Exchange 2007 Header Firewall
With the never ending fight to reduce spam, phishing messages, malicious attachments and other evil message trends it never amazes me how far some companies are willing to take their spam filters to protect themselves. It’s always that once piece of the security triad that seems to be the kicker. Availalbility! I completely understand companies saying “drop all attachments”, “no html”, etc. On the hand at what point can one crack down on the spammers yet still consider email as a valid and reliable source of communication. I have recently come across a scenario where maybe .05% of emails were not actually making it the intended recipeints but no NDR was produced. It turns out that the messages were being marked as spam.
So, I looked at the normal things that may cause that; are they on a blacklist, does the RDNS record exist and is it valid, can I email AOL/Gmail/etc (those will point out most issues), does the sending server show a clean record of delivering said items. Everything in this case proved successful. So I ran the messages, the same messages getting blocked through 2 different spam engines and look at what it was giving them a rating as. Barracuda and MailScanner/SpamAssassin showed the message in the negatives (perfectly fine) and were far from scoring a blockable item.
I started searching Microsoft’s sites to find out if there is an issue with Exchange 2007 failing to send out mail without providing an NDR. After several white papers I found that the problems were in the “Received:” and “Thread-Index:” message headers of the email. Custom rules were created at the recipient locations that blocked the message if the “Received:” routing information was not verifiable or the IP addresses in the header were anything other than the matching RDNS MX record.
There are a couple of different ways to correct this. For this specific scenario, where an Edge Transport server was utilized, removing not only the edge transport server from the permissions regarding the “Send Routing Headers” rights.
In the Exchange shell this would be:
Remove-AdPermission -identity “EdgeSync – ” -User “MS Exchange\Edge Transport Servers” -ExtendedRights MS-Exch-Send-Headers-Routing
(without an edge transport)
Remove-ADPermission -id “Organization to Internet” -User “NT Authority\Anonymous Logon” -ExtendedRights Ms-Exch-Send-Headers-Routing
This can also be accomplished by using ADSIEdit.msc and right clicking on “CN=Configuration -> CN=Services -> CN=Microsoft Exchange -> CN= -> CN=Administrative Groups -> CN=Exchange Administrative Group -> CN=Routing Groups -> CN=Exchange routing Group -> CN=Connections -> CN=”Select Send Header Name” Once there go to properties -> security -> Advanced. Here you can change the accounts permission on the Send Routing Headers and remove any “Account Unkowns”, Anonymous Logon and/or Edge Trasport users. By removing them from the permissions list it will also take them out of the Organization and Forest Header information. This seems to have takent the Thread-Index issue from getting caught as spam as well.
