[Resolved] Not following though to 1st IP

[DerekS]

spam link:

http://www.spamcop.net/sc?id=z5355407331z8...e04d869163c4f5z

Here we have part of a bigger issue of of 419 scammers using free VPN providers to hide their tracks from LE.

However in reporting these, I have noticed that the parser does not normally follow through to the source:

Received: from [204.93.60.80] by web181306.mail.ne1.yahoo.com via HTTP; Sat, 23 Jun 2012 10:04:16 PDT

The parser stops at Yahoo, reporting this to Yahoo. However in the usage of these, that is pretty useless as these issue is nLayer in this case (and most likely AnchorFree downstream) where the scammers are using disposable Yahoo email addresses to spoof banks, lottos, governments etc.

This issue also crops up when EgiHosting's services are used (where AnchorFree also has VPNs).

Once in a while the parser may track it all the way back, but this is rare.

[Farelf]

I may be wrong but that report looks to me like you don't have your mailhosts configuration set up. I hacked your spam for the purposes of comparison, substituting delivery lines for my provider and this is what my mailhosted parse would look like:

http://www.spamcop.net/sc?id=z5355759590z2...a06445ad64c2acz

(nLayer source found - though reports are disabled for them, at least the originating IP address gets a chance to go into the SCbl which might, in turn have flow-on effects)

Your tracking URL by comparison looks exactly like my (other) unmailhosted account report:

http://www.spamcop.net/sc?id=z5355755741z3...a708989a565786z (Yahoo blamed)

There are significant differences in the parser handling of the task, depending on mailhosting - inside the boundary of trusted relays and designated MX servers if not "mailhosted" (because anything else might be spoofed) VERSUS (usually) the delivery agent immediately outside your larger network if mailhosted.

[DerekS]

Thank you Farelf. Indeed, it seems you hit the nail on the head