"Copy/paste the following URL..."

[Gromit]

http://www.spamcop.net/sc?id=z691273359zd9...d303c967947a62z

Just for kicks, I tried adding a line with the c/p'ed URL from the browser version and SpamCop still couldn't see it. And yeah, I did the a href= bit.

So, any way we can get the site slammed, too?

[Jeff G.]

I agree, it would be great if Julian could put on his to-do list allowing the SpamCop Parser to understand that h<clausius>tt<accessory>p<barbarian>:<opine>//<strength>21<barnard>1.<cunard>15<breastplate>8.<gaudy>15<crusoe>.6<lsi>0/gf displays as http://211.158.15.60/gf and parses as follows:

Parsing input: http://211.158.15.60/gf

host 211.158.15.60 (getting name) no name

No recent reports, no history available

Routing details for 211.158.15.60

De-referencing cqnet.com.cn[at]abuse.net

abuse net cqnet.com.cn = postmaster[at]cqnet.com.cn, abuse[at]cnc-noc.net

Report routing for 211.158.15.60: postmaster[at]cqnet.com.cn, abuse[at]cnc-noc.net

[dra007]

cnc-noc.net is devnulled in my reports!!

[Merlyn]

They are dev/nulled on our servers also <grin>

[btech]

I've been noticing A LOT of "error parsing the header" through my SC mail. Out of the last 20 reports, 7 had this error.

I'm not seeing what would cause the error, but I'm also relativly novice to this:

http://www.spamcop.net/sc?id=z691658330zf2...d9811b10d45dfez

Is there any editing I can do to make these headers parcable?

EDIT

Here's another that I took out the included spaces around priority to make it parce

http://www.spamcop.net/sc?id=z691661901z53...7e18174023875dz

[Wazoo]

Because of the way this application handles white space and the possibility of mis-handling between it and any/the poster's software, I deleted the included quotes of a SpamCop parsing page output ... and this comes up a bit later ...

http://www.spamcop.net/sc?id=z691658330zf2...;action=display

Has an ending MIME Boundary line ... however, no Content-Type: line in the header or a beginning Boundary line. Suspicions would be that you edited too much (and you are bumping very hard on the "shall not make material change" rule)

http://www.spamcop.net/sc?id=z691661901z53...;action=display

OK, the originally posted quote displayed some line wrap issues. Verifying that the data posted was in fact a match for the data on the parser output pages, the quoted material here was edited out of that post. However, the point is that the line-wrap issues are seen in the page referenced. Check the X-Mailer line ... this is where the parser is stumbling.

Though I'm actually not sure how to explain why the sample shown (and previous samples) passed with the modification of the [Priority: Normal] line (maybe something about the brackets?) .. I will suggest that "the" issue is the line-wrapping of whatever app is in use. The length of the "original" Priority line is so long that it also is wrapped, and this gets into the problem that a line-continued needs to have some white space at the start of the continuation line. Whatever app is being used to handle this e-mail isn't doing that ... it's just counting characters and at "that" spot, it's moving the rest of the line down and continues to march. Your "deleting the spaces" is shrinking the line below the magic character count, thus taking that bad line-wrap out of the picture.

There was some dialog recently in another Topic that dealt with another instance of this "Priority line", though I seem to recall it was more oriented on the merits of using VMS ... but the point is that this isn't a widely announced problem, so the question is .. is this part of the spam construct or is this a locally generated data line? If locally, can you talk to someone to knock the spaces out of the added line? (Perhaps something designed to show up centered on a 132-column printed page - just a conceptual justification for all that extra padding ....)

[btech]

Suspicions would be that you edited too much (and you are bumping very hard on the "shall not make material change" rule)

I amde no changes to that first link. It was sent directly to my Comcast account, which auto forwards to my ces/SCmail (web interface). So it's possible that there is a problem with the delivery from Comcast, but I'm thinking is more likely that the cause is from the spammer.

[GraemeL]

There was some dialog recently in another Topic that dealt with another instance of this "Priority line", though I seem to recall it was more oriented on the merits of using VMS ... but the point is that this isn't a widely announced problem, so the question is .. is this part of the spam construct or is this a locally generated data line?  If locally, can you talk to someone to knock the spaces out of the added line?  (Perhaps something designed to show up centered on a 132-column printed page - just a conceptual justification for all that extra padding ....)

20129[/snapback]

I've seen the Priority line generate the "could not parse head" error on spam sent directly to my spamcop.net email address. I think it's added by the spammers to break the parse.

[Wazoo]

I amde no changes to that first link.  It was sent directly to my Comcast account, which auto forwards to my ces/SCmail (web interface).  So it's possible that there is a problem with the delivery from Comcast, but I'm thinking is more likely that the cause is from the spammer.

My "guess" at editing was based on the "priority" line looking exactly as seen in the "edited" spam submittal you showed over in your post at http://forum.spamcop.net/forums/index.php?...indpost&p=19996 .. which is also the Topic including the VMS verbiage.