Marc Perkel wrote:
> I had a friend make an interesting suggestion. He said, "Why not check
> the sending IP to see if it can receive anything on port 25?" The idea
> being that a spammer might be sending on port 25 but can't receive
> anying on port 25.
As a lot of other people have pointed out already, this is probably not
a good idea. But if you're going to do any sort of port-scanning as part
of a spam/ham scoring process you may find more valuable information by
scanning different ports. Personally I'd guess that *extremely* few
legitimate mail servers has unfiltered ports running "Microsoft Windows
msrpc", "Microsoft Windows UPnP" or "Microsoft Windows XP microsoft-ds"
(names returned by nmap -sV). Last time I "looked", quite a lot of spam
was delivered from hosts with those services unfiltered:
http://db.org/2004/06/07/origin-of-spam/#services
http://db.org/2004/06/14/origin-of-spam/#services
http://db.org/2004/06/21/origin-of-spam/#services
But as others have already told you; if you do this, please implement
some sort of cache.
A much simpler and less intrusive technique you may want to try is
using passive OS-fingerprinting, and either scoring on the result
or adding a header field for classifier fodder.
http://lcamtuf.coredump.cx/p0f.shtml
I use the former as part of my SMTP time scoring mechanism. All
messages delivered from clients p0f thinks are windows are given an
increased score.
Bob
