Re: An interesting way to detect spam based on the proximity of the sender with the receiver

[Rich Kulawiec <rsk () gsp org>]

I read this report, and the very grandiose methods it outlines.  Apparently
the researchers are unaware that vastly simpler and far more effective
methods exist, and that it's been a BCP to use them -- for years.  Perhaps
if they had actually interacted with the senior people working in the field
prior to beginning their work they would have learned some of the rudimentary
principles of spam mitigation.

Example 1: Use the Spamhaus DROP list in perimeter routers/firewalls.
Drop all traffic - bidirectionally.

Example 2: If you have no need to receive SMTP traffic from country X,
then firewall it out.  I've done this (on various mail servers, in various
combinations) for anywhere between 0 and 16 countries.  It works beautifully
at very low resource cost -- vastly better than wasting resources accepting
SMTP connections and then deciding what to do with the traffic.  (In some
cases, I'm dropping all traffic, not just port 25.  In other cases, I'm
allowing port 25 traffic but dropping everything to 22.  And so on.) [1]

Example 3: Refuse all SMTP traffic from anything (a) lacking rDNS
(b) lacking DNS (c) lacking matching DNS/rDNS.  Refuse on pre-greeting
traffic.  Refuse on invalid/illegal MX.  Refuse on invalid HELO.  &Etc.
Anyone who can't manage to set up DNS/SMTP via specs that have been
around for decades is incompetent, lazy or stupid: there is no reason
to grant access privileges to incompetent, lazy or stupid people.

Example 4: Refuse all SMTP traffic from anything with generic/dynamic
rDNS.  There are a couple of projects which have compiled very accurate
lists and/or patterns of these.  All such traffic is zombie-generated spam
with precious few exceptions: the FP rate is below 1 in 10e6-10e7, which
is clearly far better than obsolete techniques like Bayesian scanners.

(Of course in examples 3 and 4, appropriate SMTP response codes 
and messages should be returned so that the sending side has a clue
what happened.  FP's do happen, occasionally, with any method.  As to
temporary outages.)

And so on.  So I classify this research as "an academic curiousity,
but quite naive and completely out-of-touch with BCP". 

---Rsk

[1] I've also made some limited use of split-view DNS in order to provide
a different set of MX records to certain countries -- records which
point to MX's which will only accept connections from those countries.
This takes a bit to set up, obviously, but it does allow for custom
processing of such traffic.  An informal way of describing the policy is
"if you're a neighbor, go here; if not, go stand in line over there".
This expedites service to hosts likely not to be spammers and delays
service to hosts that are probably just sending spam anyway.  It also
isolates the occasional DoS attack, which is why I prefer it over just
implementing these differential policies on individual mail servers.
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.