Header differences on two copies of same message

[DavidT]

Someone I know sent a message to me this morning and CC'd my wife's address. Both of those mailboxes forward to their own separate SC email accounts. The "From" address isn't on either of our whitelists. My wife's copy got delivered to her inbox, and yet my copy went to my Held mail. Here are Tracking URLs on her copy, then mine (lots of unimportant details removed before processing):

http://www.spamcop.net/sc?id=z1212636853z7...e36c344aef2709z

http://www.spamcop.net/sc?id=z1212637531za...aefd3b741dedfez

There is an odd difference in the headers added by "filter8" and "blade6" during the SC processing, other than the obvious inclusion of "X-SpamCop-Disposition: Blocked bl.spamcop.net" in my copy (there's no "Disposition" line in my wife's copy). The difference is in the "X-SpamCop-Checked" lines:

X-SpamCop-Checked: 192.168.1.101 66.249.23.241 66.249.0.15 68.230.241.42 70.169.32.72 7.5.2.0 24.251.161.244

X-SpamCop-Checked: 192.168.1.103 66.249.23.241 66.249.0.15 68.230.241.42 70.169.32.72 7.5.2.0

The first one (from my wife's copy) properly identifies the source IP (a PC connected to a broadband service), while that final IP is missing from the second one. If you inspect the parsing by the reporting system on both messages, the source IP is properly identified. I'm curious why "blade6" didn't "check" the true source IP and then why it wound up deciding that the source IP was on the SCBL and routing it to my Held Mail. That *might* make sense if it had some sort of "hiccup" and had a parsing glitch, but look at the odd IP it stopped on [7.5.2.0] -- that IP seems to be assigned to the Department of Defense, and AFAIK, these messages shouldn't have passed through any resources associated with the DoD.

In my deletion of unnecessary (and private) stuff from the messages before parsing them manually, I didn't remove any "Received" headers. I removed the "Return-Path" line, the "Delivered-To" line, some "X-lines" added by the initial receiving server, a "Reply-To" line, and "X-lines" added by my antivirus and mail clients. IOW, nothing that affects the parsing or interpretation thereof.

That DoD ip shows up in one other message in my mail client's inbox....one that originated from my wife's laptop on my home network, sent out using the same ISP, and was CC'd to me. I just scanned through some similarly-routed messages and found another IP [6.1.6.3] that doesn't show up in the Received lines and yet appears in the "X-SpamCop-Checked" lines of multiple messages. It's also DoD according to ARIN.

Black helicopter time...

DT

[StevenUnderwood]

Someone I know sent a message to me this morning and CC'd my wife's address. Both of those mailboxes forward to their own separate SC email accounts. The "From" address isn't on either of our whitelists. My wife's copy got delivered to her inbox, and yet my copy went to my Held mail. Here are Tracking URL's on her copy, then mine (lots of unimportant details removed before processing):

InterMail vM.7.05.02.00 explains your 7.5.2.0 IP address being seen at all.

That IP was listed (or falsely showed as listed) at the time your message was processed which is why the lists are different. Spamcop stops checking when it finds a match. You will need to contact JT or the deputies (not sure which would be more helpful here) to determine why 7.5.2.0 caused your message to be stopped by the bl.spamcop.net.

[DavidT]

InterMail vM.7.05.02.00 explains your 7.5.2.0 IP address being seen at all.

Good catch, Steven! Now I can relax and forget about the false "DoD connection" to those bogus IP addresses. They aren't IPs at all, but rather are server software version numbers that the SC email system is falsely identifying as IPs during message analysis.

That IP was listed (or falsely showed as listed) at the time your message was processed which is why the lists are different. Spamcop stops checking when it finds a match.

This part doesn't wash quite as well. The message copies were both handed off to SC MXs at precisely "14:56:56 -0000" and received by "filter8" and "blade1" at precisely "14:56:56 -0000" and both mistakenly did a check on the bogus IP, although server loads could have made those two checks happen at different times. There's no reporting history on [7.5.2.0] and SenderBase.org has never seen it transmitting any messages. Therefore, I'm a bit more inclined to go with a theory of a "false hit" during processing. I'll report it to JT.

DT