bugtraq - Re: Is predictable spam filtering a vulnerability?

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 24 Jun 2004 19:42:56 +0000
From: "The Fungi" <fungi@...goth.org>
To: bugtraq@...urityfocus.com
Subject: Re: Is predictable spam filtering a vulnerability?


On Wed, Jun 23, 2004 at 10:07:31AM -0700, Sean Straw / PSE wrote:
[...]
> 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@...goth.org); IRC(fungi@....yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi@...goth.org);
MUD(Nergel@...ud.net:2325); WWW(http://fungi.yuggoth.org/); }