Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Shaun E on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Reconfiguring Exchange for SMTP instead of ESMTP: Firewall Known Issue 1

Status
Not open for further replies.

ShawnF

IS-IT--Management
Oct 1, 2001
149
US
Hello,

I've recently discovered a known issue between our firewall (Watchguard Firebox II) and Exchange 2000 server. Our firewall log file is filling up tremendously fast with Bad Command entries from exchange trying to send stuff out using the Bdat command instead of the Data command (I have no idea what this means). The fix according to Watchguard is to reconfigure Exchange for SMTP instead of ESMTP. They don't give instructions on how to do that.

I am not sure where to begin with this. For all I know it may be a simple 5 minute change, or it may require an extensive and time sonsuming project that may be out of my abilities since I am new at this. However, I am the "sys admin" for my company and I want to give it a try before I hand it off to the vendor that built and installed our servers.

Thanks,

Shawn F.

For your reference, description of known incident from Watchguard:

SMTP BDAT command (Bad command: BDAT in log files - some SMTP messages fail to send)

Issue: SMTP BDAT command (Bad command: BDAT in log files - some SMTP messages fail to send).

Date Reported: 8/29/2001

Description: Some ESMTP servers (Exchange 2000 is the most common) use the BDAT command instead of the DATA command to delineate the SMTP commands from the message headers and body to the receiving mail server. This is what the log messages will look like on the Firebox:


08/10/01 09:51 smtp-proxy[10472]: [x.x.x.x:52471 x.x.x.x:25] Bad command: BDAT
08/10/01 09:51 smtp-proxy[10472]: [x.x.x.x:52471 x.x.x.x:25] Bad command: content-class:
08/10/01 09:51 smtp-proxy[10472]: [x.x.x.x:52471 x.x.x.x:25] Bad command: X-MimeOLE:
08/10/01 09:51 smtp-proxy[10472]: [x.x.x.x:52471 x.x.x.x:25] Bad command: Subject:
08/10/01 09:51 smtp-proxy[10472]: [x.x.x.x:52471 x.x.x.x:25] Bad command: Date:
08/10/01 09:51 smtp-proxy[10472]: [x.x.x.x:52471 x.x.x.x:25] Bad command: MIME-Version:

The Firebox misinterprets the BDAT command as an unknown SMTP command, and the sending mail server completely ignores the error sent by the Firebox. The mail server continues to send the message, even though it should have noticed the error message generated by the Firebox.
More information on the BDAT command can be found in RFC 2033, section 4.3.

Workaround: Configure the mail server to use SMTP instead of ESMTP.

Current Status: Open.

Software Version: All versions.
 
Shawn,

I ran into a similar problem and one easy checkbox seemed to make a difference. In the Exchange System Manager, find your SMTP connector and open up its properties. On the Advanced tab, select "Send HELO instead of EHLO". I hope this helps.
 
Thanks, I will have to try that. What is the difference between those two selections?
 
From what I understand, it's how your Exchange server initiates a conection with another messaging system for outbound messages. When it sends an initial EHLO command, it's asking to communicate using Extended SMTP (ESMTP). When it sends HELO, it's asking to communicate using regular SMTP. You can probably get more detailed information on the MS TechNet site.
 
I finally got around to making the change you suggested and it fixed the problem. Thanks for your help! Do you notice any new problems created since you're not using ESMTP? According to Technet, regular SMTP does not allow for encryption, while ESMTP does. There was something else that ESMTP offers that SMTP doesn't but I forgot what that was....

Thanks,

Shawn F.
 
I haven't noticed any problems since I made the change. I also understand that ESMTP is supposedly more secure and efficient. I have also read that there is a benefit for using ESMTP if your Exchange server is setup to retrieve messages queued at another server (i.e. your ISP queues your messages and you randomly connect to download them). I don't think this is too common though.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top