[35488] in bugtraq
Re: Is predictable spam filtering a vulnerability? (silently
daemon@ATHENA.MIT.EDU (Sean Straw / PSE)
Fri Jun 25 01:13:00 2004
X-Envelope-From: PSE-L@mail.professional.org
X-Envelope-To: <bugtraq@securityfocus.com>
Message-Id: <5.1.1.6.2.20040623143643.093de500@mail.professional.org>
Date: Wed, 23 Jun 2004 14:48:10 -0700
To: bugtraq@securityfocus.com
From: PSE-L@mail.professional.org (Sean Straw / PSE)
In-Reply-To: <Pine.LNX.4.58.0406222049440.7290@shishi.roaringpenguin.com
>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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.
