On 2006-04-12 10:40:50 +1000, john habermann wrote: > Hi Peter > > On 4/7/06, Peter J. Holzer <[EMAIL PROTECTED]> 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: <[EMAIL
> PROTECTED]>
> 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: <[EMAIL
> PROTECTED]>
> 45.633597 10.1.0.10 -> 10.1.0.143 SMTP Response: 250 <[EMAIL
> PROTECTED]>, 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 <[EMAIL
> PROTECTED]>, 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.
| | | [EMAIL PROTECTED] |
__/ | http://www.hjp.at/ | -- Holger Lembke in dan-am
pgpjc5YOc13On.pgp
Description: PGP signature
