One of the layers of processing in Exchange Online Protection is mail flow rules. You might know these from their previous name in Exchange Server, which was transport rules.
The name transport rules aligned with the naming of the Hub Transport server role, first introduced in Exchange 2007. In the latest versions of Exchange, that role no longer exists. The Mailbox server role now provides that functionality. Transport rules and mail flow rules the same thing. The capabilities of the rules have improved a lot since those early days in Exchange 2007. And calling them mail flow rules makes more sense to some people because “mail flow” is an easy concept to understand. The name “transport” is a little bit vague and wouldn’t make sense to someone who hasn’t worked with those older versions of Exchange.
Mail flow rules can provide a wide range of policy enforcement outcomes. They can also fight spam and other unwanted types of email.
Now, some of you might be asking, should we need to fight spam by creating mail flow rules in Exchange Online? Doesn’t that seem a bit old school? Especially when there are complex antispam algorithms running behind the scenes in Exchange Online Protection?
That’s a fair question. And yes, it does go back to the good old days of spam fighting where a lot of spam was blocked with very simple keyword-based rules. That was before antispam products evolved to include more intelligent detection. But even the most intelligent spam filters still miss things. And we need to use every tool at our disposal to tailor our antispam protection to suit our organization.
Sometimes that means creating mail flow rules to do things like:
- Allowing or blocking specific IP addresses, domain names, and email addresses.
- Blocking specific keywords, whether that’s to detect text in the message or even a URL that the message might contain.
- Tagging all email that is inbound from external senders that contains suspicious keywords.
Mail flow rules are also effective against fresh, new attacks and campaigns. Sometimes you need a quick solution while you wait for EOP to start detecting a new attack.
Yes, EOP should prevent most attack scenarios for you. But security is all about mitigating risks using all reasonable means at our disposal.
Here’s an example. Consider a sales contact form running on a company website. The company website is hosted on shared hosting server, provided by a web hosting company. The sales team wants to ensure that no contact form emails are filtered by Exchange Online Protection. Weakening the entire organization’s protection is not a good solution. Instead, one option to achieve this is to add the web server IP address to the IP allow list in your EOP connection filter policy. This will prevent the connection filter from blocking the email.
However, by using the IP allow list you are allowing all email from that web server’s IP address to bypass your spam filters. In effect, you’re trusting the web hosting company to prevent other customers who are also on the shared hosting server from spamming or phishing your users. It’s unlikely that the web hosting company will be able to prevent that. Furthermore, any insecurity in the web form itself could lead to abuse.
So, to enhance your protection without opening yourself up to a new risk, you can use a mail flow rule instead. The mail flow rule is configured to ensure that mail from the web server is still subject to spam filtering if it doesn’t have the specific characteristics of the sales contact form emails. To achieve this, create a mail flow rule such as the following:
Mail flow rules can also be used to combat malicious emails. A lot of phishing attacks rely on impersonation of popular services like Amazon, Dropbox, Docusign, banks, and even Office 365. These attacks can be difficult for even a human to spot, so it’s no surprise that they sometimes slip past Exchange Online Protection’s defences.
However, you can mitigate these risks by using mail flow rules with regex filters to detect likely phishing attempts. You can then either quarantine them, send them to junk folders, or modify them in some way to alert the user that the mail is suspicious. Popular Twitter personality @SwiftOnSecurity has helpfully shared a series of regex patterns and other text strings in this GitHub repository.
You should use caution when applying these patterns in your mail flow rules. I don’t recommend setting up rules to immediately delete or block the mail until you have an understanding of what is being detected. Using non-destructive actions such as prepending the subject line, or raising the SCL so the message is delivered to junk mail, are reasonable approaches. Another good approach is to configure the rules to send incident notifications, or add a BCC recipient for a shared mailbox so you can review the messages that are triggering the rule. @SwiftOnSecurity has another repository with details of mail flow rules that you can use as well.
Summary
Although Exchange Online Protection is an effective solution for preventing spam and phishing from reaching your email users, there is more that we can do to protect our organizations. Exchange Online mail flow rules provide a lot of flexibility and power for detecting and mitigating specific risks. You can start with a few basic rules, and then build up over time as you learn more about the threats that are unique to your organization.
Thank you.
I try to filter the content of htm & html attachment; when it contains
* document.write(unescape( …..
* or http{://e ……..
but the filter does not seem to work.
Have any idea on how to accomplish this ?
how to force O365 to analyse in brute mode, not in reader mode ?
best regards
Hi Paul, If a message found positive in malware scanning and the attachment was scanned and cleaned. Will the message bypass other filtering policies once it was cleaned up by Malware filters?
Is there any way to make our rules run after the native EOP and ATP filters? I’d like to let those Microsoft-supplied rules do the heavy lifting and to use our custom rules only for the small percentage of items that slip through.
Does anyone have a good method to deduce which of those list of regex strings was the one that flags an email? I’m currently just being notified on email hits (vs. taking action) against SwiftOnSecurity’s regex “Suspicious Patterns” list: a large of amount of emails being flagged are legitimate ones.
Unfortunately, I am a regex n00b so editing this list is a bit daunting to me if I don’t know which lines are the ones that flagged an email…especially when the message body is fairly extensive. I tried using a site like https://regexr.com/ or https://regex101.com/ to paste in the email body to be parsed by the regex strings above but didn’t have much success.
Got any shortcuts from new blood like myself, or is learning Regex the only real thing one can do?
If you’ve thrown them all into a single rule you won’t be able to identity specific hits. What you can do is add them in small batches to a test rule. Once that test rule proves that it won’t create excessive false positives, move those values into a rule that is actively enforced, and test another small batch in the test rule. If you wanted to speed things up you could run multiple test rules at the same time. If a test rule is causing false positives you can just break it down into individual values to test further.
Thanks Paul – yeah that’s exactly what I was thinking about doing too (maybe…5-10 regex lines per rule) to narrow down the false-positive offender quicker…but I figured I’d ask the above question before I go and create 5 new test rules 🙂
Thanks for your help!
Great article. A quick question: If an IP address is in the IP allow list, will it by pass all other layered defences shown in the first picture? For example if the mail has a malware attached, will it pass through and deliver to the inbox of the recipient?
Good question. No, it will bypass content filtering but not malware filtering. Malware filtering is mandatory.