Cant parse head error

[ahoier]

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.

[rconner]

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

[Farelf]

...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.

[rconner]

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

[Snowbat]

I'm also seeing these %XMAILOE spams in a Gmail account but when pulled over IMAP, they only show up in the body and parsing looks fine:

http://www.spamcop.net/sc?id=z1639112433z1...37144382a92e9az

http://www.spamcop.net/sc?id=z1639190680zd...ab4aa0f10bf428z

[ahoier]

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.