Blocking invalid From: addresses in Office 365
A couple of weeks ago, we made an announcement in Office 365 that we would be implementing stricter checks of the From: address, starting Nov 9, 2017. You can find that at How Office 365 validates the From: address to prevent phishing. I won't repeat everything in that article as you can click and read for yourself.
Instead, I'm going to describe the background of that decision. For you see, we've been doing a lot of work on phishing this past year, and one of the tricks that spammers use is to send email with malformed From: addresses:
From: Sender
From: Example Sender <example>
From: Another Example <someone@>
And so forth.
As you may know, earlier this year we tightened up Outlook.com to prevent anyone from sending email with a malformed From: address. We are now aligning the behavior in Office 365 as well.
After deploying the behavior in Outlook.com, I was concerned that we would get complaints from senders that we were marking these messages as spam. I knew from analysis that there appeared to be "legitimate" messages sending in that fashion. We went ahead and deployed anyway, and the total number of complaints was... zero.
Not one.
That caught me off-guard.
That was Consumer email, but what about Enterprise? The problem with Enterprise email is that there is a ton of legacy email servers out there that send malformatted email. I wasn't sure whether we could get away with marking these types of messages as spam.
But the reality is that we can't protect users from phishing attacks if we let these types of messages through. It gives spammers far too much room to maneuver if they can put random garbage into the From: header as our parsers cannot possibly detect every possible combination of usually-bad-but-not-always. And therefore we took the decision to enforce the RFCs that define how to send email with a properly formatted From: address. It's the only way to prevent phishers from living in that space.
You may recall I wrote a blog post last year about some other type of From: address enforcement here - Sending mail with invalid From: addresses to Office 365. This new behavior will take precedence over that one.
I am aware that this will probably affect some small subset of "legitimate" email, that is, email software that is misconfigured. Those types of messages will start getting marked as spam unconditionally unless an administrator creates an override for them. I've gotten the follow-up question "Can we still get these types of messages scanned for spam, and just have the From: validation enforced?"
The answer is no. Either accept the email unconditionally using an IP Allow entry or Exchange Transport Rule, or let the message go to Junk. There is no hybrid approach.
Hopefully this cuts down on unwanted email, while minimizing any "legitimate" messages that are sending non-RFC compliant messages.
Oh, one last thing.
This is called out in the linked article at the top of this blog post, but I want to say it again. One thing that some senders do is try to suppress replies to automated mailers. Thus, they send email this way:
SMTP MAIL FROM: <>
From: <>
This is a clever attempt to trick a mail server into not replying to a message. Those types of messages will be marked as spam, and messages without a From: header at all may even be rejected in the future.
If you want to suppress autoreplies, either:
Send from a domain that is set up for it, e.g., noreply.contoso.com, and set up a rule in your email filter to delete all messages going to that domain. OR
.
Send from a domain that has a null MX record, e.g.,
noreply.contoso.com IN MX .That lets mail servers know that the domain does not receive email.
Use one of those two methods. But don't send non-RFC compliant email. We are getting pickier and pickier about it.
Comments
- Anonymous
October 24, 2017
Sadly the null MX record (aka rfc 7505) was not supported by Exchange Online (at least some time ago)https://techcommunity.microsoft.com/t5/Exchange/Support-for-RFC-7505/td-p/4240Is this implemented now ?