Discussion:
Backscatterer.org - How to stay off the list
(too old to reply)
Claus v. Wolfhausen
2009-12-17 11:49:30 UTC
Permalink
People often try to discuss incredible sounding stories as an excuse why
their system does backscatter.

I give therefore following public advice how to stay off the
Backscatterer blocklist.

1. Do not use Sender-callouts aka Sender Verify aka SAV.

2. Reject emails to not existing users at your local domains.
Every MX must have knowledge of valid recipients.

3. Reject emails from your users claiming to be NULL SENDER or
postmaster in MAIL FROM.

4. Tempfail (45X Error) instead of accepting on forwarding situations,
if the destination system is not available.

5. Install an "emergency brake" at your gateway for that seldom cases,
that might still generate accidental backscatter.

There are 2 very easy ways to install such an "emergency brake" to
ensure your system can *NEVER* backscatter:

Possibility 1: Set your gateway to readdress all emails claiming to be
NULL SENDER or postmaster in MAIL FROM which are not addressed to your
authenticated users to the local postmaster.

Possibility 2: Set your gateway to readdress all emails claiming to be
NULL SENDER or postmaster in MAIL FROM which are not addressed to your
authenticated users to /dev/null.

It is really that easy.

If you follow my advice, then your system can *NEVER* get listed at
ips.backscatterer.org

Q.E.D.
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
D. Stussy
2009-12-17 19:24:25 UTC
Permalink
Post by Claus v. Wolfhausen
People often try to discuss incredible sounding stories as an excuse why
their system does backscatter.
I give therefore following public advice how to stay off the
Backscatterer blocklist.
1. Do not use Sender-callouts aka Sender Verify aka SAV.
I agree.
Post by Claus v. Wolfhausen
2. Reject emails to not existing users at your local domains.
Every MX must have knowledge of valid recipients.
I agree. That's what tools like LDAP are for.
Post by Claus v. Wolfhausen
3. Reject emails from your users claiming to be NULL SENDER or
postmaster in MAIL FROM.
If they're from NULL or postmaster, they're not from users. This doesn't
make sense.

If you're saying that no user program should autorespond with an address
other than the user's mailbox, then I agree.
Post by Claus v. Wolfhausen
4. Tempfail (45X Error) instead of accepting on forwarding situations,
if the destination system is not available.
This requires an RFC/standards change as SMTP is NOT "instant messaging"
but a store-and-forward technology by design.
Post by Claus v. Wolfhausen
5. Install an "emergency brake" at your gateway for that seldom cases,
that might still generate accidental backscatter.
Too vague.

Also, why shouldn't non-delivery due to a hardware or OS error not be
reported back?
Post by Claus v. Wolfhausen
There are 2 very easy ways to install such an "emergency brake" to
Possibility 1: Set your gateway to readdress all emails claiming to be
NULL SENDER or postmaster in MAIL FROM which are not addressed to your
authenticated users to the local postmaster.
Bad advice. These should be REJECTED during SMTP, just like any other
message addressed to an unknown recipient. Rejection never causes
backscatter (by the rejecting host).
Post by Claus v. Wolfhausen
Possibility 2: Set your gateway to readdress all emails claiming to be
NULL SENDER or postmaster in MAIL FROM which are not addressed to your
authenticated users to /dev/null.
Bad advice. These should be REJECTED during SMTP. Same as above. Unknown
recipient is a valid delivery error that needs to be reported to the
sender.
Post by Claus v. Wolfhausen
It is really that easy.
Only for your clueless minions who don't know what they're doing.
Post by Claus v. Wolfhausen
If you follow my advice, then your system can *NEVER* get listed at
ips.backscatterer.org
If you follow his advice, you're not in compliance with STD 10 or its RFCs.
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
Seth
2009-12-17 20:47:08 UTC
Permalink
Post by D. Stussy
Post by Claus v. Wolfhausen
4. Tempfail (45X Error) instead of accepting on forwarding situations,
if the destination system is not available.
This requires an RFC/standards change as SMTP is NOT "instant messaging"
but a store-and-forward technology by design.
Where is it prohibited by which RFC?

"450 Requested mail action not taken: mailbox unavailable (e.g.,
mailbox busy or temporarily blocked for policy reasons)"

