On noting patterns in spam attempts

[David Wolfskill]

Most of the stuff I do to block inappropriate use (i.e., "abuse") of
email at the MTA is fairly ordinary.  There are a couple of checks
with respect to the Message-ID header, though, that are a little
unusual -- and unlikely to be well-suited for all situations.

I have recently been noting patterns with respect to the mail rejected
by one of these mechanisms that may well help identify systems that are
likely to be used in atempts to vector additional spam (that might
not otherwise be intercepted).

The first is fairly simple:  once the Message-ID header is read,
its syntax is checked.  If the value of the header would match the
Perl regex

	/^\w+\@\w+$/

, fine.  If not, the message is rejected at the MTA:

	553 Message-ID must be an addr-spec; see RFC 2822

I'll admit that this is, perhaps, rather severe.  On the other hand, it
doesn't happen very often -- but every time it does, the available
evidence suggests that the message was spam.


The other is a bit more controversial -- in no small part because it
sometimes catches mail that is wanted: thus, it is appropriate to set
up "exceptions" for it.

For this one, we wait until all of the headers have been read.  Then, we
check to see if there's a Message-ID header that was specified.  If the
SMTP client is in one of our domains (or is one of the exceptions), the
message is not blocked at this point.  Otherwise, the message is
rejected:

	553 Unidentified messages are not acceptable here

Now, I realize that RFC 2822 says (among other things):

	3.6.4. Identification fields

	    Though optional, every message SHOULD have a "Message-ID:" field.
	    ....

Thus, the Message-ID field is not required, and this rejection on my
part violates the letter of the RFC, as well as the dictum "Be
conservative about what you send and liberal about what you accept."

I will make but one comment in my defense -- for the purpose of
this note is not to defend the approach, but to illustrate something
I think I've learned by deploying it:  if the message arrived at
my SMTP server without a Message-ID, and I later determine that it
was spam, I will report the spam to whoever is supposed to be
responsible for the machine that acted as an SMTP client.  Without
that Message-ID, there is no way to make a positive identification
of the message's transit of that system.

Now here's what I've seen that I find interesting:  spammers don't seem
to know how to cope with this.  Here's an excerpt from today's maillog
here at home:

Jul 24 01:11:45 janus sm-mta ... ruleset=check_eoh, ... relay=[61.77.232.38], reject=553 5.0.0 Unidentified messages are not acceptable here
Jul 24 01:11:45 janus sm-mta ... from=<5140ghxc at aci.net>, size=1762, ...
Jul 24 01:11:45 janus sm-mta ... to=<LENNON at ONLINEROCK.COM>, ...

Jul 24 01:11:58 janus sm-mta ... ruleset=check_eoh, ... relay=[165.246.189.33], reject=553 5.0.0 Unidentified messages are not acceptable here
Jul 24 01:11:59 janus sm-mta ... from=<5140ghxc at aci.net>, size=1762, ...
Jul 24 01:11:59 janus sm-mta ... to=<LENNON at ONLINEROCK.COM>, ...

Jul 24 01:12:07 janus sm-mta ... ruleset=check_eoh, ... relay=[61.77.232.38], reject=553 5.0.0 Unidentified messages are not acceptable here
Jul 24 01:12:08 janus sm-mta ... from=<5140ghxc at aci.net>, size=1762, ...
Jul 24 01:12:08 janus sm-mta ... to=<LENNON at ONLINEROCK.COM>, ...

Jul 24 01:12:18 janus sm-mta ... ruleset=check_eoh, ... relay=[211.209.23.36], reject=553 5.0.0 Unidentified messages are not acceptable here
Jul 24 01:12:18 janus sm-mta ... from=<5140ghxc at aci.net>, size=1762, ...
Jul 24 01:12:18 janus sm-mta ... to=<LENNON at ONLINEROCK.COM>, ...

Jul 24 01:12:27 janus sm-mta ... ruleset=check_eoh, ... relay=12-237-128-54.client.attbi.com [12.237.128.54], reject=553 5.0.0 Unidentified messages are not acceptable here
Jul 24 01:12:27 janus sm-mta ... from=<5140ghxc at aci.net>, size=1762, ...
Jul 24 01:12:27 janus sm-mta ... to=<LENNON at ONLINEROCK.COM>, ...

Now: based on the timing and the contents of the log, I think it's fair
to figure that it's very likely that what we see here are 5 consecutive
unsuccessful attempts to send spam to LENNON at ONLINEROCK.COM.  (I provide
some MX service for onlinerock.com.  And yes, the person who asked me to
do it has expressed appreciation for the spam-elimination I do.)

Further, a quick look at the would-be SMTP client IP addresses shows an
interesting variety:

* 61.77.232.38		KORNET-XDSL-SEONGNAM (KOREA TELECOM, Korea)
* 165.246.189.33	ITIS-NET (Inha University, Korea)
* 61.77.232.38		KORNET-XDSL-SEONGNAM (KOREA TELECOM, Korea) -- again
* 211.209.23.36		HANANET-CATV-SUNGNAMSO (Hanaro Telecom Inc., Korea)
* 12.237.128.54		ATT (AT&T WorldNet Services -- probably Comcast now)

I'm not much for betting, but I strongly suspect that the odds favor a
bet that each of these systems -- at the time of the aborted SMTP
conversation, anyway -- was an open SMTP relay.

So, lately, I've been augmenting access.db with blocks on the specific
IP addresses in question, with the message "Apparent open relay".

Of course, the above is not representative of the only pattern I have
seen:  I also see one-offs, as well as repeated attempts from the same
IP address (or netblock).  But the above is the pattern that I find most
useful.

And every once in a while, I find an attempt to deliver mail to my SMTP
server that is rejected because of one of these "apparent open relays".

Yours for helping squelch spam,
david
-- 
David H. Wolfskill				david at catwhisker.org
Based on what I have seen to date, the use of Microsoft products is not
consistent with reliability.  I recommend FreeBSD for reliable systems.