At 21:15 2005-07-27 -0400, Chris Payne wrote:
The spam that I see arriving to my organization contains originating
RECEIVED headers originating DOMAIN NAME + ([IP address]) which do
not resolve to one-another.
# 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.
:0
* RELAYHOSTEHLO ??
^^(www\.xxx\.yyy\.zzz|(host|otherhost)\.domain\.tld|localhost)
* ! RELAYHOSTIP ?? ^^(www\.xxx\.yyy\.zzz|127\.0\.0\.1)
{
SPAMVAL="+200"
SPAMMISHNESS="${SPAMMISHNESS}${SPAMVAL}"
SPAMNOTES="${SPAMNOTES}SPAM: ${SPAMVAL} foreign sender using our
hostname or IP for submission${NL}"
}
RELAYHOSTEHLO and RELAYHOSTIP are extracted as per the code in my standard
sandbox template (see the url in my .sig). Two lines in the above recipe -
the first condition, and the SPAMNOTES assignment are both wrapped in this
email
This catches messages which have an SMTP greeting claiming to be YOUR
mailhost, your IP, or "localhost". If the submitting IP doesn't match your
IP or the actual localhost IP, then the message is flagged as suspect. An
alarming amount of junk trips this. As yet, no legitimate mail (since,
well, legit mail claiming to be from localhost WILL be from localhost, and
legit mail from your host WILL be from your host IP). This could be sticky
if you have a multihomed mail host and it uses a variety of IPs for mail.
This recent spam email for "body enhancement" contains
received: header entries showing "two hops" prior to arriving
to the University campus mail forwarder, which then forwards
the email to my mail server.
Another check I have looks for only ONE received header for externally
originated email - it's an indication that the message was submitted
directly from a spamhost. Legit mail from users outside of our host should
first pass to their mail host (even if only from their mail client to their
MTA) before being handed to mine. ONE HOP = SPAM.
Of course, plenty of spam has additional Received: headers intended to
throw off tracing the origin.
Received: from amrer.net ([211.195.195.78])
Received: from oceanebi.com (sitemail.everyone.net [209.249.170.32])
- - - - - - - - -
Neither of these received headers IP addresses resolve
exactly to the listed domain names beside the IP entryies.
That's basically what sendmail flags "may be forged" in the
locally-generated Received: header.
However, the second line does resolve to a different server
on the 'everyone.net' domain.
Not unusual. Plenty of servers are configured with multiple hostnames and
only ONE of those is in the rDNS. What does that hostname FORWARD resolve to?
$ host oceanebi.com
oceanebi.com. has address 63.217.142.5
$ host -t MX oceanebi.com
oceanebi.com. mail is handled by 10 sitemail.everyone.net.
(other checks show their NS and IP assignments are through some outfit in
Reston, VA)
$ host sitemail.everyone.net
sitemail.everyone.net. has address 216.200.145.51
sitemail.everyone.net. has address 209.249.170.32
sitemail.everyone.net. has address 209.249.170.33
sitemail.everyone.net. has address 216.200.145.35
$ host sitemail.everyone.net | sed -e "s/^.*address /host /" | sh
33.170.249.209.in-addr.arpa. domain name pointer white-2.inmx.everyone.net.
35.145.200.216.in-addr.arpa. domain name pointer sitemail.everyone.net.
51.145.200.216.in-addr.arpa. domain name pointer sitemail.everyone.net.
32.170.249.209.in-addr.arpa. domain name pointer white-1.inmx.everyone.net.
If one were to scan the Received headers(top-> down) which are not
from your own domain(you who received the mail), then these entries
could be used to kill spam.
Several SpamAssassin rules already do this. Unfortunatley, when
aggressively used, they also reject mail from people who are using
broadband and submitting mail to their own broadband ISP - the hunt for
headers locates broadband IP space and flags the message, even though it
was submitted legitimatley.
I do flag consumer broadband submissions - when that's the host which
directly submitted to MY host.
Using the FROM: line is a waste of time, since a lot of people send
legitimate email from their home internet ISP's addressed as though
it were from their work accounts, when they work from home.
Bummer these turkeys can't figure out how to use VPN, or can't establish an
SSH tunnel to a server at their office (which is how I send mail when on
the road).
I'm still quite novice with Procmail scripting, maybe someone on the
list could quickly assemble a sample script for everyone ? Would
the assumption be correct to check for matching in the headers.?
Matching hosts to IPs is generally a waste of time because too often they
won't. I mildly score messages which sendmail flags as "may be forged".
---
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