Note: this question has changed. Originally I believed it had something to do with BDAT.

An external party is trying to send us a message to a valid address and they're getting an NDR:

<sender.it #5.5.0 smtp;503 Bad sequence of commands>

Note that this message is coming from the sender's side.

I'm looking at my SMTP logs and am finding:

#Fields: date time c-ip cs-username cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes cs-bytes
2009-11-24 19:38:26 sender.it RCPT - +TO:+<me@mydomain.com> 250 0 0 28
2009-11-24 19:38:26 sender.it BDAT - - 250 0 0 9
2009-11-24 19:38:26 sender.it BDAT - - 250 0 42 9
2009-11-24 19:38:26 sender.it BDAT - - 250 0 42 9
2009-11-24 19:38:26 sender.it QUIT - sender.it 240 11188 0 37

The message never reaches Exchange. No record of anything from the sender in the message tracking log. I'm also running GFI MailEssentials 14 and there is no record of this message in its logs. No Exchange-related errors or warning in the event logs. Queues are normal.

Where do I go from here? This user is not able to send mail to my domain. I'm not having any other reported incoming email issues at this time...everything seems to be flowing like normal.

  • I had a similar issue and found that our TrendMicro was quarantining the message right after the SMTP accepted it. By doing this, the Message Tracking didn't see it as well. Maybe you have a 3rd party software that is doing some sort of policy checking - profanity, credit card, etc. It also may have had a file type set up to quarantine.
    – user291345
    May 28 '15 at 20:16

If the server responds to the ehlo command and lists Chunking, then it supports BDAT. To test your server, telnet to it on port 25 and issue the ehlo command. It will then list which of the ESMTP commands that it supports. If Chunking is in the list then BDAT is not the problem. Because this is Exchange you should see that it supports the full ESMTP command set and Chunking because AFAIK, this is the default for Exchange.

Your log file doesn't have enought info to tell what the problem is. You need to modify the log file parameters to include status codes so that you can see what the status is for each command (log file entry) and determine what the problem is.

  • Good suggestion. I believe I may have jumped the gun thinking it had something to do with BDAT. I've enabled status codes in my logs and will have the user resend.
    – Boden
    Nov 24 '09 at 19:31
  • I edited my question to include new log entries. Everything looks like it's succeeding. However, the message doesn't seem to get any further than the SMTP server.
    – Boden
    Nov 24 '09 at 20:15
  • Yep, based on the logs it looks like it's making it into SMTP and past the SMTP filtering (if you have any enabled). My next suggestion would be to use the Message Tracking tool to see if it's getting filtered by the Intelligent Message Filter.
    – joeqwerty
    Nov 24 '09 at 20:17
  • No record of the message in Exchange. I have a spam filter integrated into Exchange and it's not showing this message coming in either. I'll keep digging.
    – Boden
    Nov 24 '09 at 21:43
  • Check the badmail folder on the Exchange server to see if the message is in there. If it is then it means that the sender is being filtered by Sender Filtering.
    – joeqwerty
    Nov 24 '09 at 22:01

The Exchange Best Practices Analyzer will check to see if the server supports BDAT (their writeup on this particular test can be found here: http://technet.microsoft.com/en-us/library/aa997593.aspx). Not sure if disabling the CHUNKING and BINARYMIME verbs will help, but if you want to try it for purposes of receiving that particular e-mail from the Italian provider, instructions are here: http://support.microsoft.com/?kbid=257569

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.