Much simplified lexer

[Matthias Andree]

michael at optusnet.com.au writes:

> Matthias Andree <matthias.andree at gmx.de> writes:
>> Locally-generated Received headers can be near-unique (they aren't on
>> some systems, inode numbers can be recycled for instance, these are only
>> unique for a given point in time), but they are not sent by the spammer,
>> and they are at least not surprising to the end user, hence they (the
>> locally generated headers at large) carry no entropy, they contain no
>> information.
>
> Sorry, that's absolutely wrong. A fair bit of spam that I get has
> a _single_ Received line. (i.e. the only one that's there is
> what my system added). It's stuffed full of good info.
>
> Received: from 1.2.3.4 (mctn1-7619.nb.aliant.net [156.34.21.199])
>         by funny.optusnet.com.au (8.12.8/8.12.8) with SMTP id hAC2vOQa029135
>         for <james at plastic.whatnot.net.au>; Wed, 12 Nov 2003 13:57:53 +1100
>
> The 1.2.3.4 comes from the spammer. You'll note they lied. The _real_ source
> is in the parenthesis following. The 'funny.optusnet' is my system. The
> 'james at plastic' is the spammer.

No, that's your local recipient address.

Anyways, there are situations where you're lucky to run your own
mailserver that receives directly from the network - you won't discard
such headers.

OTOH, if I'm pulling mail with POP3 or IMAP, then I'll have extra
Received: headers that are from my own mail fetcher or from my own
system. Filtering by content (only filter those systems' Received: lines
that don't receive directly from the spammer) looks feasible.

> That's your configuration, and it's a _relatively_ rare one. The
> common case is people POP'ing their mail straight of their ISPs mail
> server.

See above: two extra Received: lines. (for fetchmail, that is).

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95