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