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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <200406251735.i5PHZ1v05707@panix5.panix.com>
Date: Fri, 25 Jun 2004 13:35:01 -0400 (EDT)
From: Seth Breidbart <sethb@...ix.com>
To: bugtraq@...urityfocus.com
Subject: Re: Is predictable spam filtering a vulnerability? (silently
  dropping messages)

PSE-L@...l.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