Re: Is predictable spam filtering a vulnerability? (silently dropping messages)

[Seth Breidbart <sethb () panix com>]

PSE-L () mail professional org (Sean Straw / PSE) wrote:
> At 20:53 2004-06-22 -0400, David F. Skoll wrote:

> > A 5xx failure code is a lot more friendly than actually generating a DSN.
>
> Well, you're causing the sending/relaying host to generate the DSN.
> Quite possibly back to some sod who has been joe-jobbed.

Often enough, no.  For instance, the virus on Joe's infected PC sends
out 87 copies of itself forging me as the sender.  They get rejected
with 5xx.  The virus isn't going to send me DSNs.  (If there were a
forwarding system involved that accepted then bounced, it might; but
that's not the most common case.)

> > Proposals like SPF can help a little.
>
> On the surface, SPF seems really nifty, but it poses a significant 
> implementation issue for listserves and forwarding services alike.

Yes, it needs a little work done to address those cases.  I see two
general possibilities:

1. At the (final) receiving end, the configuration says "I set up
   domain X to forward to me, so check the Received header it added."
   This isn't the preferable choice, but it can be done unilaterally
   by the recipient.

2. Modify the protocol to specify that forwarders add a particular
   header, and SPF checks that header for the connecting machine, and
   possibly the included IP address for the actual sender.  We'd need
   to be careful to handle multiple-forwarding gracefully, of course.

> > One good thing is that spammers often use ratware that ignores
> > failure codes.  So a 5xx return code does *not* elicit a
> > DSN, whereas having your anti-spam box actually generate a DSN
> > is obviously bad.
>
> You're back to the problem that the Anti-Spam solutions are often
> implemented post-SMTP, so those using them have the option of either
> ditching the message or generating an (often undesired) DSN.  The
> anti-spam and virus solutions which are integrated at the SMTP level
> pose DOS issues for the mailhost because the message MUST be
> identified as spam or not spam right then and there.

Even if the choices are bad/good/unknown, with the latter being
handled post-smtp, moving possibilities earlier (that is, doing
whatever amount of checking during smtp you can do) will only be
helpful.

Seth