hi there, after further discussed with the counter-party, they fixed the problem by adjusting their mail server (i don't know how they did that) as explained below, according to their explain, they're following RFC standard but not exchange server, I don't have such deep knowledge in RFC, wondering if it's really exchange's fault? many thx!
=== quote ===
Thank you for all your messages thus far as we believe we were able to track down and possibly resolve the issue. From the log file you provided, we can see what's going on.
23:45:34 173.173.173.173 Response - -
220+smtp2.3rdparty.com+ESMTP+ready
23:45:34 173.173.173.173 Command HELO
smtp2.mydomain.lan
23:45:34 173.173.173.173 Response - -
250+smtp2.3rdparty.com
23:45:34 173.173.173.173 Command MAIL
FROM:<apmrep@mydomain.com>
23:45:34 173.173.173.173 Response - -
250+2.1.0+Sender+<apmrep@mydomain.com>+ok
23:45:34 173.173.173.173 Command RCPT
TO:<apmrep.sisg@3rdparty.com>
23:45:34 173.173.173.173 Response - -
250+2.1.5+Recipient+<apmrep.sisg@3rdparty.com>+ok
23:45:34 173.173.173.173 Command DATA -
23:45:34 173.173.173.173 Response - -
354+Enter+mail,+end+with+CRLF.CRLF
Everything is working fine up to this point. However, the next "250" response from our server starts to cause some issues with the MSExchange SMTP service. The response "250-Transmission+in+progress.+Stay+tuned" from our end isn't breaking any RFC rules and can be regarded as informational - but Exchange doesn't like it. Every "250" response from this point onwards is displaced by 1. So when Exchange issues the RSET command (to start a new message transfer), the response that Exchange sees is "250+2.0.0+4c4938e9-0004694b+Message+accepted+for+delivery" from the previous message handshake session. What it should see is "250+2.0.0+Reset+state". This continues throughout the remaining handshake sequence until Exchange issues the "DATA" command. Once Exchange send this, it expects to see a "354+Enter+mail,+end+with+CRLF.CRLF" but instead, sees a "250+2.1.5+Recipient+<sisp@3rdparty.com>+ok" from the previous "RCPT TO:" command. When Exchange sees this response, it immediately issues a "QUIT" command and aborts. My guess is that Exchange will then produce a NDR with a 599 error (undetermined error) and probably with data or part of the data from the response it has seen ("250+2.1.5+Recipient+<sisp@3rdparty.com>+ok").
23:45:34 173.173.173.173 Response - -
250-Transmission+in+progress.+Stay+tuned
23:45:34 173.173.173.173 Command RSET -
23:45:34 173.173.173.173 Response - -
250+2.0.0+4c4938e9-0004694b+Message+accepted+for+delivery
23:45:34 173.173.173.173 Command MAIL
FROM:<rjones@mydomain.com>
23:45:34 173.173.173.173 Response - -
250+2.0.0+Reset+state
23:45:34 173.173.173.173 Command RCPT
TO:<dspb@3rdparty.com>
23:45:34 173.173.173.173 Response - -
250+2.1.0+Sender+<phyde@mydomain.com>+ok
23:45:34 173.173.173.173 Command RCPT
TO:<dspf@3rdparty.com>
23:45:34 173.173.173.173 Response - -
250+2.1.5+Recipient+<dspb@3rdparty.com>+ok
23:45:34 173.173.173.173 Command RCPT
TO:<ckhu@3rdparty.com>
23:45:34 173.173.173.173 Response - -
250+2.1.5+Recipient+<dspf@3rdparty.com>+ok
23:45:34 173.173.173.173 Command RCPT
TO:<dspr@3rdparty.com>
23:45:34 173.173.173.173 Response - -
250+2.1.5+Recipient+<ckhu@3rdparty.com>+ok
23:45:34 173.173.173.173 Command RCPT
TO:<mcal@3rdparty.com>
23:45:34 173.173.173.173 Response - -
250+2.1.5+Recipient+<dspr@3rdparty.com>+ok
23:45:34 173.173.173.173 Command RCPT
TO:<sisg@3rdparty.com>
23:45:34 173.173.173.173 Response - -
250+2.1.5+Recipient+<mcal@3rdparty.com>+ok
23:45:34 173.173.173.173 Command RCPT
TO:<sisp@3rdparty.com>
23:45:34 173.173.173.173 Response - -
250+2.1.5+Recipient+<sisg@3rdparty.com>+ok
23:45:34 173.173.173.173 Command DATA -
23:45:34 173.173.173.173 Response - -
250+2.1.5+Recipient+<sisp@3rdparty.com>+ok
23:45:34 173.173.173.173 Command QUIT -
23:45:35 173.173.173.173 Response - -
354+Enter+mail,+end+with+CRLF.CRLF
I should point out again that none of the responses being sent by our SMTP severs are breaking any of the RFCs and it looks like a bug in the Exchange SMTP service where it expects to see a regimented single command/response sequence. As a result, we have modified our mail server to remove the output of the command causing problems.
Best Regards,
Customer Support
=== quote ===