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

Message-ID: <20040622142002.GB2855@josefina.dcit.cz>
Date: Tue, 22 Jun 2004 16:20:02 +0200
From: Martin Mačok <martin.macok@...erground.cz>
To: bugtraq@...urityfocus.com
Subject: Re: Is predictable spam filtering a vulnerability? (silently dropping messages)


On Thu, Jun 17, 2004 at 07:28:45AM -0400, David F. Skoll wrote:

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

What is your opinion based on?
Let me guess (correct me if I'm wrong, please).


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. In this meaning, it should not silently discard
the message. (The question could be, is delivering to a special folder
-- be it /dev/null or ~/mail/junk -- considered dropping or not ? ...)

On the other hand (RFC 2821): "a relay SMTP SHOULD assume that the
message content it has received is valid and, assuming that the
envelope permits doing so, relay it without inspecting that content."


SMTP filter (i.e. spam or AV filter) is not SMTP server (or relay) but
it is SMTP (application level) firewall (RFC 3234 - Middleboxes:
Taxonomy and Issues). In this mean, it can implement any "safe" subset
of SMTP and is allowed to break RFC 2821 for valid reasons (RFC 2979
- Firewall Requirements).

For me, not generating bounce message to spam/viral message is
a reason valid enough to "break" RFC 2821. Not doing so, we all end up
filtering delivery failures of messages that we have not really sent
(as I already have to do today :-/ ).


IHMO 1: If your filter decides the message is not worth a delivery
        it's not worth a bounce too.

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

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.


Martin Mačok
IT Security Consultant