Backscatterer.org - How to stay off the list
Claus v. Wolfhausen
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
message news:hg9i02$hes$1...@news.eternal-september.org...
> 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.
> 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.
> 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.
> 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.
> 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?
> 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.
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).
> 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.
> It is really that easy.
Only for your clueless minions who don't know what they're doing.
> 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.
Seth
D. Stussy <rep...@newsgroups.kd6lvw.ampr.org> wrote:
>"Claus v. Wolfhausen" <use-reply-...@remove-this.com> wrote in
>message news:hg9i02$hes$1...@news.eternal-september.org...
>> 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.
>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.
>> 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?
>> 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
Claus v. Wolfhausen
spam+ne...@bde-arc.ampr.org says...
>
>"Claus v. Wolfhausen" <use-reply-...@remove-this.com> wrote in
>message news:hg9i02$hes$1...@news.eternal-september.org...
>> 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.
>> 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.
>> 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.
>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.
>> 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
>> 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...
>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...
>> 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.
>
>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 ...
>> 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 ....
>
>> 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 :-)
>> 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
--
Testing Account
backscatterer list or not, because even if you are, it will probably
have no impact.
Claus v. Wolfhausen
> 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