Possible to block outbound mail if reply-to domain doesn't match sending domain?
Question asked by Steve Vibert - 4/9/2020 at 7:18 AM
Our HR department recently received a phishing email from a spoofed employee email address that was very well crafted and extremely convincing with a writing style was very typical of the employee purporting to be sending the message.

Luckily, the actual sender used a mail server that was blacklisted and SM spam filtering blocked the message which resulted in our employee receiving a delivery failure email. Looking at the content of that email we discovered that the reply-to address was a .lv (Latvia)  TLD.  

While I'd like to think that our HR staff would have contacted the employee directly to ask for additional information, I'm not 100% convinced they would have given the level of chaos, distraction, and stresses caused by the pandemic.

We're currently running SM 15.7 Enterprise.  Is there a setting that allows blocking outbound mail when the reply-to domain does not match the SM domain?  

For example: assume my SM domain is "abc.com" and I receive an email from a co-worker such as "bob@abc.com". Can I block a reply to the sender if their reply-to address is anything other than an "@abc.com" address?

I fully realize that there *might* be cases where a different reply-to domain is legitimate but I'd like to option to block this.

2 Replies

Reply to Thread
Douglas Foster Replied
I think you want to block incoming mail that claims to be from your domain when it is actually coming from an external source.    Since bad guys want anonymity, it is unlikely that the reply-to will be useful as a message filter.

What you need to do is to create a regular expression to match on the From: header, and then block anything where the From header is from your domain and not otherwise allowed based on an exception.   I use Declude to do this type of filtering, but a previous discussion showed how to do it with just SmarterMail as well.

If you have a DMARC policy, and the SM DMARC enforcement feature enabled, you should be able to achieve the same result, but I expect that you will need to create exceptions and will be unable to configure those exceptions in SM.

There will be some legitimate external mail that will use your domain as the sender, in direct violation of your SPF or DMARC policy.   Secure email services (ProofPoint, Cisco IronPort, and at least one other) are one of the sources:  If your people receive a message from one of their clients, and then reply with a copy to themselves, the email arrives claiming to be from your domain account, even though the source is actually the secure email service.   Some websites allow users to send content to themselves (and sometimes to others), with the sender and receiver specified by the website user.

Consequently, your solution depends foremost on having a spam filter that can configure both the rules you need and the exceptions that you encounter.   I have not found anything except Declude that can do this to my satisfaction.   You also need good log analysis tools, a willingness to tolerate some messages being delayed by quarantine or blocked completely when new exceptions are encountered, and the labor effort to evaluate the logs to identify and configure the necessary exceptions.    

I strongly recommend running your spam filtering as an incoming gateway, so that incoming mail, internal mail, and outgoing mail are documented in separate log files.  My first incoming gateway uses SM+Declude as my incoming gateway, with two other products behind it.   One of those other products also functions as my outgoing gateway.   I do almost no spam filtering on my SmarterMail mail post office.
Steve Vibert Replied
Sorry for the late reply and thanks for the info--very helpful.

Reply to Thread