[35452] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Is predictable spam filtering a vulnerability?

daemon@ATHENA.MIT.EDU (Luca Berra)
Wed Jun 23 12:03:45 2004

Date: Sun, 20 Jun 2004 15:52:00 +0200
From: Luca Berra <bluca@comedia.it>
To: bugtraq@securityfocus.com
Message-ID: <20040620135200.GA24947@percy.comedia.it>
Mail-Followup-To: bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58.0406170727510.5272@shishi.roaringpenguin.com>

On Thu, Jun 17, 2004 at 07:28:45AM -0400, David F. Skoll wrote:
>On Wed, 16 Jun 2004, R Armiento wrote:
>
>> However, 'C':s spam filter silently drops the email.
>
>In my opinion, any spam filter that silently drops e-mail is broken, and
>is indeed a security risk.  A spam filter MUST respond with a 500 SMTP
>failure code if it rejects a message.
>
David,
the problem with your proposed behaviour is the fact that to be able to
respond with 5xx in the smtp transaction would require the spam filter
to analyze content on the fly.
This is a very resource intensive operation and usually people triyng
this approach will DOS themselves.
The most common approach for spam (content) filters is to queue messages
and process them later, in this case the filter MUST NOT generate a NDN,
since there is no way to guarantee that the envelope sender is not
faked.
I hold that after suitable training of the spam filter (this includes
generation of whitelists and such), dropping mail into oblivion is
perfectly safe.
I am speaking of serious spam filters, not regexps that match random
words in the meddage contents.

Regards,
L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

home help back first fref pref prev next nref lref last post