Friday, July 31, 2009

Some thoughts about applications sending SMTP messages to Exchange

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
* 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.

Wednesday, July 29, 2009

OCS Remote Connectivity Analyzer

Some of you might know of the Exchange Remote Connectivity Analyzer that I wrote about a year ago 'Test Exchange Connectivity website'

Now there is new Remote Connectivity Analyzer, this time for OCS (Office Communicator Server). This is work in progress so don't count on full functionality yet but with your feedback the tool will improve.

The URL is here

Thursday, July 16, 2009

Update Rollup 9 for Exchange Server 2007 Service Pack 1 (KB 970162) is released

Rollup 9 for Exchange Server 2007 SP1 is released.

Read about all the included fixes and download from here KB 970162

Some noticeable fixes are: Note that this in not the complete list but just some of the fixes. For a full list see the link above.

947662 ( ) The transport rule "when the Subject field or the body of the message contains text patterns" does not work accurately on an Exchange Server 2007 Service Pack 1-based computer

957137 ( ) The reseed process is unsuccessful on the CCR passive node after you restore one full backup and two or more differential backups to the CCR active node in Exchange Server 2007 Service Pack 1

959559 ( ) Transaction log files grow unexpectedly in an Exchange Server 2007 Service Pack 1 mailbox server on a computer that is running Windows Server 2008

961124 ( ) Some messages are stuck in the Outbox folder or the Drafts folder on a computer that is running Exchange Server 2007 Service Pack 1

968205 ( ) The Microsoft Exchange Information Store service crashes every time that a specific database is mounted on a computer that is running Exchange Server 2007 Service Pack 1

968621 ( ) The Microsoft Exchange Information Store service crashes when you use a Data Protection Manager (DPM) 2007 server to perform a snapshot backup for an Exchange Server 2007 Service Pack 1 server

970086 ( ) Exchange Server 2007 Service Pack 1 crashes when the Extensible Storage Engine (ESE) version store is out of memory on a computer that is running Windows Server 2008

Wednesday, July 15, 2009

Update for Forefront Security for Exchange 2007

If you haven’t noticed yet, you can now download “Microsoft Forefront Security for Exchange Server with Service Pack 2”

You can download an evaluation version here

You should read the release notes as there is information about the installation or upgrade if you already have an earlier version installed.
Release notes is here