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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.58.0406222049440.7290@shishi.roaringpenguin.com>
Date: Tue, 22 Jun 2004 20:53:56 -0400 (EDT)
From: "David F. Skoll" <dfs@...ringpenguin.com>
To: Martin Mačok <martin.macok@...erground.cz>
Cc: bugtraq@...urityfocus.com
Subject: Re: Is predictable spam filtering a vulnerability? (silently dropping
 messages)

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.