BDAT causing SMTP service to drop Email

I have been searching around the web to answer a vexing problem about my SMTP server not being able to send mails to our new email gateway. We were running Symantec Mail Security for SMTP (smssmtp email antivirus antispam ) at the front end for some time. Upgrading to version 5.01 seemed to be a good fit. After some tweaking, mail was flowing smooth.

The next day one of the managers said their usual email from our external production site wasn’t being delivered. Obviously this was an issue with the gateway as everything worked fine before the upgrade. First, though, I wanted to examine the production sites setup. The server had a normal Server 2003 IIS 6.0 SMTP server. It only relayed email from the web server and was delivering emails to everywhere except our email gateway. The mails would sit in the Inetpub SMTP queue directory. Further I was able to test SMTP Manually with no problem. Even SMTPDiag said everything was OK. Finally I had to sniff the packets. Here is the resulting conversation from the gateway’s point of view:

220 mailgateway Symantec Mail Security Mon, 17 Sep 2007 12:00:00 -0000
EHLO prodserver
250-mailgateway Hello [192.168.0.2]
250-TURN
250-SIZE 10485760
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250 OK
MAIL FROM: SIZE=2728
250 2.1.0 postmaster@production.org....Sender OK
RCPT TO:
250 2.1.5 manager@company.com
BDAT 2728 LAST
451 Timeout waiting for client input
Received: from mail pickup service by production.org with Microsoft SMTPSVC;
QUIT

After the BDAT 2728 LAST there should be a stream of data which represents the email, but there wasn’t. I tried a manual SMTP connection and sure enough as soon as I entered the BDAT command my SMTP connection was dumped. This was a server which was explicitly whitelisted via IP. Seeing that nothing I tried kept this connection up, I called Symantec for an explanation. They searched for a while and eventually told me that they do not support “chunking”. I pointed out that it was a standard part of the ESMTP services and that it was supported in previous versions. She acknowledged this fact and basically stated that they do not support it. No direction or anything, I was left in the dark.

BDAT is part of a newer ESMTP specification which extends SMTP’s ability to push stuff other than text through the email servers. You can see ESMTP and SMTP Commands and Definitions on Microsoft’s site. Pay attention to the CHUNKING definition:

An ESMTP command that replaces the DATA command. So that the SMTP host does not have to continuously scan for the end of the data, this command sends a BDAT command with an argument that contains the total number of bytes in a message. The receiving server counts the bytes in the message and, when the message size equals the value sent by the BDAT command, the server assumes it has received all of the message data.

The ESMTP stuff gave me direction. Some searching yielded Microsoft’s “How to turn off ESMTP verbs” in Exchange servers. Basically you can turn off different ESMTP features of exchange servers. Since Exchange uses the IIS SMTP service, I figured this might work for the SMTP server Symantec had me install. Reading the article I needed the Metabase Explorer which can be found by searching for IIS 6.0 resources. Apparently, by changing the SmtpInboundCommandSupportOptions integer I would be able to turn off the dreaded chunking, however when I changed the value to remove chunking and restarted the service, the option remained. Reviewing the earlier ESMTP documents, I realized I had to disable both BINARYMIME and CHUNKING due to the fact that BINARYMIME uses chunking to move the data around. Finally, after turning off both the CHUNKING and BINARYMIME verbs, the production site’s mail was flowing.

I hope anyone else banging their head finds this useful. Symantec should either change this option using their installer or inform the system administrators better within the instructions. Having random SMTP connections dropped without explanation is a pretty harry detail to debug especially due to how random it is. Reasons for blocking these transmissions date back to the IIS BDAT DoS attacks (Windows SMTP Service Denial of Service) code occurring back in the day. Still, being that this is a default service which is installed by Microsoft’s SMTP installer, I would think Symantec would at least address it. I saw unanswered posts about antivirus software dropping email all the way back to 2005. It is all the same problem and this is the answer.

8 thoughts on “BDAT causing SMTP service to drop Email”

  1. This is somewhat prophetic, as I am troubleshooting an issue with our Exchange mail server that seems very similar to this. Thank you for offering up the notes on your experiences.

  2. Excellent!

    I was troubleshooting a problem similar to this one back in 2005, but from a client-side perspective. The SMTPSVC running on Windows 2000 Server was getting the exact same treatment when forwarding mails with BDAT to an Exchange 5.0 server. I never did figure out why BDAT had stopped working, but I found a workaround that forced the SMTPSVC service to always use DATA instead: change the MetaBase property /LM/SmtpSvc/SmtpOutboundCommandOptions from “7” (the default) to “5”. Undocumented, but worked like a charm. 🙂

    The problem resurfaced at a different installation this week, with Windows 2003 Server and Exhange 6. Now I can tell the Exhange administrators there to take a closer look at their security software – _it_ could actually be dropping BDAT connections, like you describe.

    Thanks!

    -m-

  3. I’m having a similar problem, and I found the Symantec SMTP Server with the Metabase Explorer. However, the current value for SmtpInboundCommandSupportOptions is 4546589 and from the MS artile you mention I cannot figure what combination of options is turned on or off from this value. Should I simply subtract the values for Binary and Chunking from this and hope?

  4. Hi Alan,

    I think you will be safe to subtract out the offending SMTP verbs from the total options. The KB article only focuses on a limited subset of the SMTP commands that IIS’ SMTP service offers. In any case, since they are tied to specific hex values, subtracting out the ones you want to turn off will turn those off. I would suggest writing down the original just in case things don’t go as planned. We dumped the product after we fixed this problem due to the slowdown it caused in the mail queue.

    Good luck!

    -Joe

  5. I think Symantec will be forced to modernize their software.
    We use non-microsoft SMTP servers and iPhones use BDAT to send to them.
    People disabling chunking should be aware that they’re potentially making things a little more inefficient for their mobile users.

  6. There is an issue with Google’s SMTP when it tries to use CHUNKING. But they appear to not transmit the number of bytes they say they will in the BDAT verb. This means 3rd party servers can’t support CHUNKING. Unless they can blacklist Google from advertising this to them.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s