Hi, On Tue, Mar 04, 2003 at 09:43:20AM -0800, Sis wrote: > On Sun, Mar 02, 2003 at 01:46:47PM +0100, Emile van Bergen wrote: > > > # This script is intended for use in .qmail files. It scans a message's > > # Received: headers for IP addresses and checks each IP address that is not in > > # an explicit permitted prefix list, against a configurable number of realtime > > # DNS blacklists. The headers are scanned using 822field from djb's mess822 > > # package; the DNS lookups are done using dnstxt from djbdns. > > I agree with your idea here, but aren't the Received: headers mostly > forged? I was recently "attacked" because some spammer used my domain > name as the return address for his spam and i got 10's of thousands of > bounced messages! Brought down my MTA! In case anybody on this list > hasn't already been convinced that spam costs real money, wait until > your domain name is forged. > > Maybe i missed it, but i didn't see code for checking the truth of > the Received: IPs? If an earlier MTA in the path adds all kinds of nonsense Received: headers, that won't matter, because they won't cause a message to be accepted if there is any Received: header that contains a blacklisted IP address. The idea is that at some point a message passes the border between a malicious and a trustworthy MTA. The latter will record the IP adress of the malicious MTA in a valid Received: header. So basically I reject every mail that is received by a non-forging MTA from a blacklisted machine. Of course, if a later MTA in the path goes on stripping headers or replacing all IPs by unlisted ones, I'll get a false negative, but I can hardly get false positives, as it's very unlikely that a message from a legitimate origin will at some point pass through a blacklisted MTA. It's just an extension of standard blacklisting, with the same faults and benefits. I just extend the principle to the whole chain. As said, the main purpose is allowing the 'trusted' 3rd party backup MTAs to be less strict in their RBL selection without them becoming a tunnel for spam. Cheers, Emile. -- E-Advies / Emile van Bergen | emile@e-advies.info tel. +31 (0)70 3906153 | http://www.e-advies.info
Attachment:
pgphoWACLFrkG.pgp
Description: PGP signature