Full Disclosure mailing list archives
Re: throwing the book at spam
From: "lsi" <stuart () cyberdelix net>
Date: Mon, 24 Jul 2006 21:51:46 +0100
Thanks for the feedback Valdis: - the IP address is only reversed if the Received: line does not contain a reversed name (which will be placed there if reverse lookup is enabled on the receiving server, and the name could be reversed). Since reverse lookup is enabled on my servers, a fail here means that the lookup has failed twice. The chances of this happening on a non- spammy email are small*. In the case of RFC1918 networks, this should not cause a problem as a legit host will present a name to (or be successfull resolved by) a legit mailserver*, even if they are using private addressing. - the SMTP server is only resolved if multiple received: lines are in use. This is because the last received: line is our own server, if there are no others then only our own server was involved, and we trust that. Also, only the first server in the chain is resolved. In the case of RFC1918 networks, this test could fail to work correctly if the machine is internal. This could be addressed by ensuring to use the last received: line with a public IP. - split-view DNS - no comment, I haven't a clue on that. My (quick) research told me that a) this was a new thing related to DNSSEC, and b) it was way over my head.. surely this means DNSSEC will break all applications that use reverse lookups? If I can't depend on my DNS results, where am I? - temporary DNS outage - unlikely, could be fixed with a test lookup before we start (and possibly during..) - not yet implemented, but upcoming are some extra tests on the Message-ID and Return-Path fields that will improve the cleanup rate... * these assumptions rely on the fact that this filter runs last - a message only gets munched by this filter if all the other filters have left it alone. Only unknown senders are involved, who do not match on any whitelisted subjects or addressees. I've been using it for a week, will audit the log soon .. ;) Stu On 16 Jul 2006 at 20:35, Valdis.Kletnieks () vt edu wrote:
Note that these tests are *very* hard to get right. In particular, they tend to fail spectacularly if you don't allow for the fact that many times, the mail originates inside an RFC1918 private network, so trying to resolve the IP addresses will fail. There's also a lot of other ways this can bork up if at any time a split-view DNS was involved, or there is/was a temporary DNS outage....
On Sun, 16 Jul 2006 11:33:32 BST, lsi said:These tests are fairly self-explanatory, with the exception of the analyse_received test. This test analyses the significant Received: headerline inside each mail (there are usually several Received: lines, but only one is relevant for our purpose). Any mail with an invalid Received: line is deleted. The tests for validity are as follows: IP_missing IP_obfuscation IP_unreversible by-line_not_present sending_SMTP_server_unresolvable sending_hostname_not_provided
--- Stuart Udall stuart at () cyberdelix dot net - http://www.cyberdelix.net/ --- * Origin: lsi: revolution through evolution (192:168/0.2) _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- throwing the book at spam lsi (Jul 16)
- Re: throwing the book at spam Valdis . Kletnieks (Jul 16)
- Re: throwing the book at spam lsi (Jul 24)
- Re: throwing the book at spam Valdis . Kletnieks (Jul 16)