Strange event 3030 NDR on exch2003

[zaccaz]

exch2003sp2 on w2k3sp2, with backend + frontend servers deployment

now got strange, unpredictable ndr especially when sending to a particular email domain "example.org" in which we got Event 3030 NDR (status code 2.1.5 for recipient xxx@example.org) & Event 10009 DCOM (unable to communicate with smtp.example.org <--which is the smtp server of the recipients)

say in 15:51 got the ndr, in 15:52 the sane sender forward the rejected email to the same xxx@example.org recipient, it went thru without problem....

wondering how can i further narrow down the issues & fix it? many thx!

 

[zaccaz]

typing mistake, it should be

say in 15:51 got the ndr, in 15:52 the same (not sane) sender forward the rejected email to the same xxx@example.org recipient, it went thru without problem....

later on, we got similar cases of event 3030 ndr without event 10009 dcom at the same time.

anyway the most difficult part of this problem is the status code 2.1.5, which should mean "valid recipient email address"

anyone can help? million thx in advance!

 

[zaccaz]

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 ===