On Tue, 21 Aug 2001, Charles Churchill wrote:
> Here is a transcript of a session I had sending email to a client's site. It
> look like it died shortly after the initial handshake. Could someone please
> take a look at it and give me an opinion on what is going on?
Thanks for doing all the right things and posting a complete debugging
session. I've cut this down to just the SMTP dialogue, until the failure
point:
> SMTP<< 220 galaxyplus.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.2966 ready at Tue, 21 Aug 2001 14:30:52 -0400
Aarrgghh!! MS software ... watch out for dragons ... :-)
> SMTP>> EHLO PONY.datatek-net.com
> SMTP<< 250-galaxyplus.com Hello [64.244.65.198]
> 250-TURN
> 250-ATRN
> 250-SIZE
> 250-ETRN
> 250-PIPELINING
> 250-DSN
> 250-ENHANCEDSTATUSCODES
> 250-8bitmime
> 250-BINARYMIME
> 250-CHUNKING
> 250-VRFY
> 250-X-EXPS GSSAPI NTLM LOGIN
> 250-X-EXPS=LOGIN
> 250-AUTH GSSAPI NTLM LOGIN
> 250-AUTH=LOGIN
> 250-X-LINK2STATE
> 250-XEXCH50
> 250 OK
It claims to support every option under the sun. It also is broken,
because it should not be saying
> 250-AUTH=LOGIN
That is a pander to another broken bit of MS software, which expects
that broken line, instead of the correct "AUTH LOGIN". Sigh. However,
Exim is not that fanatical, and we carry on...
> SMTP>> MAIL FROM:<root@???> SIZE=1382
SMTP>> RCPT TO:<mgoff@???>
SMTP>> DATA read response data: size=50
Exim sends those three commands in a block, because the server supports
pipelining.
> SMTP<< 250 2.1.0 root@???....Sender OK
> SMTP<< 250 2.1.5 mgoff@???
> SMTP<< 354 Start mail input; end with <CRLF>.<CRLF>
The server sends three responses in a block. All OK.
> SMTP>> writing message and terminating "."
Exim now sends the message.
> writing data block fd=6 size=362 timeout=300
> ok=0 send_quit=0 send_rset=1 continue_more=0 yield=1 first_address=0
> set_process_info: 16804 delivering 15ZGTt-0004N1-00: just tried
> mail.galaxyplus.com [209.178.72.226] for mgoff@???: result DEFER
> LOG: 0 MAIN
> mail.galaxyplus.com [209.178.72.226]: Connection reset by peer
Instead of sending a response at the end of the message, the server just
drops the connection. That is a problem at the server end.
This kind of behaviour has been seen on servers that do not like the
message for some reason - for example, it's too big, or they think it's
spam, or whatever. Instead of sending back a negative response (which
would cause Exim to bounce the message) they just drop the connection.
This is broken behaviour.
I hope this helps.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
