procmail
[Top] [All Lists]

Re: Multiple "Received: from" domains as spam flag?

1998-01-08 17:27:40
At 02:44 AM 1/8/98 -0500, Walter Dnes wrote:

Question... Assume that I handle subscribed mailing lists
at the beginning of my procmail mail filter.

All after any initial spam filtering, to catch spams relayed through your
favourite mailtool listserv, right?

Is there any other circumstance in which I should see email
being relayed to me via an intermediate site?  If not, then
2 or more "Received from: " lines in the message headers 
(excluding my own ISP, of course) is an excellent algorithm
for catching relayed spam.

Don't rely on this.  Several (though certainly not all) possibilities come
to mind:

        * Most mail has two recieved from headers - one for the originator
        to their mail server, and another for their server to yours.  At
        LEAST.  Unless they're on the same server as you.

        * Any site which isn't itself directly connected to the net
        (such as a mailserver in some small company which connects on
        demand to post mail to and retrieve mail from another server)
        will involve additional routing headers.

        * Messages intentionally routed through a specific path.  I happen
        to do this on some forwards between one domain and another to ensure
        that the mail passes through a server that can actually see the
        other server properly (due to mail config on one system (that I
        don't control) assuming that all subdomains are handled there too).

        * Messages which are mailed through a mailer exchange server.  Say
        your incoming mail server is taken down briefly for maintenance, or
        is otherwise unreachable because of a network fault.  If it has a
        mailer secondary (DNS MX records define these), then mail will be
        sent there when someone attempts to mail you something, and it'll be
        queued there until YOUR mail server comes back online.

        * It is not uncommon for corporate networks to have mail routing
        within them.  Say someone at the "Chicago office" mails a message out
        to someone on the internet.  That message may traverse the
        chicago server (recieved by it from the original user), then go to
        the corporate headquarters, then from there to your server, then to
        you.  Even some large national ISPs have multiple hops on their own
        mail networks (mail load balancing - some machines are for POP, some
        are for SMTP).

        * If you or someone else forward something from another host (via
        procmail or a simple .forward), you'll be adding additional routing.

        * If you fetchmail from another account, you'll add additional
        routing.

It is not uncommon for me to recieve messages with 7 or more recieved
headers in them.  Completely valid.  Try getting mail from the other side
of the planet sometime and see if it doesn't pass through an extra system
or two on its way to you.

 Some spammers add forged headers in an attempt to hide their
tracks.  As an extra bonus, the multi-Received: algorithm would
result in ordinary 1-hop spam being trapped because the forged
headers would make it look like a relay.

Many spammers these days are simply resorting to theft of services and
injecting the message into an open SMTP server using a (fairly)
untraceable-to-them dialup account, only identified by the dynamic IP
address they connect through.

I don't think that true forgery isn't that common anymore.  Too much work
on the spammers part.   If you really wanted to examine that stuff, you
might note that the recieved timestamps on most all but the final delivery
on some spoofed spams are all identical to the date line of the message.
No seconds elapse or anything.


Nice idea though - some analysis of recieved lines is always in order for
detecting spam, but I don't think simple counting of them is going to do
much good.

[snip - counting]

I can't help you here (I don't do any counting operations in Procmail), but
I'm sure there are several people here that can.

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