procmail
[Top] [All Lists]

Re: junk email header

1998-01-16 10:12:16
At 07:36 AM 1/16/98 CST, Don Hawkinson wrote:

Is there anything in the following header that would identify it as junk
email?

DATE: 16 Jan 98 6:02:31 AM

Not relating to spam detection, but this date is goofy.

From: 0Vt3pYIbi(_at_)prodigy(_dot_)com
Reply-to: ddd2961(_at_)prodigy(_dot_)com
Message-ID: <jJC8duq(_at_)4ukg8A96lmhg8>

See the recent discussion about juno/hotmail/prodigy/aol filtering -- it
would have caught this because the Message-ID on these services should
contain the domain portion matching the From: address.

This From/Message-ID relationship does not hold true with ALL domains
(virtually hosted domains use a server from the host ISP, and so the
message-ID can often contain that host's domain name).

Received: From sony300 by ibm266;Fri, 16 Jan 1998 6:2:31 -400 (EDT)

Not easy to pick it out with a filter, bu this is a totally BS received line.

SUBJECT: secrets of making money now

Killfile the subject phrase:

SPAMSUBJ=$SPAMDIR/subj.dat

:0
* $? $FORMAIL -xSubject: | $FGREP -i -f $SPAMSUBJ
{
        LOG="SPAM: Subject Phrase Match$TWITVER"

        :0:
        |gzip -9fc>>$MAILDIR/twits.gz
}

(I have variables defined for paths and paths to executables)

Then add lines or keywords to subj.dat to have filtered out (note: this
will usually get rid of all threads in discussion groups on a posted spam
as well, unless someone changes the subject line - I generally find this to
be a plus).

Additionally, if you subscribe to the massively-malformed Message-ID rule,
you should note that this Message-ID doesn't conform to the norm (most
messageIDs contain a domain portion of some sort).

:0:
* ! ^Message-ID:.*@
looks_like_spam

(I don't presently do this myself because of broken mailers that do this BS)

X-UIDL: 5a0246e04e1341cd527dedb7e196eed1

Unless you're fetching mail using fetchmail or a similar utility, from a
POP which adds these headers, I've found that X-UIDL is used 100% for spam
- the spammer adds it to their message BEFORE sending it (whereas X-UIDL is
supposed to be added by the POP server, and shouldn't normally be seen by
procmail, which sees the mail BEFORE the spool, which is where the POP
server pulls messages from).  Check your mail to see if you normally have
this header in your messages or not.  Or run a test filter for a while.

I happen to fetch mail from another account to consolodate my mail in one
place, plus to run my filters on the otherwise POP-only mailbox.  That
service doesn't add X-UIDL.  My mail server does (remember, POP comes after
local mail filtering), but I've modified it to use X-XUID (_stored_ into
the headers, but X-UIDL is still reported to the mail clients when fetching
UIDL information).  Works like a champ, and doesn't interfere with my
ability to check for X-UIDL in the POP mail client if I so choose.

:0c:
* ^X-UIDL:
could_be_spam

(this makes a copy, and files it - you can come back and take a look at the
file after a while and see whether it contains just spam or not, and remove
the 'c' (copy) flag if you decide to make the filter active).

---
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.

 Sean B. Straw / Professional Software Engineering
 Post Box 2395 / San Rafael, CA  94912-2395

<Prev in Thread] Current Thread [Next in Thread>