Is anyone else seeing the 50k per spam/100k per e-mail in a "multiple spam in a single e-mail" web form submittal error? When there is actually less that 50k/100k data being sumitted via the web form...

I have tracked the error down to SpamCop not correctly handling Unicode characters embedded within an HTML stream. For example, the Unicode Character for the "bullet" symbol, or "95 U+2022".

149 8226 0x95 U+2022 • bullet General Punctuation

Any Unicode character causes the problem. The problem is 100% re-producible.

If you are seeing the issue, please post a reply to my post, so that we can get momentum for getting the issue fixed.

Thanks!

moving to the SpamCop Reporting Help Forum section qith this post.

Tried to reproduce that problem George, without success (used the hex 95 character, both within and outside the HTML part). What is the actual size of the spam you are talking about? Can you provide a Tracking URL (link) for a case where SC has truncated the body? My try is http://www.spamcop.net/sc?id=z3334499068zb...6c22618564e74fz. If it is reproducible you don't have to wait for a straw poll, just provide the data necessary to show the problem.

...Yes, I used to see that a few years ago whenever I submitted Chinese-character spam to the parser. No recent experience, though.

Now clarified this is the "No data / Too much data" error.

Based on reports that this problem is not generally reproducible, I have confirmed that it is a combination issue requiring: (1) the SpamCop web form, (2) unicode character encoding in the spam e-mail, and (3) Internet Explorer Version 6.0.xxx.

When I paste in the identical “problem” spam e-mail into the SpamCop web form, using Mozilla Firefox Version 3.0.13 instead of Internet Explorer Version 6.0.xxx, I do not see the problem. Having said that, this is still a SpamCop web form bug. SpamCop should be able to either process the apparently questionable I.E. 6.0-generated data, or respond with a more relevant error message.

My guess is that fixing this problem will resolve a number of other outstanding (and difficult to understand) SpamCop issues.

Your analysis is useful, but I'm not sure I agree with your conclusion.

Why should SpamCop spend the time and effort to identify and uniquely report all the errors produced by all possible browsers? They do identify an error and thus protect the parser and the reporting systems - which is the objective to my mind.

Besides how would the web based form process identify that the error is caused by IE and how it implements the form, as a posed to the process of cutting from a mail app or pasting into the IE implemented form or the mail app?

Just for me I would prefer the programming time be spent increasing the reporting rate (eliminating the "no action taken" results).

We possibly need to differentiate between what the parser does with the headers and what it does with the bodies. It can't be expected to deal with mangled headers, it does deal with some 'common' non-standard headers (both provider and application caused, what Julian sometimes called "bizzaro' IIRC - perhaps that term is still in the parser results where applicable?) but it should (ideally) be sunnily unfussed by the bodies. The bodies aren't the main mission after all (as Lou says) and aren't even looked at in quick/VER reporting - but other members keep demanding that bodies be parsed for spamvertizements (and all that goes with that, including HTML interpretation, ignoring innocent bystanders/'free' webmail advertizers/'free' antivirus plugs etc. in the process as just a small part of that).

As George says/infers, an unexpected result in handling bodies may be symptomatic of some deeper problem. The "No data / Too much data" message reflects some sort of error trapping one suspects but it is too general, not to mention misleading in this circumstance. Looking at http://forum.spamcop.net/forums/index.php?showtopic=807 maybe confirms an IE6 problem with 'non-Latin' characters, perhaps as also indicated by Steve T, above (maybe the problem under discussion is not unexpected after all) but the explanation given in the error dialog box (unchanged all this time) is quite inadequate:It doesn't mention the special characters thing with IE6 (only IE6? - and if that is part of the binary submissions thing it is way too obscure) and it doesn't mention the old Netscape 4 problem (arising, ironically, from a special accommodation for a specific browser IIUC).

If it is not feasible (who knows?) to trap these errors individually then maybe that generalized error message needs to be re-named and the explanations expanded a little. Even if there are very few people using those browsers now, it shouldn't cost too much to alter a dialog box. I would be suggesting that, as a minimum. The more profound problem with (later version) IE header mangling for e-mail submissions is a different matter and has its own momentum with a much larger potential user-base.

Is that reasonable?

This same problem has been reported in forum topic "Replying to Error when pasting message into reporting side (too large?)".

I added a note to that topic.

Thanks George - the link to that topic is Error when pasting message into reporting side (too large?). More confirmation, that's good.