|
BugTraq
Is predictable spam filtering a vulnerability? Jun 16 2004 11:26AM R Armiento (rar_bt armiento se) (7 replies) Re: Is predictable spam filtering a vulnerability? Jun 17 2004 05:27PM Joel Eriksson (je-secfocus bitnux com) (3 replies) Re: Is predictable spam filtering a vulnerability? Jun 18 2004 08:57PM Jason Coombs (jasonc science org) Re: Is predictable spam filtering a vulnerability? Jun 18 2004 06:52PM PSE-L mail professional org (Sean Straw / PSE) RE: Is predictable spam filtering a vulnerability? Jun 17 2004 02:18PM Aaron Cake (aaron vltpm com) (1 replies) Re: Is predictable spam filtering a vulnerability? Jun 21 2004 01:23PM Chris Brown (chris wavetex com) Re: Is predictable spam filtering a vulnerability? Jun 17 2004 11:28AM David F. Skoll (dfs roaringpenguin com) (4 replies) Re: Is predictable spam filtering a vulnerability? (silently dropping messages) Jun 22 2004 02:20PM Martin Maèok (martin macok underground cz) (2 replies) Re: Is predictable spam filtering a vulnerability? (silently dropping messages) Jun 24 2004 07:15AM Valdis Kletnieks vt edu Re: Is predictable spam filtering a vulnerability? (silently dropping messages) Jun 23 2004 12:53AM David F. Skoll (dfs roaringpenguin com) (2 replies) Re: Is predictable spam filtering a vulnerability? (silently dropping messages) Jun 23 2004 10:46PM der Mouse (mouse Rodents Montreal QC CA) Re: Is predictable spam filtering a vulnerability? (silently dropping messages) Jun 23 2004 09:48PM PSE-L mail professional org (Sean Straw / PSE) (2 replies) Re: Is predictable spam filtering a vulnerability? (silently dropping messages) Jun 25 2004 07:49PM der Mouse (mouse Rodents Montreal QC CA) Re: Is predictable spam filtering a vulnerability? (silently dropping messages) Jun 25 2004 05:35PM Seth Breidbart (sethb panix com) Re: Is predictable spam filtering a vulnerability? Jun 20 2004 01:52PM Luca Berra (bluca comedia it) (3 replies) Re: Is predictable spam filtering a vulnerability? Jun 23 2004 05:07PM PSE-L mail professional org (Sean Straw / PSE) (2 replies) Re: Is predictable spam filtering a vulnerability? Jun 24 2004 07:42PM The Fungi (fungi yuggoth org) Re: Is predictable spam filtering a vulnerability? Jun 24 2004 05:44PM John Fitzgibbon (bugtraq jfitz com) (1 replies) Re: Is predictable spam filtering a vulnerability? Jun 25 2004 05:08AM PSE-L mail professional org (Sean Straw / PSE) Re: Is predictable spam filtering a vulnerability? Jun 19 2004 02:56PM Kyle Wheeler (kyle-bugtraq memoryhole net) Re: Is predictable spam filtering a vulnerability? Jun 19 2004 12:49AM Jon Fiedler (jmf9 cwru edu) (1 replies) Re: Is predictable spam filtering a vulnerability? Jun 19 2004 01:29AM David F. Skoll (dfs roaringpenguin com) RE: Is predictable spam filtering a vulnerability? Jun 17 2004 08:26AM Hamlesh Motah (admin hamlesh com) Re: Is predictable spam filtering a vulnerability? Jun 17 2004 08:21AM Ilya Sher (ilya79 actcom net il) |
|
Privacy Statement |
> 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.
[ reply ]