Re: Chaintest not working, or spammer trick?

Geoffrey Hyde wrote:
www.spamcop.net/sc?id=z947668478zeb1d52e378e4916c06b1227e96e6c343z

  Abbreviated tracelines *comment
  from mk084020170193.a1.net ([84.20.170.193]) by
imta02ps.mx.bigpond.com *SC sez source, possibly relay
  from [84.20.24.113] (helo=mpi) by mk084020170193.a1.net *possible
sourceline

SC may have made a mistake on the parse, may have broken the chain
prematurely, or SC may be right.

"mk084020170193.a1.net looks like a dynamic host, untrusted as relay"

SC doesn't know there are a bunch of output servers which look just like
that.

The payload is a b64 gif stockspam.

> Why does SC bother with the part about "such-and-such is not a MX for
> bigpond?

That is part of the algorithmic sequence for preparing for the 'mx
step'.

> As far as I know bigpond will receive mail from anywhere.

That does not pertain to 'blank is not an mx'.

> I'm wondering if SC has had a change or update which changes the way
> it considers my ISP's mail configuration.

That parse is not for a mailhosted account, unless something has been
changed in how the algorithm provides the verbose for a tracker.

> In the above example, SC might have chaintested successfully, if it
> had accepted that bigpond will receive mail from anywhere on the
> internet.
>
> Or I could be reading the parse wrong - I have reported it as SC
> found it, in case this is some spammer trick.
>
> Anyone know whether the ISP SC notified is correct?

Regardless of whether the source was   84.20.170.193  rDNS
mk084020170193.a1.net  which looks like a a1.net output server to me or
84.20.24.113  no rDNS presumably a user IP which isn't listed anywhere,
the notify is the same block.

But SC's cached answer for the notify address was stale.  The current
ripe contacts say  [email protected]  &
[email protected]  -- not what SC had in its cache:
[email protected]   &  [email protected]

The problem/question is whether or not the headers show a user IP
relaying thru' a server or if the bottom Received is a bogus line with a
good forgery and timestamp.  Senderbase shows a number of output servers
with similar names, but not that one.  I can't find anything in
sightings to help dissect those headers.  All things considered, I think
in this case it is better for SC to err on the side of naming the
server -- if the server is relaying spam and it gets listed, there will
be an earlier resolution of what is going on.


-- 
Mike Easter
kibitzer, not SC admin