This site uses advanced css techniques
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.
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.
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:<firstname.lastname@example.org> <-- 250 2.1.0 email@example.com....Sender OK --> RCPT TO:<firstname.lastname@example.org> <-- 250 2.1.5 email@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...
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:
This Tech Tip covers both.
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:
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.
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.
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:
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