From: Greg A. Woods (woodsweird.com)
Date: Fri Jan 02 2004 - 12:59:51 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[ On Friday, January 2, 2004 at 02:25:13 (-0600), Scott Dier wrote: ]
> Subject: Re: spamcop blocklist & SANS
>

BTW, it's a blacklist, not a blocklist. I.e. a list of sites thought
deserving of censure or punishment, sites stigmatized as untrustworthy.

> You obviously don't run a site where many of your users foward-through
> your site. I've seen a large site with many forwarding users get
> blocked by spamcop because of how their system forwards messages without
> preserving the Recieved: lines... spamcop lists them often enough these
> days to be more than annoying.

Well, actually, if I can guess at the reasoning behind the way SpamCop's
header processing works I think the goal is indeed to list the relay MTA
that's responsible for _originating_ the message. Not the user's MUA
client, and not any recipient MUA responsible for forwarding the
original "RCPT TO:" address through any aliases or ~/.forward hops, etc.

I.e. if your users use your authorised mail relay gateway to forward
their e-mail (as they should and you should require them to do so), then
the idea would be that if they start sending spam, through your gateway,
then SpamCop would list your gateway host's outgoing IP address(es) as
the true source of the spam since in fact it is the source and since
anyone using the SpamCop blacklist would have to block your relay host
in order to stop the spam your users are sending.

Such relay hosts should be appointed with facilities that allow their
administrators to locally enforce anti-spam policies and thus making it
possible to prevent any significant amount of spam from ever being
forwarded in the first place.

The problem is of course that it's damn near impossible to accurately
determine the true _originating_ M_T_A -- i.e. the one that would need
to be blocked in order to stop the spam -- from the "Received:" headers
alone, and that's the real reason why bl.spamcop.net should be
considered experimental.

One of my clients has very narrowly avoided being listed by SpamCop
several times recently. I'm not sure why but SpamCop mistakenly
identifies the client's PC address, not the relay host as it should.
Their gateway host really should have been listed, but luckily it was
not.

Ideally those submitting spam to SpamCop would either ensure that all
the "Received:" headers added by their own "local" aliases and
~/.forward hops would be complete with "for" sub-fields so that
SpamCop's parser can identify them as being added on the recipient end.
Unfortunately Postfix leaves a lot to be desired in this respect.

Alternately anyone submitting spam to SpamCop should strip all "local"
"Received:" headers off so that the first header is the one added by the
first host receiving the message on their behalf and thus identifies
directly the true source of the spam.

What I do when I forward spam to SpamCop is parse through my own local
headers (with some e-lisp code) and identify the true source of the spam
and I put that identifying information on the subject line of my
message. That probably doesn't help SpamCop, but it will hopefully
point out the culprit to any other contacts I also copy the message to.
I have been considering stripping off all the extraneous headers though.

> It's also a good reason never to strip off Recieved: lines. :)

Well actually stripping off "Received:" headers from messages forwarded
by a known MUA is a very good thing to do since they are almost
certainly forged if they exist -- unless of course your only goal is to
avoid being fingered by anyone as a spam source, but even then it won't
likely affect how SpamCop's parser sees the message (unless the forged
headers are _very_ good).

Note the "Received:" header added by your own gateway will identify the
MUA client host. In the case I mention above my client's gateway did in
fact write the first "Received:" header and it was that header which
SpamCop used thus mistakenly identifying their customer's PC, not my
client's relay host.

--
                                                Greg A. Woods

+1 416 218-0098 VE3TCP RoboHack <woodsrobohack.ca>
Planix, Inc. <woodsplanix.com> Secrets of the Weird <woodsweird.com>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]