Most organizations have applications that need to send mail, either to internal recipients or to have a SMTP server to relay there mail destined for external recipients.
Common configuration is that they figure out the server IP address where the application runs on and then enter the IP on the allow relay list on Exchange 2003 virtual server, if then run Exchange 2007 they often are a little bit puzzled until someone shows them MSExchangeteam 'Allowing application servers to relay off Exchange Server 2007'.
Why do I think this is bad?
First, most applications don't need the relay permission, admins often think so but the truth is that they don't need it.
Servers are not static, IP changes, name changes both on the application side and the Exchange side. If the server get infected with something bad, it is not just the application running on the server that are allowed to relay but everything running on the server since its the IP that are allowed to relay.
Remember this: IP restrictions are not authentication.
Have seen applications that are hardcoded to connect to a specific IP or names meaning that either IP or name can be changed on the Exchange server.
Resolution is of course to have applications easy to reconfigure with destination SMTP server’s name.
Another problem is when there is some kind of anti spam software running on Exchange. This will often make the applications mail end up being classified as spam and make Exchange admins trying to configure the anti spam software to white list some mail. Sometimes this cant be done and sometimes it can making admin workload bigger than before.
Resolution here is to educate developers in SMTP. They often doa good job of building applications but are very often bad at SMTP. They find a free SMTP engine on Internet and they stick it in there applications and in the end they manage to send a SMTP mail but it is often bad formatted in various way making the anti spam software react and classify it as spam.
Resolution here is of course knowledge about SMTP.
Back to the relaying part of sending mail. One very good solution here is to have the submitting application to authenticate SMTP session. By sending authenticated SMTP mail to Exchange, it will get the permission to relay, it will most likely bypass antispam software depending of software of course. It will also make the application easier to move to another server without reconfigure Exchange. Another thing with authentication and SMTP is that if I authenticate as ‘application 1’ I am only allowed to use ‘application 1’ email address, I cannot use another SMTP sender address..
My recommendations to developers, building applications sending SMTP mail.
* Use a good SMTP engine that do work. Have encountered one that didn’t like the tarpit time you can configure in Exchange 2003 and are default activated on Exchange 2007. This engine simply could not work with tarpit.
* Use authentication when submitting mail. NTLM is of course better than Basic, but if using basic authentication, use it over TLS.
* Ability to easy change SMTP configurations such as server name, sender and receiver SMTP address, TCP port etc.
* Have redundant SMTP server configuration. The SMTP server that you’re using may not be up and running. If mail are critical, consider having some queue functionality in the application that can try to resend mail. One queue functionality would be to use the local windows SMTP service, but this will only work if application run on Windows boxes and the local SMTP service is working.
* Use only valid sender and destination SMTP addresses. If there is NDRs, they should go back to an existing mailbox that someone can monitor and act upon.
There are of course recommendations to Administrators as well.
* Clearly communicate to developers what the rules are for submitting SMTP mail to Exchange. No hardcoded configuration, no anonymous submission etc.
* Add a good name for your SMTP servers, such as ‘smtp.ADdomainname’ for developers to use instead of giving them the real servername or IP. With a standardized name across all applications you can make them use another server when there is need. If you internal Active Directory name is company.local your smtp server name would be SMTP.company.local
* Set up internal MX records for the AD name space. Same advantage as above.
* If you have multiple HUB server, Load balance TCP port 587 across those servers and make applications use SMTP submission port 587 (this is the client receive connector that are default created on Exchange 2007) instead of the default 25. Don’t load balance port 25 since it will break functionality in Exchange such as authentication.
* Be very careful of what mail you let through to internet, maybe you should block applications to send to Internet on connectors to maintain your good name on Internet. Companies have ended up on various blacklists because developers have built bad SMTP mail or have a buggy application that spray mail across Internet.
There are probably many more options/alternative/thoughts around this, but these are just some that regularly pops up.
