Re: Fake Headers triggers Spamcop to send complaints to wrong ISP?

Benoit Panizzon wrote:

> I work on the Abuse Desk of Improware 157.161.0.0/16

I don't think your IP 157.161.238.32  no rDNS sourced this item.

> We just got a quite strange Spamcop complaint about spam sent from an
> IP that according to our data is was not allocated to any customer
> during the time that email was sent.

I think SC misparses the item you posted.  Here is a tracker to
represent it

http://www.spamcop.net/sc?id=z837711675zdcdadfd59bf4582072238795f290fda2z

If reported today, reports would be sent to:
Re: 157.161.238.32 (Administrator of network where email originates)
[email protected]

> I fear the whole Received: headers are faked, but don't manage to
> find out how spamcop is fooled by them. Usualy spamcop is quite
> sensitive in detecting fake MX chains etc...

SC misjudges an IP which is close to the MX & output server for
turbus.cl for being a relay.  That .cl IP is currently SC blocklisted
for hitting traps and reporters.

  Abbreviated Received lines *comment
  from smtp4.libero.it (193.70.192.54) by ims4a.libero.it *serves
recipient
  from wpopcp.libero.it (172.16.1.35) by smtp4.libero.it  *serves
recipient
  from (ipnat2.turbus.cl [206.48.149.132]) by wpopcp.libero.it
*sourceline
  from (mail.monmouth.com [209.191.58.1]) by ipnat2.turbus.cl *timestamp
3h, bogusline
  from hdqfadojllrs (HELO lyvstufk) ([157.161.238.32]) by
mail.monmouth.com *bogusline

SC parses all the way down to the bottom instead of breaking the chain
and sourcing at the 3rd line from the top.  SC thinks the item came from
your IP thru' monmouth and turbus to libero.

A human parser would use the evidence and clues in the headers to
determine how to break the chain properly.  The evidence in the headers
is the timestamp as noted, and that turbus.cl shouldn't be relaying for
monmouth in NJ and that the turbus.cl IP is not the output server for
turbus, but its IP .139 is, and that the SPF could have been used by
libero when libero received the item from the .cl IP.

The remedy for the SC parse error would be for the libero.it SC reporter
to configure for mailhosting.  If the client performing the parse were
mailhost configured, SC would not parse thru' that turbus.cl IP as a
server, I don't think.

> mail.monmouth.com is no MX for libero.it so probably the last
> Received or even more are fake. Why does spamcop not recognize them?

SC misjudges the turbus IP as a server which it has sent to the relay
testers, so it derives that it should trust it to be a server.  That is
a mistake.

Possible relay: 206.48.149.132
206.48.149.132 not listed in relays.ordb.org.
206.48.149.132 has already been sent to relay testers
Received line accepted


-- 
Mike Easter
kibitzer, not SC admin