text: The Backscatterer.org IP list
  
  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.
  
  Short version
  
  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.
  
  Long version
  
  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:
  
  That are on the IP list, and
  
  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.
  
  Suppose a spammer sends a zero-day spam campaign to a non-existent mailbox.
  
  The spam makes it through the filter (Forefront Online) and is delivered to the customer’s on-premise mail server.
  
  The customer’s on-premise mail server discovers it cannot deliver the email and sends an NDR bounce back to the spoofed sender.
  
  The customer uses our service to send all of its outbound mail, including NDR bounces. We end up relaying the NDR through our outbound.
  
  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:
  
  We inspect outbound mail for NDR bounces and route them through our NDR pool rather than our regular outbound pool.
  
  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.
  
  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:
  
  The IP address is on the Backscatterer list, and
  
  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.
  
  More and more we are seeing customers on hosted MS servers being added to RBLs. This is not a 'spoofing' situation because, unless perhaps there are 'dedicated' outbound smtp relay IP options for your customers, we are observing that many domains be be being relayed off the same outlook protection server. Basically, a 'shared services' model where companies who are using RBLs effectively cannot accept legitimate email. Whitelisting the IP, or range for that matter, is not the answer because we, as a receiving company, cannot be sure who or what may be on that server next based upon a rotation which is not in the subscribed customer's control. Nor is whitelisting the domain, for reasons well pointed out above (spoofing). What needs to happen to negate this need is for hosted customers to be issued dedicated virtual IPs for their outbound mail, which will finally address this issue.
  
  I wanted to make a clarification out of fairness. This isn't just on Microsoft Hosted Exchange or 0365 observation. Nor is my post strictly about backscatter.org, as there are a number of other legitimate and well maintained RBLs which many messaging administrators will use on their block lists.
  
  I am observing this the same pattern on many high volume hosted email platform services as more companies embrace the cloud. The answer cannot be to whitelist a domain or entire range of IP addresses – one sending services site even asked their customer to 'ask' the recipient company, yours truly, to exempt an IP range that could have included up to 4K IPs ( …sure, I did that …not!)
  
  I don't know that an enforced global adoption of SPF or DKIM type implementations solve this concern, which is why mention a need for dedicated virtual IPs for each individually hosted company. Basically, the hosted customers don't realize that their outbound is being injected into a pool of servers, shared with lots of other sending domains, including those that may be sending zero hour garbage, including potential malicious payloads.
  
  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)”.