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

On Tue, 22 Jun 2004, Martin [iso-8859-2] Ma?ok wrote:

> > A spam filter MUST respond with a 500 SMTP failure code if it
> > rejects a message.

> What is your opinion based on?

Personal experience.

> I'm assuming you mean RFC 2821 (SMTP) -- by issuing "250 OK" to
> a message, SMTP server is accepting responsibility for delivering or
> relaying the message.

Yes.

[...]

> For me, not generating bounce message to spam/viral message is
> a reason valid enough to "break" RFC 2821.

I agree with silently discarding viruses, because false-positives are
practically unknown. Silently discarding suspected spam is very
bad, because false positives are reasonably common.

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

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

> IMHO 3: If user Joe gets 10 delivery failures of messages that he has
> not sent and one delivery failure of message that he has
> actually sent, it is worse than if he gets nothing.

This is indeed a problem, and it's a loophole that needs to be closed.
There needs to be a way for an SMTP server to correlate a bounce
message with a sent message, and reject the bounce message if it
wasn't caused by a validly-sent message. Proposals like SPF can help
a little.

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.

IMO, silently discarding mail that is suspected to be spam will only
further damage people's trust in the reliability of e-mail, which is
already very strained.

Regards,

David.

OK, I'll brave the storm of broken autoresponders one more time....

>> IMHO 3: If user Joe gets 10 delivery failures of messages that he
>> has not sent and one delivery failure of message that he has
>> actually sent, it is worse than if he gets nothing.

> This is indeed a problem, and it's a loophole that needs to be
> closed.

Unfortunately it's difficult for most people to close.

> There needs to be a way for an SMTP server to correlate a bounce
> message with a sent message, and reject the bounce message if it
> wasn't caused by a validly-sent message. Proposals like SPF can help
> a little.

A little. But there also is a need to _identify_ bounce messages.

A few years back, I got joed - some lamer forged my address into the
from-line of what appears to have been an entire spamrun. I got some
small number of thousands of bounces before I taught my mailer to pick
apart multipart/report bounces and reject them if the bounced message
doesn't show certain signs that all messages I send show. This helped
immensely, and when the modern crop of from-line forging malware showed
up, my defenses were already in place and functioning.

Today, I occasionally get bounces for malware with my address forged
into the fromline. I respond to them with a more or less stock
response that goes something like

If you _must_ do accept-and-bounce (something which is
increasingly "part of the problem" in today's net), please at
least make sure your bounces are proper multipart/report
bounces, so they can be mechanically identified and treated
appropriately. (See RFC 3462 for more on multipart/report.)

I've been doing this only a little while. If there comes to be a site
which is a persistent source of bounces and also persistently ignores
that request, I'm prepared to block it entirely.

/~\ 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