220 mysbsserver.myinternaldomain.local Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Wed, 15 Aug 2007 19:30:25 -0600Okay, so what is wrong with this picture?
It is pretty obvious that the people who set this one up were not using the CEICW to configure the Internet settings. If they did, Exchange would have answered with at least "myinternetdomain.com" instead of the .local internal domain.
What does that mean? Probably a good chunk of that particular establishment's email won't be getting anywhere fast. Most SMTP servers will perform a reverse DNS lookup on any email they are receiving. The myinternaldomain.local does not exist on the Internet, so their email is toast.
Also, the ESMTP 6.0.37.90.3959 does not line up with any of our installations. My guess is that Exchange SP2 is not installed. Our SBS Exchange SP2 ESMTP answers 6.0.3790.1830.
After a search, we couldn't find the version numbers for the SMTPSVC. Anyone able to fill us in?
So, there are two very important lessons here:
- Use the wizards! - especially the Configure E-mail and Internet Connection Wizard.
- Post SBS install should always have the latest updates and service packs.
Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
*All Mac on SBS posts are posted on our in-house iMac via the Safari Web browser.
4 comments:
The mysbsserver.myinternaldomain.local in the greeting banner simply means that the Masquerade Domain has been set without setting the FQDN.
There is no error here, apart from the leakage of the internally used domain name for the AD.
Reverse DNS is performed on the IP address of the connecting host and has nothing to do with the SMTP 220 greeting banner issued by the exchange server. It may get stuck if it uses that FQDN as the HELO/EHLO for an outbound message, but good email server configurations deal with this.
The 6.0.3790.3959 number is the version number for W2K3 SP2. The SMTP service uses the Windows Server version number and not the Exchange Server version number, as SMTP is a Windows service.
Granted the wizards make it easier, but you can have a properly running SBS box without using the wizards. It does defeat the purpose of using SBS though, but at least it allows Enterprise admins to get an SBS box up and running.
Chris,
One of the current anti-spam techniques we are running into is whether that banner correctly identifies the sending server.
If the sending server is serving myemail@myemail.com then that banner must read:
myemail.com if the IP for rDNS is pointing to itself
or
mail.myemail.com if the MX is pointing to itself.
Leaving that banner as it is will cause the user's emails being sent via that server dropped off the planet.
From DNSSTuff.com's report on the offending server:
Mail server host name in greeting
WARNING: One or more of your mailservers is claiming to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). If your mailserver sends out E-mail using this domain in its EHLO or HELO, your E-mail might get blocked by anti-spam software. This is also a technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the hostname given in the SMTP greeting should have an A record pointing back to the same server. Note that this one test may use a cached DNS record.
Note that the RFC requires that banner to correctly identify itself with a correlating DNS A record.
By default, after setting up our SBS servers, we run them through the DNSStuff.com tests as well as the MXToolbox.com MX lookup to verify that everything is as it should be.
Believe me, one little setting like this can turn into a nightmare for our client if set incorrectly.
Philip
Philip,
You're confusing the SMTP greeting banner that a *receiving* SMTP server prints prior to the SMTP conversion with the *sending* SMTP server that issues a HELO/EHLO command with FQDN.
It's irrelevant what gets printed in the greeting banner by the *receiving* SMTP server, but you are quite correct in that the FQDN used in the HELO/EHLO command should resolve to an IP address but this should not be the basis for outright rejecting an e-mail. If you look at RFC 2821 (and previous RFCs on SMTP) you will find that the section describing EHLO/HELO doesn't use the MUST directive regarding the FQDN to map to a valid address. To do so will most likely result in the blocking of valid e-mail from older mail servers,for which there are still a lot in use.
I agree that using dnsstuff.com to validate your setup is a good move, but being flexible in what you're prepared to accept also goes a long way to hassle-free administration. The programming mantra of "be flexible in what you receive, but be strict in what you transmit" is a good one to adopt.
Chris,
My interpretation of the RFC is that the banner presented in the "Receiving" banner is the same as the "Sending"? Thus, the warning given by DNSTools.com?
Is that the case? If not, where is the "sending" banner located in Exchange?
Thanks,
Philip
Post a Comment