forged localhost sender test

I periodically review the trickle of junk that gets through my spam 
filters.  I've put it off for a while since I recently moved and have a LOT 
of stuff to deal with - ignoring the spam doesn't take too much time since 
I already filter the heck out of my mail and spam generally ends up in the 
otherwise empty unfiltered box, or in my "random contacts to my list 
address" which is my singularly most spammed address.  In returning to work 
though, the cruft is annoying.
In recent months the technique of submitting messages using a forged SMTP 
EHLO greeting seems to have taken a sharp rise.  This technique has been 
used for about three years now, but nowhere near as often as recently, and 
I mean for SPAM - viruses have used it for a while as well, though I filter 
for viruses at a global procmailrc and so they're not part of the 
statistics I see for "junk".
Via this method, the submitter APPEARS to be submitting from your host 
(even though the actual host and IP as looked up during the SMTP exchange 
do not match), whether the From: or even envelope addresses claim to be 
from your host/domain.  Often, they're using the IP as the hostname in the 
EHLO instead of the hostname itself.  In any event, we can't simply discard 
mail because the EHLO doesn't match the IP - DNS being what it is, there's 
a number of reasons this could occur and still not be a positive indication 
of forgery (though it really should never occur from your OWN host of 
course!).  Sendmail already flags such mismatches with "may be forged", and 
I have a small spam score elevation for that event.
Some months ago, I added a "RELAYHOST" determination to my standard 
procmail config, which I used for subsequent DNSBL checks.  I've since 
updated the sandbox template as published on my site, which is where you 
can see the RELAYHOST extraction process (an invocation of formail to nab 
the topmost received: header, and a few match operations, nothing magic at 
all).  If you've got some hinkey MTA, you may need to change the syntax 
used in the match constructs - they're based on the very common sendmail 
Received: format.

The forged localhost submission recipe is quite basic -- you check the 
RELAYHOSTEHLO variable against known IPs and hostnames for your 
localhost.  For people running their own little host, this is VERY 
straightforward, but if even if you're on some commercial hosting service, 
chances are the IPs you're expected to receive email on (AT THAT HOST) are 
limited, as are the hostnames the system is known by (try 'host -t MX 
your_domain' - and the lowest MX score should be the one where your mail is 
being processed at, 'host -t A your_mx_host' to get the one or more IP 
addresses associated with that host, and 'host -t PTR your_mx_host_ip' for 
each IP to get the hostname associated with the RDNS for the IPs).  If the 
message appears to have this host in the greeting, then the recipe 
progresses to the second condition - checking that the known host IPs match 
the IP used in the connection for the mail host.  'localhost' should be 
included in the RELAYHOSTEHLO check, and 127.0.0.1 (the localhost loopback 
IP) should be included in the RELAYHOSTIP check, since local submissions 
should be checked as well.
Users on some dyndns setup (running SMTP on dyndns?  ick!) will likely have 
a config nightmare for this since your IP isn't consistent.  This config is 
inappropriate for fetchmail setups where you're retrieving your messages 
from a remote POP/IMAP host and re-injecting them locally (in which case, 
the topmost received should always be your host and will be legit, or 
perhaps it'd be your ISP mailhost, which still should be legit).  If you 
tinkered with the RELAYHOST variable extractions to get the correct 
Received: header to work with, then the recipe would be functional for 
fetchmail setups.

# 20041212 - forged localhost submission (claiming to be from the MTA system,
# but in actuality being submitted from a foreign IP).
# This recipe relies upon the RELAYHOST variables having previously been
# initialized.
# the RELAYHOSTELHO should match against all known aliases for your host
# - the IP(s), the hostname(s), and localhost.  RELAYHOSTIP should be the
# IPs and localhost IP (127.0.0.1).
:0
* RELAYHOSTEHLO ?? (w\.x\.y\.z|(mail|smtp)\.somedomain\.tld|localhost)
* ! RELAYHOSTIP ?? (w\.x\.y\.z|127\.0\.0\.1)
{
        SPAMVAL="+200"
        SPAMMISHNESS="${SPAMMISHNESS}${SPAMVAL}"
        SPAMNOTES="${SPAMNOTES}SPAM: ${SPAMVAL} foreign sender using our 
hostname or IP for submission${NL}"
}

Running this in a sandbox against my spam corpus and regular mailbox 
resulted in a 0 false-positive rate.  Running it against my virus corpus 
resulted in a hit rate in excess of 45%.
I'm _not_ making the claim that this recipe is going to get rid of gobs and 
gobs of your spam.  What it does for me is isolates a number of the handful 
of messages that manage to slip past the rest of my spam filters (and since 
I'm using it as part of a "SPAMMISHNESS" score, it works in conjunction 
with other rulesets, not just on its own).  Somehow, last month I ended up 
with 44 spam messages which weren't caught by my filters because I've not 
been managing them for serveral months.  So far this month, 15 already.  A 
third of those get nabbed by this recipe (and another third are legitimate 
forwards from an account on another host which doesn't pre-filter, so they 
don't match the criteria in any event).
Comments?
---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.


____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail