[SpamCop-List] Re: Backscatter

[Frank Ellermann]

Blammo wrote:

> blackmailing others into suporting one's (SPF) own buggy
> software is unreasonable

Just reported in another article, today I got my first load
of spam backscatter since about 10 months, reported manually
with a very polite note:

"Erroneous spam bounce / challenge / forward - please use a
 filter and/or SPF"

I really don't care _how_ they avoid it, it's only important
that they always _could_ do it using my published SPF policy.

It's an open standard, they can write their own software if
they don't like the available implementations.

> Without going into details, which you probably know anyway,
> it is not anti-spam nor real sender verification

It's anti-forgery.  Not one of the 160 bounces I got today
was necessary, they'd all result in FAIL and reject if tested
at the first MX on the side of the victims.

Also unnecessary:  all spams that made it to their victims
with my MAIL FROM in this spam run.

Also unnecessary:  all other spams with unprotected addresses
from the same zombies.  As soon as SPF checks throw some FAIL
results the receiver should know what he has to expect from
the sending IP in the next hours.

The latter might be faster than the SCBL, you can reject the
zombie immediately, even before it's reported / blacklisted.

And of course there are systems doing this already, using
SpamAssassin 3 or similar toools, and on those systems not
one spam with my forged MAIL FROM reached its victim.

>From those systems it was also not bounced to me, it was
simply rejected.  So that is a typical win-win scenario for
all participants.

> very user unfriendly.

Depends on how tricky the sender policy wants to be.  I'm no
fan of the more complex "features", for xyzzy.claranet.de it
is plain simple (two queries):

xyzzy.claranet.de text = "v=spf1 redirect=claranet.de"
claranet.de       text = "v=spf1 ip4:212.82.225.0/24
                                 ip4:195.170.96.0/24 -all"

So if you get MAIL FROM:<me at xyzzy> and the IP is not one
of the 2 * 256 listed IPs, please reject this as forgery.
Obvious without digging deep in the spec.

> However, when used after spam and virus detection, such
> as with Spamassassin, it is a useful tool.

The best order depends on the average costs.  If you do it
after spam / worm detection you already have the mail DATA.

It's better to do it between MAIL FROM and DATA - no reason
why you should waste your MTA's time receiving this crap if
you could know that it's forged before the DATA.

Of course you can also check it later together with other
tests.  Actually you can mix both approaches, if it's a FAIL
policy do it a.s.a.p., if it's a policy without FAIL chance
do it later (combined with scoring maybe) or maybe never (?)   

The most expensive steps are the DNS queries.  Bye, Frank