What is “backscatter”?
Simply put, backscatter is caused when our server accepts a message on behalf of your server, but when we try to send that message to you, your server rejects it. This accept-then-reject causes our server to generate an undesirable bounce; this is known as backscatter. Backscatter is considered a form of abuse and/or spamming by many people, and as such, we try to eliminate it as best we can. This policy is the result. We do understand that in the real world there are many variables that come in to play, and we’re happy to work with our customers.
Messages submitted through our outbound mail account service can also be considered backscatter, such as MAILER-DAEMON messages generated by a client or automatically generated delivery status notifications. If a mail server sends backscatter (usually containing spam) through our outbound mail servers, we reserve the right to revoke access at our discretion. Our servers are configured to refuse most types of backscatter messages.
Why are we doing this?
We enforce this rule (when many other providers do not) because we believe sending bounces to possibly forged return addresses is not proper behavior for a mail service provider like ourselves. We’re in business to reduce spam, not create more for others to deal with. Since the bounce is unsolicited – and goes against our design philosophy of filtering in real time and rejecting during the SMTP session – it’s considered form of spamming. If our mail servers accepted a message on behalf of your mail server, then you must accept the message, regardless of actual intent or content. The only exceptions we make are for valid technical reasons (such as malformed addresses) or policy reasons.
For further discussion, see this forum topic: http://forums.rollernet.us/viewtopic.php?t=237
Is backscatter spam?
If you look at it from a content perspective, it’s generally not spam – it’s just an error message from a mail server. The catch is that it can easily be sent back to the wrong person (i.e. forged address in spam that caused the bounce), at which point backscatter becomes spam from a consent perspective. Of course, many times a spam message is part of the bounce message, at which point it fails both the content and consent tests. Since backscatter easily crosses the line into spamming and abuse, we don’t allow it.
If you run anti-spam filtering on your server it’s up to you to configure it to never bounce messages sourced from our mail servers. In this case, the backscatter is likely to be spam, and we simply can’t allow it. Roller Network offers many filtering options and features with its mail services.
As of February 18, 2009 the automatic bounce scanner described below has been disabled. Please see the following announcement for more information: http://forums.rollernet.us/viewtopic.php?t=545
Backscatter Prevention Policy
All mail service domains served by the Roller Network must maintain a properly configured valid user table. The valid user table is configured through the account control center (http://acc.rollernet.us/) at http://acc.rollernet.us/mail/handling.php. This feature allows the Roller Network mail servers to reject unknown users, rather than accept messages that are later rejected by the final destination.
Anti-spam measures that reject during the SMTP session, when used in conjunction with the Roller Network mail services, are also subject to this policy. We recommend configuring these types of filtering to discard or file messages sourced from our mail servers, and configuring the filtering options in the account control center to match your local anti-spam policy as close as possible. The current list of mail servers and corresponding IP addresses is available in the account control center at http://acc.rollernet.us/resources.php.
The Roller Network mail servers will check and report the delivery status of all messages that are processed by our mail services. Any message that is accepted by our system as valid, but is rejected by the final destination, is considered backscatter. Messages (and the related domain) that create backscatter for any reason will be subject to one of the following actions:
- If the domain is in “Default Deny” mode, the corresponding table entry in the valid user table that permitted the message will be automatically disabled.
- If the domain is in “Default Allow” mode, it will be automatically changed to “Defer All” and our servers will stop accepting mail for the domain.
For domains using a global table:
- A global mode “Deny” table will have the corresponding table entry disabled.
- A global mode “Allow” table will be changed to “Defer” and our servers will stop accepting mail for any domain using the global table.
Domains in automatic learning mode will be ignored. If auto-learn mode domains become a source of backscatter at a future date, they will become subject to this policy.
If any automated action is taken on a domain by the account control center, a notification will be sent to the Alert Email Address configured for the parent account (or primary address if no alert address is configured). If a domain is automatically placed into defer mode, the problem may be corrected and the domain’s valid user table changed back to the appropriate mode. It is the responsibility of the account owner to ensure that the email addresses registered with the account are valid. Email settings may be updated at https://acc.rollernet.us/account/preferences.php.
All account levels are subject to this policy. Contact us with any questions regarding this policy.
Backscatter is, in general, undesirable and can be considered abusive. For more information on backscatter, see:
If you have any questions, concerns, or want to report what you think is a false positive on the backscatter scanner, contact us.
As of February 18, 2009 the automatic bounce scanner described above has been disabled. Please see the following announcement for more information: http://forums.rollernet.us/viewtopic.php?t=545