If I can't forward, then the mailbox is unavailable at that moment, so
450 is exactly what RFC 5321 specifies.
Post by D. Stussy
Also, why shouldn't non-delivery due to a hardware or OS error not be
reported back?
Because the failures should be detected before the final 250.
Post by D. Stussy
Post by Claus v. Wolfhausen
It is really that easy.
Only for your clueless minions who don't know what they're doing.
If it's harder for you, who does that make clueless?
Post by D. Stussy
Post by Claus v. Wolfhausen
If you follow my advice, then your system can *NEVER* get listed at
ips.backscatterer.org
If you follow his advice, you're not in compliance with STD 10 or its RFCs.
Citation needed. RFC 5321 specifically states that 450 means exactly
what Claus suggests.

Seth
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
Claus v. Wolfhausen
2009-12-18 03:24:04 UTC
Permalink
Post by D. Stussy
Post by Claus v. Wolfhausen
People often try to discuss incredible sounding stories as an excuse why
their system does backscatter.
I give therefore following public advice how to stay off the
Backscatterer blocklist.
1. Do not use Sender-callouts aka Sender Verify aka SAV.
I agree.
Fine.
Post by D. Stussy
Post by Claus v. Wolfhausen
2. Reject emails to not existing users at your local domains.
Every MX must have knowledge of valid recipients.
I agree. That's what tools like LDAP are for.
Exactly.
Post by D. Stussy
Post by Claus v. Wolfhausen
3. Reject emails from your users claiming to be NULL SENDER or
postmaster in MAIL FROM.
If they're from NULL or postmaster, they're not from users. This doesn't
make sense.
You have probably never seen "clever" lusers installing crapware that
generates a fake undeliverable report to the claimed sender if the luser
clicks the "this is spam" button.
Post by D. Stussy
If you're saying that no user program should autorespond with an address
other than the user's mailbox, then I agree.
Exactly that was what i wanted to say.
Post by D. Stussy
Post by Claus v. Wolfhausen
4. Tempfail (45X Error) instead of accepting on forwarding situations,
if the destination system is not available.
This requires an RFC/standards change as SMTP is NOT "instant messaging"
but a store-and-forward technology by design.
I strongly recommend you should read RFC 5321
Post by D. Stussy
Post by Claus v. Wolfhausen
5. Install an "emergency brake" at your gateway for that seldom cases,
that might still generate accidental backscatter.
Too vague.
No explained in detail some lines later...
Post by D. Stussy
Also, why shouldn't non-delivery due to a hardware or OS error not be
reported back?
Because they should be detected before saying 250 accepted for delivery...
Post by D. Stussy
Post by Claus v. Wolfhausen
There are 2 very easy ways to install such an "emergency brake" to
Possibility 1: Set your gateway to readdress all emails claiming to be
NULL SENDER or postmaster in MAIL FROM which are not addressed to your
authenticated users to the local postmaster.
Bad advice. These should be REJECTED during SMTP, just like any other
message addressed to an unknown recipient. Rejection never causes
backscatter (by the rejecting host).
Sure but i said: Install it as an emergency brake ....
That means under normal conditions this readdressing should never happen,
but if you were a programmer you would know that it is always a good idea
to create an emergency routine just in case something goes really wrong...

In case you are using redirecting to your local postmaster account you will
like get aware of any problems ...
Post by D. Stussy
Post by Claus v. Wolfhausen
Possibility 2: Set your gateway to readdress all emails claiming to be
NULL SENDER or postmaster in MAIL FROM which are not addressed to your
authenticated users to /dev/null.
Bad advice. These should be REJECTED during SMTP. Same as above. Unknown
recipient is a valid delivery error that needs to be reported to the
sender.
See above. The only difference is that in this case you will not be alerted
if something goes wrong but it is your system ....
Post by D. Stussy
Post by Claus v. Wolfhausen
It is really that easy.
Only for your clueless minions who don't know what they're doing.
You are clueless but at least you have realized parts of the backscatter
problem. There is still hope for you :-)
Post by D. Stussy
Post by Claus v. Wolfhausen
If you follow my advice, then your system can *NEVER* get listed at
ips.backscatterer.org
If you follow his advice, you're not in compliance with STD 10 or its RFCs.
Wrong. RFC 5321 says it is fine. Which RFC are you claiming says different?
--
Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
Testing Account
2009-12-22 15:55:06 UTC
Permalink
Frankly, there's no real reason to worry about whether you are on the
backscatterer list or not, because even if you are, it will probably
have no impact.
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
Claus v. Wolfhausen
2009-12-24 11:14:34 UTC
Permalink
Post by Testing Account
Frankly, there's no real reason to worry about whether you are on the
backscatterer list or not, because even if you are, it will probably
have no impact.
Yes that is the reason why no one ever came here and did whine about
being listed at ips.backscatterer.org

--

Claus von Wolfhausen
Technical Director
UCEPROTECT-Network
http://www.uceprotect.net
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
Loading...