[SpamCop-List] Re: Backscatter

[Frank Ellermann]

McWebber wrote:
 
> LDAP is not an accounting database. Many systems,
> with multiple MX use it.

Another system I've heard of is a kind of relay test:
Like "call-back-verification", only forward to the
RCPT TO at the next hop instead of backwards to the
MAIL FROM.  It has some obvious timing issues, the
sender won't wait forever for an "okay" or "error"
after the RCPT TO.

Probably LDAP has similar problems.  It defeats the
idea of a backup MX, it should take over when the
main site incl. primary MXs and LDAP is unavailable.

>> But the default for all identified worm should be
>> "don't bounce".  Dito for spam.
 
> Unfortunately, it's not. Which is why a lot of
> backscatter is getting reported.

From SC's POV the only problem with these reports is
that they are almost identical to any "unavoidable"
backscatter.  SC is only a script, it's smart enough
to get "bounce" vs. "spam" right, but then it cannot 
identify "avoidable" vs. "unavoidable".

> Please cite the law.

Google says it's (de) "206 StGB Postunterdrückung":
<http://purl.net/net/de2en/lawww.de/Library/stgb/206.htm>

> Is it then illegal in your country to have a catchall
> address?

Now I have a catchall address.  That's why I'm interested
in this thread and SPF.  One spammer decided that this is
also a good time to forge my addresses sgain, I got about
160 backscatter mails today (the first major attack after
about 10 months).

Reporting this crap with SC is now very simple.  I have a
FAIL sender policy, so it is 100% "avoidable" as soon as
the forged MAIL FROM appears in the SMTP dialogue.

> You would then receive the misdirected email and do with
> it as you please, including deleting it.

Yes, I know all the fun with catchall addresses, especially
Message-IDs.  All reported via SC and deleted, no problem
if I do it.  My mail provider would have a problem if he
accepts and deletes mail for me without telling me.  It's
not different for catchall addresses.

> Not "bouncing" to the forged sender causes no abuse to
> any innocent party.

First you have to _know_ that it's forged.  Or at least to
guess, e.g. worm => default forged => delete.  And it's not
always possible to get this right without a sender policy.

E,g. if something in your setup decides "over quota", and
therefore you never check what it is (a worm), then you're
not in the position to decide "forged".

The only place to catch all forgeries is at the first MX,
if the forged sender publishes a FAIL sender policy, and
the first MX checks it.  Otherwise, if you hope to get it
right later, you depend on spam detection heuristics and
less reliable tricks, and that might file => bounce.

That's also what SC says in its FAQ about "misdirected"
bounces.  SC only forgot to enforce that senders really
must have a FAIL sender policy or a similar DKIM policy
before they can report all bounces.

There's no incentive for senders to protect themselves,
they can just report all bounces as spam without doing
anything on their side.  That will backfire, it's wrong.

  [bounce example]
>> avoidable.  Some outblaze mailer.
> Outblaze? goodname.net has nothing to do with Outblaze.

Yes, today it doen't mumble something about "outblaze"
in its greeting, probably I screwed up, s/net/com/ (?)
Tested again:

using MAIL.MOSTBOX.COM for goodname.net
20050801 12:42:39 TCP connection with MAIL.MOSTBOX.COM:25
42:39.91 220 mail.mostbox.com ESMTP
42:39.91 ehlo xyzzy.dnsalias.org
42:40.38 250-mail.mostbox.com
42:40.38 250-PIPELINING
42:40.38 250 8BITMIME
42:40.38 mail from:<abuse at xyzzy.dnsalias.org>
42:40.82 250 ok
42:40.82 rcpt to:<gggjhggg at goodname.net>
42:41.28 250 ok
42:41.28 quit
42:41.72 221 mail.mostbox.com

Avoidable, assuming that gggjhggg@ doesn't exist.  Bye