Front page | perl.qpsmtpd |
Postings from April 2006
On 2006-04-12 10:40:50 +1000, john habermann wrote: > Hi Peter > > On 4/7/06, Peter J. Holzer <hjp@hjp.at> wrote: > > On 2006-04-07 14:55:58 +1000, john habermann wrote: > > > > Since the error occurs within less than 1 second of the start of the > > transmission, it can't be a timeout. So the connection is probably > > dropped for some reason. It is probably best to use a packet sniffer > > (ethereal works well in my experience) to check what the client and > > server actually send. > > I have used tethereal to capture the communication between the server. > This is what I have between the 354 go ahead and the 451 error: [...] > I am afraid it doesn't mean anything to me. Should I try capturing the > full packet information rather than trying just the summary of the > packets. Yes. Although tethereal is a bit too verbose then (I am not very familiar with it as I normally use ethereal, but there doesn't seem to be anything between "one line summary" and "full details). With ethereal I'd capture whole packets (this is the default with ethereal anyway), then choose "Follow TCP stream". That gives me the conversation (text only, no packet headers) with client and server coloured red and blue, respectively. You can use tethereal (or tcpdump) to write to a file and then use ethereal to inspect that file (ethereal is also available for Windows, in case you don't have a Linux workstation). In this case I think we can figure out what happens from the summary lines alone. > 35.108240 ws143.ltsp -> Broadcast ARP Who has 10.1.0.10? Tell 10.1.0.143 > 35.108365 10.1.0.143 -> 10.1.0.10 TCP 1847 > smtp [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460 > 35.108383 10.1.0.10 -> 10.1.0.143 TCP smtp > 1847 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 > 35.108615 10.1.0.143 -> 10.1.0.10 TCP 1847 > smtp [ACK] Seq=1 Ack=1 Win=65535 Len=0 > 45.128569 10.1.0.10 -> 10.1.0.143 SMTP Response: 220 natoffice.wilderness.org.au ESMTP qpsmtpd 0.32 ready; send us your mail, but not your spam. > 45.128976 10.1.0.143 -> 10.1.0.10 SMTP Command: EHLO BODHRAN > 45.132931 10.1.0.10 -> 10.1.0.143 TCP smtp > 1847 [ACK] Seq=98 Ack=15 Win=5840 Len=0 > 45.134141 10.1.0.10 -> 10.1.0.143 SMTP Response: 250-natoffice.wilderness.org.au Hi ws143.ltsp [10.1.0.143] > 45.134473 10.1.0.143 -> 10.1.0.10 SMTP Command: MAIL FROM: <computers@wilderness.org.au> > 45.134551 10.1.0.10 -> 10.1.0.143 SMTP Response: 250-PIPELINING The MAIL FROM command was sent before the 250-PIPELINING response to the EHLO command was received. I don't think that's allowed. [...] > 45.631418 10.1.0.143 -> 10.1.0.10 SMTP Command: RCPT TO: <cary.littleford@wilderness.org.au> > 45.633597 10.1.0.10 -> 10.1.0.143 SMTP Response: 250 <lachlan.simpson@wilderness.org.au>, recipient ok > 45.633792 10.1.0.143 -> 10.1.0.10 SMTP Command: DATA > 45.635901 10.1.0.10 -> 10.1.0.143 SMTP Response: 250 <cary.littleford@wilderness.org.au>, recipient ok That's the response to the previous RCPT TO command. > 45.636040 10.1.0.143 -> 10.1.0.10 SMTP Message Body Now the client sends the message body, before ... > 45.636243 10.1.0.10 -> 10.1.0.143 SMTP Response: 354 go ahead ... the server tells the client to do so. > 45.636415 10.1.0.143 -> 10.1.0.10 TCP 1847 > smtp [FIN, ACK] Seq=227 Ack=479 Win=65057 Len=0 And it closes the connection before the server has a chance to respond. This is definitely wrong behaviour. However, I am a bit surprised that qpsmtpd doesn't tolerate it. While there were recently some discussions about checking that form of misbehaviour AFAIK is hasn't been implemented yet (and it would belong into a plugin, anyway). maybe there is something wrong in the message body, too ... hp -- _ | Peter J. Holzer | Ich sehe nun ein, dass Computer wenig |_|_) | Sysadmin WSR | geeignet sind, um sich was zu merken. | | | hjp@hjp.at | __/ | http://www.hjp.at/ | -- Holger Lembke in dan-amThread Previous | Thread Next