Onderwerp: Re: Is predictable spam filtering a vulnerability? (silently

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.

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

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

Only if the sending host is running a real MTA. If it's ratware
talking to you, it won't do anything of the sort. _That_ is the real
gain of an SMTP-layer rejection over accept-and-bounce: it doesn't
generate DSNs when talking to ratware.

> Quite possibly back to some sod who has been joe-jobbed.

But in that respect it's no worse than generating a DSN yourself.
Better sometimes and no worse the other times - sounds like a win.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B