We frequently get 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?” I thought I’d write a blog post to explain what we do and how the Backscatterer list works.

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 joe@example.com wants to know if his message was delivered or not.

However, the following picture illustrates the backscatter case:

In this case, joe@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:

• Perform an SPF check on the incoming message.
  
  If the message does not pass an SPF check, then the message is (probably) spoofed, or at the very least cannot be verified.  Do not send a bounce to messages that do not pass SPF checks.
  
  The problem with this strategy is that at least half of legitimate messages do not even publish SPF records.  Thus, a substantial number of messages that could not be delivered would not receive bounces if the mail server chose to do this.
  
  
• Bounce the message in SMTP.
  
  If the on-premise mail server refuses to deliver the message before it has accepted the message in the SMTP transaction and issues a reject, the sending mail server must issue the bounce.  In this case, the sending mail server generates the bounce but it would go to the spammer, not the innocent victim.
  
  The problem with this is that many servers do not have the ability to detect the full suite of cases where it won’t be able to deliver the message later on.  It may not know during SMTP that the user’s inbox is full, or that the inbox does not exist, or that there was some other transient error downstream and could not deliver.

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:

1. That are on the IP list, and
2. Send mail with an SMTP MAIL FROM of “postmaster@” or the null sender, <>.

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. 

1. Suppose a spammer sends a zero-day spam campaign to a non-existent mailbox. 
   
   
2. The spam makes it through the filter (Forefront Online) and is delivered to the customer’s on-premise mail server.
   
   
3. The customer’s on-premise mail server discovers it cannot deliver the email and sends an NDR bounce back to the spoofed sender.
   
   
4. The customer uses our service to send all of its outbound mail, including NDR bounces. We end up relaying the NDR through our outbound.
   
   
5. Backscatterer detects and adds the mail relay’s IP address (i.e., our IP address) to its list.  The mail did not originate with us, but we were the ones that relayed it to the rest of the world.
   

The below diagram illustrates this process:

We have mitigations in place to prevent backscatter from going out through our outbound IPs, including the following:

1. We inspect outbound mail for NDR bounces and route them through our NDR pool rather than our regular outbound pool.
   
   
2. Customers can upload user lists to us and we can reject the mail in SMTP rather accepting it. This prevents the customer from bouncing it later on.
   
   
3. Our filters are constantly updating in order to keep the missed spam as small as possible, which lowers the risk of sending backscatter in the first place. 

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:

1. The IP address is on the Backscatterer list, and
2. The sending email is sent from postmaster@ or <>.

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.