Spam not being blocked by Cloudmark with Forefront Protection for Exchange due to Exchange receive connector configuration

There can be a wide variety of reasons for Cloudmark not detecting Spam as you expect. Too many to place in one blog, but I would like to discuss a fairly common one which is due to a mis-configuration of the Exchange receive connector.

Basically this issue is caused because, by design, if an email is pass to an Exchange server via an authenticated connection, Exchange will assume that this is a “safe” email (as it comes from a trusted source) and will bypass the Anti-Spam scanning.

To address this you must ensure that all connections coming from machines which could be passing Spam emails to this server, are forced to use “Anonymous” authentication and will then be subjected to Anti-Spam scanning.

Ok, so how do we do this.

In this example I will assume that in front of the Server performing Anti-Spam scanning, we have 2 edge servers, routers or SMTP relay servers, which have the IP addresses:- 10.0.0.51 & 10.0.0.52.

 

1) First we need to edit the default receive connector to exclude these 2 IP addresses

clip_image002

2) Next we need to create the new connector, through which all possible Spam emails will flow

clip_image004

3) Next we need to set this to accept only anonymous connections

clip_image006

4) Then finally we need to restart the Exchange transport service for the changes to be applied.

 

To test that this new connector is the connector that is being connected to from your front end/SMTP relay/Edge server, you should open the new connector in Exchange and set the “Protocol logging level” to Verbose under the “General” tab and this should then start to log entries to the Exchange protocol logs, (by default this is located in “C:\Program Files\Microsoft\Exchange Server\v14\TransportRoles\Logs\ProtocolLog\SmtpReceive”).

 

There is also a “dirty” (and unsupported method I would assume) to test this, which is to temporarily change the FQDN in the receive connector (General Tab), and then connect to the server from your front end/SMTP relay/Edge server on port 25 (putty is a good tool to use for this if you would prefer not to install the telnet client).  This should then display the FQDN name configured in the connector.

 

Additionally, I would recommend that you review Van’s great blog describing another very common issue we see relating to Spam detection:-

https://blogs.technet.com/b/msfss_stuff/archive/2010/04/23/forefront-protection-for-exchange-blocks-outlook-block-sender-functionality-and-exchange-imf.aspx

 

 

Any comments and/or constructive feedback are most welcome.