Re: SpamCop doesn't parse routing info correctly

Using cite marks per par instead of per line to prevent shortlines.

Tristan Miller wrote:

> I'm running into an odd problem where SpamCop fails to correctly
identify the source of an e-mail.

Correct.  SC breaks the parse chain prematurely on one of your examples
because of a noncompliant server.

> When I forward to SpamCop an offending e-mail that I received at my
personal account ([email protected]), SpamCop correctly
identifies the source as an IP at the University of Arizona.

Using SC to determine the source of this kind of mail is appropriate,
but you shouldn't be SC reporting these as spam -- I'm assuming that you
are not.

> My employer ([email protected]) is also on the spammer's mailing
list.  However, when they (or I) send their copy of the very same e-mail
to SpamCop, it fails to identify the source as the University of
Arizona.

Correct.  SC correctly parses yours at nothingisreal;  SC incorrectly
parses the worldsocialism because there is a noncompliant MTA mailserver
in the chain..

> This is very strange, since both copies of the e-mail contain the same
Received header giving a U of A IP (128.196.165.21 =
PUB-E3.AHSL.Arizona.EDU):

Yes, but there is a lot between the sourceline and the last MTA.  SC
trips on the way for worldsocialism because of a noncompliant server
line.  See abbreviated headers below.

> Both our domains, nothingisreal.com and worldsocialism.org, are hosted
by DreamHost.  The only major difference in our setup is that I use
fetchmail to download my mail via POP3 from mail.nothingisreal.com and
deliver it to a local mail server, whereas my employer checks mail via
IMAP on mail.worldsocialism.org.

The headers are distinctly different.

> Here is the version I received which SpamCop correctly parses.

  Abbreviated Received tracelines *comment
  from localhost (localhost [127.0.0.1]) by polecat.worldsocialism.org
*serves you
  from mail.nothingisreal.com [208.97.132.24] by localhost *serves you
  from (web35715.mail.mud.yahoo.com [66.163.179.169]) by
randymail-mx2.dreamhost.com *serves you
  from [128.196.165.21] by web35715.mail.mud.yahoo.com *sourceline

SC correctly parses those lines by chaining from each upper 'from' field
IP to each lower 'by' field domainname.

> Here is the version my employer received which SpamCop doesn't
correctly parse.

  Abbreviated Received tracelines *comment
  from enforcer.dreamhost.com [66.33.220.4]) by
randymail-mx1.dreamhost.com *serves recipient
  from localhost (localhost [127.0.0.1]) by enforcer.dreamhost.com
*serves recipient
  from enforcer.dreamhost.com ([127.0.0.1]) by localhost *serves
recipient
  from hesl01uker.he.local (smtpout.btconnect.com [213.123.26.90]) by
enforcer.dreamhost.com *serves recipient, funky helo
  from c2bthimr02.btconnect.com ([194.73.73.202]) by hesl01uker.he.local
*serves recipient, funky line
  from (web35715.mail.mud.yahoo.com [66.163.179.169]) by
c2bthimr02.btconnect.com *serves recipient
  from [128.196.165.21] by web35715.mail.mud.yahoo.com *sourceline

SC incorrectly parses those lines because it breaks the chain
prematurely because of the funky  213.123.26.90 rDNS
smtpout.btconnect.com which is handling its Received traceline
non-compliantly.

It is calling itself hesl01uker.he.local in its line that it stamps # 5
from the top and SC cannot associate the IP with that name.  As a
result, SC cannot get past the IP 213.123.26.90 and 'has to' name it as
source.

If that recipient were reporting spam with spamcop, they would have to
configure themselves with mailhosting, because SC would always name that
server as the source of any mail with such headers.

In the above headers, the item goes from source 128 > mud.yahoo >
btconnect > dreamhost

The bad server line belongs to btconnect.

In your headers, the item goes from source 128 > dreamhost without the
intervening btconnect, so the bad line does not appear in your headers.

-- 
Mike Easter
kibitzer, not SC admin