Re: Routing issue reports me instead of spammer

Graeme Leith wrote:
> Jon (spamtrap) wrote:

>> I wonder if you could help me with a routing issue:

Just to re-iterate what Graeme has explained to address some additional
housekeeping and organizational and posting guidelines.

First, this wasn't a 'routing' issue, it was apparently a transient
parsing issue and you posted some partial headers to illustrate or
demonstrate your point, but it didn't illustrate the point as well as a
tracker would do, where 'tracker means 'tracking url'.

This is a tracker for a forged or contrived spam I created out of your
partial headers to demonstrate both a tracking url, and also to
demonstrate that SC currently parses those Received tracelines perfectly
well.

When SC parses an item, it puts this at the top of every parse

Here is your TRACKING URL - it may be saved for future reference:
http://www.spamcop.net/sc?id=z796657640zc32c9fc85104fd73607c05362b26c49bz

That tracker can be accessed by anyone to see both how the spam is
parsed, and also to see the entire spam.  So whenever you want to show
us something, you have the parser parse the item and paste the tracker
into your message which is discussing the item.

That tracker shows this now [before I cancelled the report]:

Report Spam to:
Re: 62.66.229.118 (Administrator of network where email originates)
   To: [email protected] (Notes)

This abbreviation below is how I like to discuss Received tracelines.

   Abbreviated Received lines *comment
   from mailsweeper.bbb.co.uk ([212.248.233.182]) by
EXCH1.corp.bbb.co.uk *serves you
   from superonline.com (unverified [62.66.229.118]) by
mailsweeper.bbb.co.uk *sourceline

You are asking why SC named 212.248.233.182 as the source -- but if you
will click the tracker above, you will see that presently SC doesn't
name that IP which handles your mail, but instead names the source
62.66.229.118 rDNS 0x3e42e576.adsl.cybercity.dk which is a proxified
user IP listed in cbl and scbl.

There is a faq on the parser naming your server instead of the correct
parsing at http://www.spamcop.net/fom-serve/cache/13.html  Why does
SpamCop want to send a report to my own network administrator?

The essence of the answer is whether or not SC can successfully parse or
chain from the upper 'from' field IP in the Received lines to the lower
'by' field domainname.

At the time you submitted the spam item to the parser, it could not,
most likely because SC was unfamiliar with the server functioning as a
relay.  At this time, due to the submission to relay testers and aging,
SC now is familiar and correctly parses the item to the source, as
demonstrated with the spam forgery.

The business of using mailhosts to solve these problems is a newer
addition to spamcop's parsing options.  Using correctly configured
mailhosts greatly reduces the chances of your own provider being named
as spamsource, and also helps with some other sources of errors.  When
you use mail hosts, SC 'tolerates' and trusts your own servers to be
relaying, and becomes much more intolerant or distrustful of any
preceding relays further down the chain to be relaying.

-- 
Mike Easter
kibitzer, not SC admin