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-next>] [day] [month] [year] [list]

Date: Wed, 23 Jun 2004 14:48:10 -0700
From: PSE-L@...l.professional.org (Sean Straw / PSE)
To: bugtraq@...urityfocus.com
Subject: Re: Is predictable spam filtering a vulnerability? (silently
  dropping messages)

At 20:53 2004-06-22 -0400, David F. Skoll wrote:
>I agree with silently discarding viruses, because false-positives are
>practically unknown.

Well, there are a LOT of crummy A/V approaches out there, and I've received 
more than one bounce based on something flagging a message as a virus 
because there's some keyphrase in it.  In fact, this is why most of the A/V 
notification lists ceased providing descriptions of viruses and instead 
just provide a link to their website where you can get detail -- because 
far too many cheezeball "virus" solutions triggered off of simple keyword 
phrases.

> > IHMO 1: If your filter decides the message is not worth a delivery
> >         it's not worth a bounce too.
>
>That's not correct.  I've had many legitimate emails rejected by overzealous
>spam filtering.

The same folks who write the overzealous spam filtering generally break a 
number of RFCs anyway.  Sending their notifications replies to the From: 
address instead of the envelope sender for instance.  Or rejecting messages 
from a contact which has regularly correspondend with their user.  Sending 
messages forged to be FROM the intended recipient (or, in some cases, 
forged to be from the original message author).

> > IMHO 2: If your filter does not do the job of filtering messages well
> >         and bounces back, it is just distributing his work to others
> >         and deserves to be repaired/changed or blacklisted (firewalled
> >         out by others).
>
>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.

>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.

>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.

---
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.
  Founding member of the campaign against email bloat.