Message-ID: <44C540F2.9764.E54972@stuart.cyberdelix.net>
Date: Mon, 24 Jul 2006 21:51:46 +0100
From: "lsi" <stuart@...erdelix.net>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: throwing the book at spam

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@...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@...erdelix.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/

Powered by blists - more mailing lists