JoeKiller – me no are no nice guy

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.