|
|
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 24 2004 08:32PM Michael A. Dickerson (mikey singingtree com) 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 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 |
[...]
> If the envelope sender is faked, then rejecting the message at SMTP time
> (say, due to a DNSBL check) will result in an NDN directed at that faked
> address anyway, excepting when the sending mail host is really a zombie PC
> or spamware to begin with, in which case it'd be dropping the NDNs into the
> ether. The chief difference is that with an SMTP time rejection, YOUR mail
> server doesn't _deliver_ anything - the server which was attempting to
> deliver the message to you would be responsible for delivering the bounce
> based on your SMTP replies during the transaction.
[...]
We get around this problem at work by performing recipient address
verification on our primaries and using cached call-forward
recipient verification on our secondaries. When a secondary server
receives a message destined for an address it hasn't seen recently,
it will try to reach the primary and find out if the address will
accept mail before returning either 250 or 550 to the sender. If it
can't contact the destination immediately, it will elect to defer
the message like a secondary would normally. This is all done using
the "callout" feature in Exim v4. The only time this has become an
issue for us is when our primary is under a denial of service from
an incoming spam flood or is otherwise offline, in which case the
secondary still has to try (in vain usully) to send NDRs to the
spammers afterward. Of course, we are not employing any spam
filtering that results in NDRs or rejection of messages (we filter
them into separate mailboxes), so this has not been an issue for us.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi (at) yuggoth (dot) org [email concealed]); IRC(fungi (at) irc.yuggoth (dot) org [email concealed]#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi (at) yuggoth (dot) org [email concealed]);
MUD(Nergel (at) srmud (dot) net [email concealed]:2325); WWW(http://fungi.yuggoth.org/); }
[ reply ]