{"id":1401,"date":"2014-09-28T01:56:01","date_gmt":"2014-09-28T06:56:01","guid":{"rendered":"http:\/\/swildow.darktech.org\/wp\/?p=1401"},"modified":"2014-09-28T01:56:01","modified_gmt":"2014-09-28T06:56:01","slug":"backscatter","status":"publish","type":"post","link":"http:\/\/www.wildow.com\/blog\/?p=1401","title":{"rendered":"Backscatter"},"content":{"rendered":"<h3 class=\"post-name\">The Backscatterer.org IP list<\/h3>\n<div class=\"post-rating\">\n<span id=\"ctl00_content_ctl00_w_31573__acf0ed_ctl00_ctl01\" class=\"rating readonly\" title=\"Rated Good [4 out of 5].\"><\/span><\/div>\n<div class=\"post-author\"><span class=\"profile-usercard-hover\" data-profile-rendered=\"true\" data-profile-userid=\"606c6162db1f4fa2ba6f902f24ab4fb8\"><span class=\"user-name\"><a class=\"internal-link view-user-profile\" href=\"http:\/\/blogs.msdn.com\/31628\/ProfileUrlRedirect.ashx\">tzink<\/a><\/span> <\/span><\/div>\n<div class=\"post-date\"><span class=\"value\"> 22 Aug 2012 10:59 AM <\/span><\/div>\n<div class=\"post-date\"><a href=\"http:\/\/blogs.msdn.com\/b\/tzink\/archive\/2012\/08\/22\/the-backscatterer-org-ip-list.aspx\">http:\/\/blogs.msdn.com\/b\/tzink\/archive\/2012\/08\/22\/the-backscatterer-org-ip-list.aspx <\/a><\/div>\n<div class=\"post-date\"><!--more--><\/div>\n<p>&nbsp;<\/p>\n<p><span style=\"font-family: verdana, geneva;\">Office 365 (Exchange Online Protection, or EOP) frequently receives questions about the <a href=\"http:\/\/www.backscatterer.org\/\">Backscatterer.org<\/a> IP blocklist.\u00a0 Customers call in and say \u201cYour outbound IPs for the service are on Backscatterer!\u00a0 What are you doing about it?\u201d 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.\u00a0<\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\"><strong>Short version<\/strong><\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">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.<br \/>\n<\/span><\/p>\n<p><strong><span style=\"font-family: verdana, geneva;\">Long version<\/span><\/strong><\/p>\n<p><span style=\"font-family: verdana, geneva;\">Backscatterer is designed to list IPs from mail servers that transmit backscatter mail \u2013 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.\u00a0 However, if the original sender is spoofed, then the bounce goes to the spoofed sender who may be an innocent victim.<\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">The below picture illustrates the legitimate case:<\/span><\/p>\n<p><a href=\"http:\/\/blogs.msdn.com\/cfs-file.ashx\/__key\/communityserver-blogs-components-weblogfiles\/00-00-00-68-90-metablogapi\/2844.image_5F00_37921EA8.png\"><img loading=\"lazy\" decoding=\"async\" style=\"border: 0px currentcolor; display: inline; background-image: none;\" title=\"image\" src=\"http:\/\/blogs.msdn.com\/cfs-file.ashx\/__key\/communityserver-blogs-components-weblogfiles\/00-00-00-68-90-metablogapi\/3823.image_5F00_thumb_5F00_41E34308.png\" alt=\"image\" width=\"554\" height=\"219\" border=\"0\" \/><\/a><br \/>\n<span style=\"font-family: verdana, geneva;\">There\u2019s nothing wrong with the above in the legitimate case because joe@example.com wants to know if his message was delivered or not.<\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">However, the following picture illustrates the backscatter case:<\/span><\/p>\n<p><a href=\"http:\/\/blogs.msdn.com\/cfs-file.ashx\/__key\/communityserver-blogs-components-weblogfiles\/00-00-00-68-90-metablogapi\/0383.image_5F00_169EAC01.png\"><img loading=\"lazy\" decoding=\"async\" style=\"border: 0px currentcolor; display: inline; background-image: none;\" title=\"image\" src=\"http:\/\/blogs.msdn.com\/cfs-file.ashx\/__key\/communityserver-blogs-components-weblogfiles\/00-00-00-68-90-metablogapi\/3021.image_5F00_thumb_5F00_287B3FCE.png\" alt=\"image\" width=\"591\" height=\"266\" border=\"0\" \/><\/a><br \/>\n<span style=\"font-family: verdana, geneva;\">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.\u00a0 The on-premise mail server has different strategies to avoid this:<\/span><\/p>\n<ul>\n<li><span style=\"font-family: verdana, geneva;\"><strong>Perform an SPF check on the incoming message.\n<p><\/strong>If the message does not pass an SPF check, then the message is (probably) spoofed, or at the very least cannot be verified.\u00a0 Do not send a bounce to messages that do not pass SPF checks. <\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">The problem with this strategy is that at least half of legitimate messages do not even publish SPF records.\u00a0 Thus, a substantial number of messages that could not be delivered would not receive bounces if the mail server chose to do this. <\/span><\/li>\n<li><span style=\"font-family: verdana, geneva;\"><strong>Bounce the message in SMTP.\n<p><\/strong>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.\u00a0 In this case, the sending mail server generates the bounce but it would go to the spammer, not the innocent victim. <\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">The problem with this is that many servers do not have the ability to detect the full suite of cases where it won\u2019t be able to deliver the message later on.\u00a0 It may not know during SMTP that the user\u2019s inbox is full, or that the inbox does not exist, or that there was some other transient error downstream and could not deliver.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-family: verdana, geneva;\">The Backscatterer IP list publishes IP addresses that send backscatter messages and bounces.\u00a0 However, it explicitly <a href=\"http:\/\/www.backscatterer.org\/?target=usage\">states<\/a> that the list should be used in \u201csafe mode.\u201d This means that if you are using Backscatterer as an IP blocklist, you should only block messages:<\/span><\/p>\n<ol>\n<li><span style=\"font-family: verdana, geneva;\">That are on the IP list, and<\/span><\/li>\n<li><span style=\"font-family: verdana, geneva;\">Send mail with an SMTP MAIL FROM of \u201cpostmaster@\u201d or the null sender, &lt;&gt;.<\/span><\/li>\n<\/ol>\n<p><span style=\"font-family: verdana, geneva;\">Why do they say this?<\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">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.\u00a0 Backscatterer is designed to stop backscatter, <strong><em>not<\/em><\/strong> legitimate mail.\u00a0 Backscatter mail is ultimately an NDR bounce, and NDR bounces usually contain postmaster@ or the null sender &lt;&gt;. That is not the full set of NDR identifiers, but it\u2019s good enough to get probably 80% of all bounce messages.<\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">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.<\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">Having explained that, let\u2019s look at the architecture in a hosted service.\u00a0 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.\u00a0<\/span><\/p>\n<ol>\n<li><span style=\"font-family: verdana, geneva;\">Suppose a spammer sends a zero-day spam campaign to a non-existent mailbox.\u00a0 <\/span><\/li>\n<li><span style=\"font-family: verdana, geneva;\">The spam makes it through the filter (Forefront Online) and is delivered to the customer\u2019s on-premise mail server. <\/span><\/li>\n<li><span style=\"font-family: verdana, geneva;\">The customer\u2019s on-premise mail server discovers it cannot deliver the email and sends an NDR bounce back to the spoofed sender. <\/span><\/li>\n<li><span style=\"font-family: verdana, geneva;\">The customer uses our service to send all of its outbound mail, including NDR bounces. We end up relaying the NDR through our outbound. <\/span><\/li>\n<li><span style=\"font-family: verdana, geneva;\">Backscatterer detects and adds the mail relay\u2019s IP address (i.e., our IP address) to its list.\u00a0 The mail did not originate with us, but we were the ones that relayed it to the rest of the world. <\/span><\/li>\n<\/ol>\n<p><span style=\"font-family: verdana, geneva;\">The below diagram illustrates this process:<\/span><\/p>\n<p><a href=\"http:\/\/blogs.msdn.com\/cfs-file.ashx\/__key\/communityserver-blogs-components-weblogfiles\/00-00-00-68-90-metablogapi\/5657.image_5F00_4F49560E.png\"><img loading=\"lazy\" decoding=\"async\" style=\"border: 0px currentcolor; display: inline; background-image: none;\" title=\"image\" src=\"http:\/\/blogs.msdn.com\/cfs-file.ashx\/__key\/communityserver-blogs-components-weblogfiles\/00-00-00-68-90-metablogapi\/1460.image_5F00_thumb_5F00_76176C4E.png\" alt=\"image\" width=\"590\" height=\"278\" border=\"0\" \/><\/a><\/p>\n<p><span style=\"font-family: verdana, geneva;\">We have mitigations in place to prevent backscatter from going out through our outbound IPs, including the following:<\/span><\/p>\n<ol>\n<li><span style=\"font-family: verdana, geneva;\">We inspect outbound mail for NDR bounces and route them through our NDR pool rather than our regular outbound pool. <\/span><\/li>\n<li><span style=\"font-family: verdana, geneva;\">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. <\/span><\/li>\n<li><span style=\"font-family: verdana, geneva;\">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.\u00a0<\/span><\/li>\n<\/ol>\n<p><span style=\"font-family: verdana, geneva;\">Even in spite of these mitigations, there is still the small risk that we may not detect all bounces.\u00a0 Some spam may leak through, some customers may bounce it, and we may not detect backscatter spam on the outbound.\u00a0 <em>This is a minority case and we actively seek to minimize it as much as possible<\/em>.\u00a0 <\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">Because we are a relay for outbound mail, some backscatter may relay through us.\u00a0 There are times when we simply do not have all available information at the time of relay to make a decision to prevent backscatter.\u00a0 It\u2019s a byproduct of a hosted service that sits in front of downstream mail servers and all hosted mail services have the same problem. <\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">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.<\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">That\u2019s why our outbound IPs may end up on Backscatterer.\u00a0 But whereas Backscatterer lists most IPs because they have a lack of mitigations to prevent backscatter, our IPs get listed <em>despite our mitigations<\/em> to prevent backscatter.<\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">However, even if we do end up on Backscatterer, it shouldn\u2019t matter.\u00a0 If a 3rd party is using it in safe mode, they should reject if:<\/span><\/p>\n<ol>\n<li><span style=\"font-family: verdana, geneva;\">The IP address is on the Backscatterer list, and<\/span><\/li>\n<li><span style=\"font-family: verdana, geneva;\">The sending email is sent from postmaster@ or &lt;&gt;.<\/span><\/li>\n<\/ol>\n<p><span style=\"font-family: verdana, geneva;\">Legitimate mail does not meet this criteria.<\/span><\/p>\n<p><a href=\"http:\/\/blogs.msdn.com\/cfs-file.ashx\/__key\/communityserver-blogs-components-weblogfiles\/00-00-00-68-90-metablogapi\/0602.image_5F00_35E152D4.png\"><img loading=\"lazy\" decoding=\"async\" style=\"border: 0px currentcolor; display: inline; background-image: none;\" title=\"image\" src=\"http:\/\/blogs.msdn.com\/cfs-file.ashx\/__key\/communityserver-blogs-components-weblogfiles\/00-00-00-68-90-metablogapi\/2844.image_5F00_thumb_5F00_5CAF6914.png\" alt=\"image\" width=\"576\" height=\"125\" border=\"0\" \/><\/a><br \/>\n<span style=\"font-family: verdana, geneva;\">Using the list in this way \u2013 as documented on their webpage \u2013 would not prevent a mail server from blocking legitimate mail, it only blocks backscatter. It is transparent to legitimate mail (except for legitimate bounces).<\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">This is why we do not take action if our IPs end up on Backscatterer.org.\u00a0 Even if they do, because of our architecture, it won\u2019t matter in nearly all cases so long as the user of the Backscatterer list implements it in the way it is documented.<\/span><\/p>\n<p><span style=\"font-family: verdana, geneva;\">That\u2019s how most hosted services deal with the Backscatterer IP list.<\/span><\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The Backscatterer.org IP list tzink 22 Aug 2012 10:59 AM http:\/\/blogs.msdn.com\/b\/tzink\/archive\/2012\/08\/22\/the-backscatterer-org-ip-list.aspx<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1401","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1401","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1401"}],"version-history":[{"count":1,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1401\/revisions"}],"predecessor-version":[{"id":1402,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1401\/revisions\/1402"}],"wp:attachment":[{"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1401"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1401"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.wildow.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1401"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}