Analysis of a problematic parse

[DavidT]

Those of you who are adept at interpreting the SC parsing, please take a look at this Tracking URL:

http://www.spamcop.net/sc?id=z580798293za9...da56d9224eb8afz

It's an example of something I reported out of my Held Mail in a Quick Reporting batch, and then when scanning through the "SpamCop Quick reporting data" email from SC, I missed that the "Reportid: 1151134474 To: abuse <at> alabanza.com" sent to the "Administrator of network where email originates" ("Re: 209.239.41.66") was sent to my own ISP, Alabanza. This was done despite the fact that the parse properly identified the source of the email NOT as "209.239.41.66" but as "69.60.6.220" (which was the true source). I don't understand why the report didn't get sent to the people responsible for the IP 69.60.6.220 instead.

So, just for fun, I changed only the dates (so that the system wouldn't think that the message was too old) and ran a test parse (without reporting, of course), here:

http://mailsc.spamcop.net/sc?id=z624726835...35717d7c31e4d2z

In this case, you see that the reports would be sent to the proper places, and not to Alabanza, the ISP hosting my email address. It seems to me that the parsing engine made an obvious mistake in the first URL above, and this might be a reason for me to jump into the Mailhosts, even though this was the only such error out of thousands and thousands of messages that I've used Quick Reporting on for several months.

Please take a look at the first parsing results above and see if you agree that the SC reporting system screwed up.

dt

[dbiel]

this might be a reason for me to jump into the Mailhosts

That IS the reason Mailhosts was created. With as well as Mailhosts seem to be working, I would not be suprised if it becomes manatory very shortly.

By the way, Mailhosts becomes even more important if you use multiple forwarding of messages.

[Wazoo]

It's hard to agree that SpamCop screwed up, as the current set of parse results show that things are working just fine ... but have to agree that something had to have gone wrong in the first example, showing the alabanza report going out. One possibility that comes to mind (and I haven't figured out how to try to verify this) is that perhaps this server had just recently come on line, thus it fell under the "recently discovered" mode of the parser. Possibly then looked at as a possibly compromised machine at that time, but this server is now recognized and is now "known" as an e-mail server. Only guessing at this point ....

If this is anywhere close to true, there is a very recent Topic over in Mail-Host that has asked the question of what happens to the mail-host configuration of the ISP makes some changes. I'm not sure that this was answered with something real solid.

Sorry not to be able to point at something definitive, one of those bad things about the parse engine/result page being dynamic ... can't see what happened on that real/first parse.