From Roaring Penguin
Revision as of 17:02, 6 September 2017 by JohnMertz (talk | contribs)

Jump to: navigation, search

We frequently receive reports about both Hosted CanIt and On-Premise clients being listed on This generally does not mean what you might expect.

What is Backscatter?

Backscatter is an abundance of automated bounce messages sent by mail servers, typically as a side effect of incoming spam. For example, if a spammer is spoofing the sending address "" and sends hundreds of messages to email addresses that don't actually exist to "", that machine will generate a bounce message for each telling the sender that their message failed to be delivered. Those bounce messages would attempt to be delivered to the real "". As a result "" is seen as source of backscatter, since bounce messages should not be sent to an innocent third party.

What is, is a useful tool, in principal. It aggregates machines know to generate backscatter so that email filters can block bounce messages coming from those machines. However, in practice, it does not use this power responsibly.

They use a ransom model for de-listing as opposed to most legitimate sources which will de-list when spamming problems have been resolved. If the ransom is not paid, they keep the IP on their list for 4 weeks, regardless of whether the triggering behaviour has continued. Furthermore, refuses to explain or provide details for why certain IPs have been listed, providing no way to ensure that the machine will not be added again weeks later.

What is not is NOT actually a blacklist. Common tools for searching IP blacklist (including MX Toolbox, which we at Roaring Penguin often suggest as a useful resource) sometimes include on their list of actual blacklist sources. This is convenient for searching, but it is not accurate.

MX Toolbox staff have admitted in their forums that should NOT be treated as a blacklist source and the discussion in that forum post makes a persuasive argument that it should not be included at all.

No reasonable mail filter should treat mail from IPs listed solely with this service as spam unless it is clear that the message is a bounce.

How Hosted CanIt addresses

Bounce messages are generated by the sending machine. The primary way that we avoid backscatter is by ensuring that any messages that are going to fail do so while we are still the receiving machine. This is why we insist upon having a working recipient verification method. With that, we are able to reject invalid recipients as soon as the sender asks for them. That way, if the recipient doesn't exist, the sending machine generates the bounce, not ours.

We also have our Hosted service configured to not send bounce messages via our inbound MX machines. If a message comes in via your MX record to Hosted CanIt and is not rejected during the receipt phase, but then goes on to be rejected by your mail server (while we ARE the sending machine) we will generate the bounce message, but we will route it via a different dedicated machine that is in no way associated with your domain. This way, if the bounce machine gets listed, it will not impact you except that some legitimate bounce messages (eg. typos) might not be received by the sender.

Despite this, our inbound machines do still (somehow) get listed on and we do not pay to get them de-listed. Instead, we use different machines for sending outbound mail. This way, even if one of our inbound machines is listed, outbound mail flow will not be impeded. Sending machines should not check the reputation of the recipient mail server (there is no reason to block mail sent TO a spam source), so inbound mail should also not be impacted.

If your Hosted CanIt domain is having mail blocked and you find that it is listed only on, this should be treated as a coincidence. Our inbound scanners are often on their list so this can appear to be a reasonable explanation, but it is a red herring. Unfortunately, unless it is us blocking the outbound mail, we generally don't have a good explanation for why the mail might be getting rejected. You can feel free to contact our support, but it is very likely that you will need to get in contact with the recipients mail service.

Questionable Methodology and Professionalism

Upon investigating one incident it was revealed that we were listed because of one incident out of hundreds of thousands of messages sent per day with the information:

 You will either find that your system tried to send misdirected bounces or misdirected autoresponders to claimed but in reality faked senders, or your system tried sender verify callouts against our members near that time.
 So you should look for outgoing emails that have a NULL SENDER or POSTMASTER in MAIL FROM.

The blocked machine does not send bounces messages, nor does is outbound messages should the recipient have auto-replies set up.

In all likelihood what they triggered on was "Sender Verify Callouts". claims that this is unequivocally abusive, however it is a mandatory requirement for using our system and it is with that understanding that we have clients intentional enable recipient verification connections from our service (except if they use LDAP or a manually defined list of valid addresses). With that understanding our clients should not be submitting any complaints and would be wrong to assume that this behaviour is abusive.

We use <> (a null sender) as the from address when verifying that the recipient email address actually exist (although no message is actually sent from this sender, regardless of the of the result). RFC1123, which defines the specifications for valid email addresses, indicates that this address MUST be treated as valid and it is widely used for anonymous testing purposes. This address alone certainly cannot be taken as evidence of a bounce or auto-reply and it is dubious that this would be done without vetting the contents of the actual message.

The "postmaster" user is also defined as belonging to a real human and is to be used as an address which is guaranteed to be monitored. Assuming that a valid administrative user is always abusive is also irresponsible. That said, we do not generate messages from "postmaster".

The message that matches the non-specific time window that was provided appears to have been a bounce generated by a third party which we relayed to the original sender who had an Always-Allow rule for the domain. The server which generated the bounce was AmazonSES, which conveniently was not listed as a source of backscatter despite the fact that they must send hundreds of thousands daily.

Despite our past bad experiences with Backscatterer, it is not our place to endorse or object to the use of any reputation list. We can say, objectively: