GeorgePhelps Posted September 20, 2009 Share Posted September 20, 2009 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! Link to comment Share on other sites More sharing options...
Wazoo Posted September 20, 2009 Share Posted September 20, 2009 moving to the SpamCop Reporting Help Forum section qith this post. Link to comment Share on other sites More sharing options...
Farelf Posted September 20, 2009 Share Posted September 20, 2009 ...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...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. Link to comment Share on other sites More sharing options...
turetzsr Posted September 21, 2009 Share Posted September 21, 2009 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. <snip> ...Yes, I used to see that a few years ago whenever I submitted Chinese-character spam to the parser. No recent experience, though. Link to comment Share on other sites More sharing options...
Farelf Posted September 22, 2009 Share Posted September 22, 2009 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...Now clarified this is the "No data / Too much data" error. Link to comment Share on other sites More sharing options...
GeorgePhelps Posted September 22, 2009 Author Share Posted September 22, 2009 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. Link to comment Share on other sites More sharing options...
Lking Posted September 22, 2009 Share Posted September 22, 2009 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. 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). Link to comment Share on other sites More sharing options...
Farelf Posted September 23, 2009 Share Posted September 23, 2009 ...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. ...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: No data / Too much data You are most likely submitting a very large email. Please trim some of the unnecessary data (noting where this has been done) from this posting and try again. SpamCop will no longer accept email larger than 50.0K bytes. Other possibilities: You may have a firewall which prevents HTTP POST commands, you may have linked to the wrong URL or your browser does not handle binary submissions correctly (try a different browser) 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? Link to comment Share on other sites More sharing options...
GeorgePhelps Posted September 24, 2009 Author Share Posted September 24, 2009 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. Link to comment Share on other sites More sharing options...
Farelf Posted September 24, 2009 Share Posted September 24, 2009 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.