On noting patterns in spam attempts

Sat Jul 26 13:47:23 PDT 2003

Quoting David Wolfskill (david at catwhisker.org):
> 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.
...
> 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+$/

Per 822 (2822 came after my rules went in), message id's MUST MUST MUST
be in "<\w+@\w+>" form.
BRACKET SOMETHING @ SOMETHING BRAKCET.

> , fine.  If not, the message is rejected at the MTA:
> 	553 Message-ID must be an addr-spec; see RFC 2822

I block them with a generic "header error" (I'm not here to make
spammers smarter).  It can get 2-5% of all mail.

I did once block ill-composed email from a script devised by
someone who should have known better.  It was fixed forthwith.

Spamassassin will note when a message-id is added by a downstream
relay and add a point or two.

> 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.

I'm seeing 60% spam rates at a client.  severe is cost saving.

> 	3.6.4. Identification fields
> 	    Though optional, every message SHOULD have a "Message-ID:" field.
> 	    ....

I don't recall that in 822, but many messages will NOT have a message-ID
when coming from MUAs (especially when I compose via "telnet host 25" :)