[Scspamcop] Re: Who is the spammer trying to fool here?

[Mike Easter]

Geoffrey Hyde wrote:
>
http://www.spamcop.net/sc?id=z1378597901z9b6651aa237c2053eccf364a8e9744fbz

This is a misdirected bounce

  Abbreviated Received tracelines
  from smtp.mei.co.jp ([133.183.129.25]) by imta04ps.mx.bigpond.com
  from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by
smtp.mei.co.jp
  from epochmail.jp.panasonic.com ([127.0.0.1]) by mail.jp.panasonic.com
  from lomz85.jp.panasonic.com by soml23.jp.panasonic.com

Those are all valid lines which mail got into the .jp system by a
misdirected bounce.  The names MEI and panasonic all mean the same thing
in this context, pananet or Matsushita Electric Industrial Co

> SpamCop wants to report the traceline right after my ISP's mail
> server.  It apparently doesn't believe that chain testing the next
> line of this spamitem is going to get it a source IP address.

It is true that SC parses more 'strictly' for a mailhosted account, so
it is less prone to chain down thru' the headers.  For a nonmailhosted
account, SC parses down to the 2nd line, but that's when it runs out of
IP addresses.

In reality, both of the IPs 133.183.129.25 rDNS smtp.mei.co.jp and
157.8.1.150 no rDNS calling itself panasonic would be notified in the
same way by a human -- however, SC's notify for the 133 in this case
would be wrong, whereas the notify for the 157 would be correct, see
below.

The routing deputy is going to need to fix the problem for the algorithm
not being able to figure out to go to nic.ad.jp instead of arin or
apnic.

> If one were to believe the tracelines and assume that at least the
> second one is properly stamped and valid, maybe it would report
> [157.8.1.150] however I'm not even sure of this traceline to make
> that kind of assumption offhand.

The name of the server which initiated the misdirected bounce is
smtp.mei.co.jp

> I assume that the Returned Mail item in the body is a clever fake or a
> victim of spammer fraud itself.

The item in the body which bounce was misdirected to you is a .jpg spam
which has your addy in the From.  It is spamvertising bigpenis29.com

That original spam was sourced from an abused RR proxy

> Either way there's no use even
> trying to understand where that came from.  I've certainly never
> heard of an X-Received: line anyway.

The Xreceived line is just part of how the panasonic/mei.co.jp .jp
servers handled the item they received.  The SC munge prevents seeing
how it was addressed in the To, which isn't necessarily the basis for
the .jp servers getting it, as the server handling it is based on the
RCPT TO transaction, not the To: content.

> This tracker has been canceled, as I'm not sure whether to believe
> SpamCop's parse or not.

SC's notify for 133.183.129.25 in this instance is bad.  There is
something wrong with the algo.  SC queries arin and arin refers to
whois.nic.ad.jp but SC fails to pick up on the fact that it should be
going to nic.ad.jp and so it simply does a devnull instead of getting
the notify properly.  SC's notify for 157.8.1.150 is 'better' but not
good.  In the case of 157, SC gets an addy which bounces.

What SC *should* be doing is getting the contact from nic.ad.jp for
both/either of them.

whois -h whois.nic.ad.jp 157.8.1.150 ...
a. [Network Number]             157.8.0.0/16
b. [Network Name]               PANANET
g. [Organization]               Matsushita Electric Industrial Co., Ltd.
m. [Administrative Contact]     SO4680JP

a. [JPNIC Handle]               SO4680JP
c. [Last, First]                Ohta, Shirou
d. [E-Mail]                     ohta.shirou at jp.panasonic.com
g. [Organization]               Matsushita Electric Industrial Co., Ltd.

whois -h whois.nic.ad.jp 133.183.129.25 ...
a. [Network Number]             133.183.0.0/16
b. [Network Name]               PANANET
g. [Organization]               Matsushita Electric Industrial Co., Ltd.
m. [Administrative Contact]     SO4680JP

-- 
Mike Easter
kibitzer, not SC admin