[SpamCop-List] Re: Head 'em off at the Headers

[Mike Easter]

rodxpam wrote:
> On the downside, misconfigured headers aren't a guarantee of spam, and
> header analysis isn't sufficient as a stand-alone solution."

My experience with discussing headers with people who post them here is
that the variations and noncompliance with which *normal* providers vary
their stamps of the Received tracelines is such that 'analyzing' headers
for correctness would not be a very useful strategy.

Here's how your article puts it in the table


Methods -- Pros -- Cons

Header Analysis -- Identifies headers that don't conform to RFCs, a
strong indication of spam -- Misconfigured hosts may be incorrectly
tagged as spam


I'll use my own provider as an example, because SC's parser has to deal
with its 'bozotic' headers routinely.  Just now I don't have an example
of an EL bozotic header, but here is a 'synthesis' of the kind of
problem, derived from a normal EL headerline I received today in a
non-spam from a friend.

Received: from sccmmhc92.asp.att.net ([204.127.203.212]) by
mx-a065b14.pas.sa.earthlink.net (EarthLink SMTP Server) with ESMTP id
1dqlxGA73NZFpN0 for <munged>; Tue, 26 Apr 2005 01:35:40 -0700 (PDT)

I call that particular configuration

Received: from rDNS ([sou.rce.IP.add)] by ho.st.na.me somestuff
morestuff; datestamp

and in the generic elements I've 'drawn' above, the RFCs require the
'ho.st.na.me' and the RFCs also require the semicolon after 'morestuff'
before the datestamp.

EL has been known to use some bird's name instead of ho.st.na.me and
also to sometimes leave out the semicolon before the datestamp.

> "Misconfigured headers";  is a technical term; evidently. It appears
> quite frequently in articles and posts by people sharing information
> about various Internet Protocols.

Very funny.  The problem with your 'misconfigured headers' is that as a
tool against spam it is unreliable because the ratio of false positives
and false negatives is so high as to make it unusable.  The only thing
useful in the 'header analysis' section is the 'brilliant' observation
that it is more efficient to look at header information, ie dnsbl/s,
than the body.

The most common thing spammers do to headers is add bogus headerlines,
and it is very simple to configure a properly configured headerline,
even tho' EL and other major providers mess it up frequently..

> The web site I mention above has a
> dozen or so examples

No it doesn't.  The link above is a magazine article and the entire
paragraph on header analysis I'll copy below my sig, because it doesn't
say very much.

> if you would like to learn about how to find
> email headers, what the contents mean and how spammers often
> "misconfigure" headers to make identifying the cretins difficult.

Thanks but I already know how to find headers and what the contents mean
and what spammers often do to headers.  That's why I'm questioning your
premise.

> If you read further on the cited page and it's links, "header
> analysis" and "stand alone" technical terms are also covered.

My current client side spamfilter is designed for my spam and it never
has a false positive and it catches almost 100% of my spam.  Its most
powerful feature in terms of spamcatching is its dnsbl/s.  The
contribution of its body filter and regex examination of the header for
'quirks' is insignificant compared to how often the dnsbl/s catch the
item.

-- 
Mike Easter
kibitzer, not SC admin

Header analysis

Header analysis scans for e-mail headers that deviate from
specifications outlined in RFCs. Many spammers will spoof headers to
make it harder for investigators to track down the source of the spam,
making malformed or spoofed headers a strong indicator of unwanted mail.
Header analysis is also more efficient than scanning a message body
because the headers are shorter. Like DNS queries, header analysis is
often incorporated into a larger heuristics engine.

On the downside, misconfigured headers aren't a guarantee of spam, and
header analysis isn't sufficient as a stand-alone solution.