Intentionally Malformed Spam

[bdurrett]

http://www.spamcop.net/sc?id=z682214277ze8...4b098a954db617z

In the above mentioned report, the two links are easy to see but, due to the intentional malforming of the e-mail / header (the usual multi-part but no boundary lines hack), the links are not discovered.

One-part submission form, complete headers and message body inserted so I can guarantee that there is NOT a copy-&-paste error.

Just FYI that the spammers have found yet another way to get away with their spamvertised Web Sites.....

[Wazoo]

As far as "found another way" .... hardly something exciting at present. Thus specific ussie has been around since folks started using Outlook to submit their spam submittals. Once upon a time, Julian allowed this to fly, but way too many bad reports were being offered up and way too many ignorant users were just blinfly clicking away on all the targetted addresses. Code was tightened and either an RFC compliant e-mail was required or the use of the two part form offered as a work-around.

I find it a bit odd that you so blithely state that you cut/pasted into a one-part form, mention having to cut/paste the header and body as separate actions, and then neglect to identify the tools in use. Just as the parser must do, "we" are left having to make a decision / call on whether or not what was submitted was an actual RFC compliant e-mail datum or something "created" ... but as specific data is missing, the parser errs to the cautious side and refuses to make any assumptions, thus no reports on items not correctly identified and handled.

[bdurrett]

I find it a bit odd that you so blithely state that you cut/pasted into a one-part form, mention having to cut/paste the header and body as separate actions, and then neglect to identify the tools in use.  Just as the parser must do, "we" are left having to make a decision / call on whether or not what was submitted was an actual RFC compliant e-mail datum or something "created" ... but as specific data is missing, the parser errs to the cautious side and refuses to make any assumptions, thus no reports on items not correctly identified and handled.

18732[/snapback]

Sorry for forgetting to state that I am pulling the mail through the AT&T Global Networks' Web Mail interface. I had too many problems with Outlook in all it's myriad forms when trying to use the various hacks like the two-part submission, etc. The Web Interface allows one to "View Full Headers" in a seperate HTML window where one then can "View Source" or "View Body" as a seperate HTML window where one can then, again, "View Source." The basic front end shows neither headers nor the HTML source behind the mail automatically but it does allow one to purposefully NOT display graphics from an external source (i. e. graphics that are linked into the mail from external sites).

As for the rest, I understand that the parser errs on the side of caution and was not complaining. Rather I was attempting to help point out that there is an obvious attempt to circumvent a tool that is plainly causing the spam-slime a great deal of discomfort (not as much as I would like to cause them but that is another matter )

Cheers

[Wazoo]

No grief intended. This "complaint" is way up on that top 10 list, and so many users then follow up with the "why doesn't SpamCop just ignore these kinds of errors?" But from the "programming of the parser" end, there are just too many variables in the mix to allow the parser to just assume that what it was fed was the actual spam, no errors made during handling by the servers involved, the e-mail applications involved, the user's methods and modes of moving the data, and of course, is it a spammer manipulation.