Office 365 (Exchange Online Protection, or EOP) frequently receives questions about the Backscatterer.org IP blocklist. Customers call in and say “Your outbound IPs for the service are on Backscatterer! What are you doing about it?” This often occurs when people go to a 3rd party website, enter in our outbound IPs, and it says that our IPs are listed on Backscatterer.
EOP does not delist from the Backscatterer list. Generally speaking, when customers receive NDR messages indicating the message was blocked, it is not because the IPs were listed on Backscatterer but instead for some other reason such as a different IP blocklist, or due to content of the message. The details are in the bounce message and more details can be discovered searching support sites of the IP list responsible.
Backscatterer is designed to list IPs from mail servers that transmit backscatter mail – email servers that accept the email during the SMTP transaction, discover that they cannot deliver it, and then send a bounce back to the original sender. However, if the original sender is spoofed, then the bounce goes to the spoofed sender who may be an innocent victim.
The below picture illustrates the legitimate case:
There’s nothing wrong with the above in the legitimate case because firstname.lastname@example.org wants to know if his message was delivered or not.
However, the following picture illustrates the backscatter case:
In this case, email@example.com receives a bunch of email bounces in his inbox that he did not send and this is undesirable, especially if the original message was spam. The on-premise mail server has different strategies to avoid this:
The Backscatterer IP list publishes IP addresses that send backscatter messages and bounces. However, it explicitly states that the list should be used in “safe mode.” This means that if you are using Backscatterer as an IP blocklist, you should only block messages:
Why do they say this?
Because in the above example, the sending mail server sends bounce messages out of the same IP address that it sends regular, one-to-one email. Backscatterer is designed to stop backscatter, not legitimate mail. Backscatter mail is ultimately an NDR bounce, and NDR bounces usually contain postmaster@ or the null sender <>. That is not the full set of NDR identifiers, but it’s good enough to get probably 80% of all bounce messages.
Using Backscatterer in this way (IP address + some identifier within the message itself) is an easy implementation to block NDR bounces from IPs that are known to have sent backscatter while not blocking legitimate mail.
Having explained that, let’s look at the architecture in a hosted service. Because a hosted service is effectively a relay, the mail server that sits in front of the on-premise mail server does not have all the information available to it.
The below diagram illustrates this process:
We have mitigations in place to prevent backscatter from going out through our outbound IPs, including the following:
Even in spite of these mitigations, there is still the small risk that we may not detect all bounces. Some spam may leak through, some customers may bounce it, and we may not detect backscatter spam on the outbound. This is a minority case and we actively seek to minimize it as much as possible. Because we are a relay for outbound mail, some backscatter may relay through us. There are times when we simply do not have all available information at the time of relay to make a decision to prevent backscatter. It’s a byproduct of a hosted service that sits in front of downstream mail servers and all hosted mail services have the same problem. In the picture above, the spammer has sent a malicious mail. But it does not have to be a spammer, it could be a user who has mistyped an email address and the mail that is bounced is not necessarily spam but is still going to the wrong user.
That’s why our outbound IPs may end up on Backscatterer. But whereas Backscatterer lists most IPs because they have a lack of mitigations to prevent backscatter, our IPs get listed despite our mitigations to prevent backscatter.
However, even if we do end up on Backscatterer, it shouldn’t matter. If a 3rd party is using it in safe mode, they should reject if:
Legitimate mail does not meet this criteria.
Using the list in this way – as documented on their webpage – would not prevent a mail server from blocking legitimate mail, it only blocks backscatter. It is transparent to legitimate mail (except for legitimate bounces).
This is why we do not take action if our IPs end up on Backscatterer.org. Even if they do, because of our architecture, it won’t matter in nearly all cases so long as the user of the Backscatterer list implements it in the way it is documented.
That’s how most hosted services deal with the Backscatterer IP list.