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]
Date: Thu, 24 Jun 2004 13:32:47 -0700 (PDT)
From: "Michael A. Dickerson" <mikey@...gingtree.com>
To: bugtraq@...urityfocus.com
Subject: Re: Is predictable spam filtering a vulnerability?


On Sun, 20 Jun 2004, Luca Berra wrote:
> 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.

That's right .. and I agree with David.  In my environment, there are only
two responsible ways to do spam filtering:

1. You can deliver all messages to the mail client and let the client
decide what to do with them.  You can mark suspected messages as spam,
deliver them to a different folder, etc. but a human must have access to
them so that, at the very least, when somebody calls on the phone and
says, "Didn't you get my email," it can be found.

2. If you or your users are too lazy for #1, you have to put up the money
to do your filtering inline with the SMTP transaction, BEFORE the MTA has
returned a success code indicating acceptance of the message.  Then real
mail, relayed by a real SMTP server with a real envelope sender, will get
an immediate bounce message that they can respond to.  As others have
seen, spambots will ignore the failure code and nobody cares.

If you are too lazy to do #1 and too cheap to do #2, then you have set up
a system that *will* drop important messages in a silent and untraceable
way.  I have a hard time imagining an environment where that is OK.  If
you don't care whether an email gets delivered, why would you bother
writing it?  Then, as soon as a trustee sends the president an email that
disappears into the void, I will have plenty of time to explain the
(possibly very good) statistical performance of the spam filter to the
unemployment clerk.

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

This is meaningless; there is no way to guarantee that the envelope sender
is correct on ANY message, spam or not.

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

Nobody in research or industry has yet claimed an accuracy rate better
than about 98-99%, and that rate is only achieved by the most "serious"
and well trained spam filters yet devised.

M.D.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