Does this site look plain?

This site uses advanced css techniques

Logo: No Bounces

Microsoft's Small Business Server 2003 includes Exchange 2003, and in some uncommon circumstances, the default configuration provokes a failure that causes mail to bounce. It's taken a long time to figure out the whole story, and this Tech Tip covers how to fix it.

Table of Contents

Many won't ever see this issue, but we believe that this fix constitutes a best practice for an SBS installation. Why risk it with a feature you'll never use?

The short summary is that the XEXCH50 verb, which is part of an Exchange-to-Exchange extension to SMTP, is sometimes tripped up by an intermediate firewall attempting to perform deep-inspection filtering on an SMTP connection. It gets confused and aborts mail delivery even though the Exchange servers would have been happy to talk to each other.

But even without firewall issues, Exchange logs an error in the Event viewer when the verb is used even though the mail goes through just fine. This is cluttersome.

Because this SMTP command word doesn't seem to be of any use in an SBS environment (it's rare for there to be two Exchange servers in an this kind of enterprise), turning this keyword off avoids the whole issue.

This is only useful to sites that have just one Exchange server (which includes virtually all SBS2003 installations). Larger enterprises need to study this in more detail before implementing any of this (in particular, disabling this will break public-folder replication).

Furthermore, this only applies to direct Exchange-to-Exchange communications: sites that use third-party mailfiltering systems (such as Vlad's excellent Exchange Defender mail/spam filter service) won't have this direct connection, and are unlikely to ever see this issue arise.


Background

Sender / Receiver
In this Tech Tip we are only referring to server-to-server communications via SMTP, and for clarity we use the term sender to be the mailserver making the outbound SMTP connection, and receiver as the mailserver accepting that connection.

We are specifically not ever speaking about the sender or recipient email addresses, or any email client such as Outlook.

When two Exchange 2003 servers talk to each other via SMTP, they are able to engage in a bit of Exchange-specific chitchat that allows for transfer of extra information about the message being sent that SMTP doesn't normally support.

The ability to use this extra feature is guided by the advertisement of the XEXCH50 verb during the EHLO handshake. Here we show the first part of this conversation: 


     Legend: -->  we send to the other end
             <--  the other end replies to us

     $ telnet smtp.example.com 25
     Trying 10.1.1.1...
     Connected to smtp.example.com.
     Escape character is '^]'.
<--  220 example.com Microsoft ESMTP MAIL Service, ...
-->  EHLO linux.unixwiz.net
<--  250-example.com Hello [10.1.1.2]
<--  250-TURN
<--  250-SIZE
<--  250-ETRN
<--  250-PIPELINING
<--  250-DSN
<--  250-ENHANCEDSTATUSCODES
<--  250-8bitmime
<--  250-BINARYMIME
<--  250-CHUNKING
<--  250-VRFY
<--  250-TLS
<--  250-STARTTLS
<--  250-X-EXPS GSSAPI NTLM LOGIN
<--  250-X-EXPS=LOGIN
<--  250-AUTH GSSAPI NTLM LOGIN
<--  250-AUTH=LOGIN
<--  250-X-LINK2STATE
<--  250-XEXCH50     «— "We support XEXCH50"
<--  250 OK

The presence of XEXCH50 in the EHLO banner tells the sending machine that this facility is available, and we can see it in use here: 

    ...
--> MAIL FROM:<sender@example.com>
<-- 250 2.1.0 sender@example.com....Sender OK
--> RCPT TO:<recip@example.com>
<-- 250 2.1.5 recip@example.com
--> XEXCH50 1904 2
<-- 504 Need to authenticate first
--> BDAT 1211 LAST
--> Subject: Testing
--> Date: Sun, 20 Apr 2008 15:11:50 -0700
--> continued message data...
Event Viewer Message

Even though the receiving mailserver objects to the keyword (with a 504 response), it's not a fatal error: the conversation continues after sending a message to the Event Log.

Though this message may be helpful in tracking down inter-machine authentication problems in a multi-Exchange-server organization, this is nothing but noise on an SBS machine. And the "For more information" link provided in the event log is not at all helpful.

But this can get worse when deep-inspection firewalls are involved: those that attempt to parse the SMTP conversation can be tripped up by the nonstandard XEXCH50 keyword. In this case, the firewall may decide to "fail closed" on a protocol violation rather than let unknown and possibly dangerous traffic through.

We understand that older versions of ISA Server and Sonicwall have both suffered from this — surely there are others as well — though we suspect most have been fixed by now.

Turning off the use of EXCH50 is done in two places:

  1. Turn off advertisement of XEXCH50 in the EHLO banner when the receiving machine accepts a new inbound connection: this lets the sending mailserver know that we don't do XEXCH50.
  2. Refrain from issuing XEXCH50 commands when sending mail even though the receiving mailserver says it's available.

This Tech Tip covers both.


Disable inbound XEXCH50

A remote sending mailserver trying to deliver mail to us locally will only attempt to use the XEXCH50 verb if it's using EHLO mode and our Exchange server says that the keyword is available. Clearly we must turn this off.

This is done by unregistering the "event sink" for the XEXCH50 command, and it's far easier to show the steps than it is to explain exactly what this means. The XEXCH50 command appears to be handled by a specific Exchange DLL, and by unregistering it, Exchange won't use any of the DLL's facilities.

This requires locating the directory with Exchange (usually C:\Program Files\Exchsrvr\bin\) and running regsvr32 /u to unregister PEEXCH50.DLL:

unregistering peexch50.dll

The regsvr32 command returns immediately, and the dialog box appearing a moment later confirms that the DLL has been unregistered.

The various documentation recommends doing an iisreset after making the change, though in our experience the XEXCH50 verb goes away upon the next SMTP connection. We're including it here in case it actually matters.

Disable outbound XEXCH

Now that we've stopped our local copy of Exchange from advertising this feature to incoming sender mailservers, we must stop ourselves from using it on the outbound side. This is controlled by a registry entry.

  1. Start the Registry Editor regedit
  2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC
  3. Right-click on the XEXCH50 key and click New DWORD Value
  4. Name that value SuppressExternal «— no space between
  5. Set the value to 1
  6. Close the registry editor

We don't believe that a restart of any service is required for this to take effect, but don't know for sure. We can see this graphically here:

Updating registry

Other Resources

Microsoft KB article #818222
Microsoft KB article entitled "Messages remain in an outbound queue until a non-delivery report is generated when you send e-mail to a remote domain". It suggests a firewall issue on the XEXCH50 command and suggests either the disabling of XEXCH50 itself (which we recommend), or disabling EHLO mode entireyl (which we don't recommend).

We welcome feedback or reports of surprises on this Tech Tip. Special thanks to Larry Struckmeyer (SBS-MVP) for his helpful input.

First published: 2008/04/21