At 02:07 PM 6/2/97 +0000, Matthew G. Saroff wrote thusly:
I got the following email spam.
Bummer for you. Until it appeared here, I hadn't gotten it. :(
I can't figure out the header. If anyone could figure out a
decent procmail script for this and where this excrement actually came
from, please tell me.
No specific script, but see my comments below.
Normally, I would not quote a message verbatum, but there is an
800 number in the message. Call and leave a message explaining how you
will never buy from spammers.
Suggestion for you then: [CLIP] the message body to just the paragraph
where the phone number/company info is shown. Otherwise, you serve to
disseminate the spam message for the spammer, which is a BadThing(tm).
I'm not a MailMaven, so some of the following may contain TECHNICAL
inaccurracies.
Now, as to the header, you can be sure that a vast majority of the received
headers are bogus. By all accounts, the first two received lines (those
involving pacbell.net) are the only valid ones, and the spammer was
connected to a pacbell dialup. This information, along with the date/time
of the message, provided to abuse(_at_)pacbell(_dot_)net (I assume that's their
address) should help to identify the spammer to pacbell.
When looking at headers, what you should do is find the one which delivered
to you, then get the FROM, and locate the header which contains it as the
BY. Repeat the process until you reach an endpoint. Note dates and times
while you do this. This of course doesn't generally identify WHO really
did send the message, but it should show the path the message took. Extra
(bogus) headers can be inserted even by inexperienced spammers (and with
programs doing most of this for them, it is that much less uncommon).
Doing this, I confirmed that the originating dialup entry (the ppp-206...
one) exists by pinging it. Since that is a dialup IP, not an SMTP host,
the received headers which follow it are all bogus.
Also, the mere name entries in the other received headers are bogus (cmon,
LAPD!.com, i_b_m.net?). The date/time info in those received headers is
also bogus. And they also don't "link" in any way to the recieved headers
at the top.
These days, with the exception of forwarded mail, delayed mail (when your
mail server is down), (and some others), _most_ mail really only goes
through two SMTP hosts before reaching it's destination (that is, if gets
to an SMTP at your site, and generally comes directly from the SMTP host
where it was inserted). Excessive received headers are a sure sign of
something being amiss.
On the procmail filtering front - I keep thinking that it would be neat to
write a support utility that you'd hand a copy of the headers, and it would
do a DNS lookup on all the "by xxx" entries in the received by headers.
The program would keep track of how many of them fail, and return that as
it's return code. Thus, loads of bogus headers (as your message has),
would return a higher number, which would generally be indicative of SPAM.
This could be used as-is (nonzero, and you toss it), or to do weighting
(factoring it in with other things). Haven't had the time to do this
myself, but I sure would like to see it.
---------- Forwarded message ----------
Return-Path: email_5(_at_)pacbell(_dot_)net
Received: from mail-gw3.pacbell.net (mail-gw3.pacbell.net [206.13.28.55])
by pcans1.pca.net (8.6.12/8.6.9) with ESMTP id NAA19384 for
<msaroff(_at_)pcans1(_dot_)pca(_dot_)net>; Mon, 2 Jun 1997 13:59:36 GMT
From: email_5(_at_)pacbell(_dot_)net
Received: from reduce-taxes (ppp-206-170-26-163.sntc01.pacbell.net
[206.170.26.163]) by mail-gw3.pacbell.net (8.8.5/8.7.1) with SMTP id
GAA04021; Mon, 2 Jun 1997 06:53:41 -0700 (PDT)
---
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395