Domain Verification

Hi Hashim

There are a couple of considerations ..

please see my spam configuration KB : https://community.sophos.com/kb/en-us/120802

note: the delay queue feature is a highly effective tool when combating spam.. it requires 10.5 days before it will start enforcing (so you may not be at 100% as of yet) 

in regards to things to try:

#1 configuration / policy / smtp options / perimeter protection  .. both of these check boxes should be checked.. this will tell postfix to drop mail from any non-existent envelope sender/mta.

#2 if the configured dns is slow.. (do not use external dns like 8.8.8.8)

#3 ensure the connecting ip is not listed as an internal mail host.

#4 if you are using an upstream proxy or load balancer, ensure it is allowing the actual mta to connect and it is not stripping/replacing ips.

#5 as per the spam configuration.. ensure your filtering rules are configure as per the kb

#6 the delay queue is a powerful anti-spam tool, however it takes 10.6 days to start enforcing . if its before then this feature is not active.

In regards to the message its self.. its important to ensure your looking at the envelope sender and not a DATA from .

In the message headers you will see lines like:\

(snip)

Received by: 

Received by: 

Received by: 

From: Heart Attack Defense <heart.attack.defense@fatbrainfeeds.com>
To: "jimmy, bob" <mydomain@domain.com>
Subject: An Early Warning Sign Of YOUR Heart Attack?

(snip)

very last received by, is the actual connecting mta..  anything past that is the DATA from.

If everything still seems correct and or theirs question about ips/ load balancers or upstream proxies.  You should submit samples to is-spam@labs.sophos.com  (create a new message, drag / drop all of the spam as .eml attachments)

there could be an actual spam rule, or other issue that could be identified by escalating the samples to the labs team.


I would also recommend configuring a syslog server and exporting the message.log file and the mail.log file.. this will give you all of the logs associated to the email including the triggered rules and postfix logs.



Unfortunately the logs are a must, and posting your logs on a public forum is not recommended.. however you can defiantly refer to these comments within your ticket.

Cheers

It is common for mail to come from a different IP address than the MX record.   In a big environment, one group of machines handles incoming traffic, another group of machines handles outgoing traffic.   SPF may provide a complete list of known senders, MX will not.  I have found so many problems with SPF causing false positives that I do not use it.

Some email domains are send-only, so they do not publish an MX record.   This may or may not indicate spam.   Some mail receiving systems block a non-MX domain, but not all have this feature.   I have legitimate mail coming daily, from a business partner, which is a send-only domain.

Requiring Reverse DNS or requiring Forward-confirmed reverse DNS are strategies that have been tried.   IETF does not seem to think them very useful by themselves.   See RFC 7601, the "iprev" section, for a discussion on this topic.  Follow the references in that RFC for more detail.

I am currently using UTM and another spam filter device together, neither of which understand DMARC.   My next solution must have DMARC support.   SEA is a possibility because it has DMARC, but it seems to lack other of my must-have features, like configuring whitelist rules that require matching on multiple criteria  (e.g. email domain and server RDNS).

There are vendors doing interesting work on domain reputation, matching known spam sources to other email domains and IP addresses based on Whois information and other data.  

I think the future of spam filtering is going to be in cloud services, because they will have the best databases of information, including domain reputation.

Thanks Red_Warrior and sorry for my late response.

I have applied all of the suggested configuration and the device is on production for more than 2 months.

Thanks Doglas for the useful comment.

I have been suffering from Spoofing for long time and have opened multiple support cases without a solution that is "Ideal"

I just recently realized the differentiation between sending-host and receiving-host, and that MX record is used for receiving.

I used to believe that MX servers are the ones whose IPs are expected to be seen when doing sender verification.   

RDNS as per the protocol will ONLY check if the sender IP has an MX record, which will, mainly , filter dynamic IPs, and THATS IT.

However,  I believe a good email protection solution should do something beyond that.

for example:  

1- The sender's domain in the "Mail From" SMTP header, should match the domain in the PTR for the sending IP (exceptions can be configured manually) 

2-  The sender in the "FROM" at the DATA  section, should also be verified against the either the "mail-from" or the domain in the PTR.

The letter one, was PITA and not implemented by many vendors. The bad news is that this Sender is the one displaued to the user when using MS Outlook   

I will read more about 

Forward-confirmed reverse DNS

Speaking for SEA, I agree that it has some extra features like DMRAC and also control of DKIM verification (like forcing DKIM verification for certain domains like Paypal), But on the other hand lack some features that are already applied in the UTM, like granular exceptions control.