Jump to content

Cant parse head error


ahoier
 Share

Recommended Posts

I've received some spam lately, that use a %XMIMEOE in the header/body (in Gmail's "Show Original" it's in the header, but in the email view it's in the body, likely because it's not supposed to be IN the header).

http://www.spamcop.net/sc?id=z1637898685za...9d3b4532dbda9dz is the relevant tracking URL.

http://www.spamcop.net/sc?id=z1637898687zd...a3333f9b8235f9z is another occurrence.

http://www.spamcop.net/sc?id=z1637898688z5...8f12c222494242z is another occurrence.

http://www.spamcop.net/sc?id=z1638020829z9...9196238fed8c68z is another one.

http://www.spamcop.net/sc?id=z1638033515z7...17c51cd7feb501z is another.

Just figured I'd report it, since this is probably the 3rd time I've seen it pop up.

There's also other instances of similar occurrences from a Google search for that strange variable (likely a bug in the spammers "kit" they are using?)

http://www.google.com/search?q=%25XMIMEOE&...58&filter=0 - one of which points to NANAS USENET group.

To expand:

I'm experiencing this with Gmail as noted above. I use Gspamcop mentioned in this thread to forward the spam.

I guess it's not really a question per se...I just figured I should report this happening so the developers/admins/etc are aware. I did try searching the forums/faq but didn't find any results with %XMIMEOE.

Edited by ahoier
Link to comment
Share on other sites

I've received some spam lately, that use a %XMIMEOE in the header/body (in Gmail's "Show Original" it's in the header, but in the email view it's in the body, likely because it's not supposed to be IN the header).

From what I can see in a couple of these, they actually are part of the strict header since they fall above the first blank line. At a guess, I'd say that they were tokens that were supposed to be replaced by some header material, but the bulking software screwed up and did not interpolate them. I don't know offhand whether they would cause indigestion to the SpamCop parser (or any other SMTP header parser), but it is a distinct possibility.

-- rick

Link to comment
Share on other sites

...I don't know offhand whether they would cause indigestion to the SpamCop parser (or any other SMTP header parser), but it is a distinct possibility.
Yes, the parser is excruciatingly sensitive in the handling of headers though it generally gets through them OK but then baulks at the processing of the body with the counter-intuitive warnings (which have to be taken together)

Parsing text part

error: couldn't parse head

Anyway, I would think rick is right (and the O/P), this is the result of the spammer's tools being mishandled or misbehaving and accordingly the priority for parser development to "rectify" the problem might be quite low. Hard enough to keep up with compliancy standards without throwing in "mistakes". Still, if it got to be enough of a problem ... but my impression is the importance of full parses is at a low these days, spamtraps and quick reporting bearing much of the burden in feeding the SCbl. And spammer "mistakes" generally fade away (to be replaced by new ones).

But well worth raising, thanks ahoier. Are there some "me too"s to be heard? Thinking of a msg to the deputies if there are (noting they are a step removed from system development and provide a necessary filter but apparently-anyway don't get to set the priorities) - of course anyone can send them a message at any time but it is probably a good idea to raise matters "here" for collective review and comment first, exactly as was done this time.

Link to comment
Share on other sites

Are there some "me too"s to be heard?
The only one I can think of is the churl who puts nonprintables into the subject line (who became the star of a recent thread here). Might not be worthwhile to rewicker the whole parser just for him, especially since SC finds the mail source anyway without efforting itself.

-- rick

Link to comment
Share on other sites

Interesting. Straight away my guess was it had to be a missing variable in their bulker-scri_pt/app thing.

But yea, I'm using gspamcop, which, as far as I know, uses IMAP to download and submit the message, but your messages look very different than mine. (the %XMIMEOE being in the body instead of the header).

But yea, probably not worth "fixing" since they will just create a new %VARIABLE next week that will throw-off the parser anyhow.

Edited by ahoier
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...