I recently reported some spam that contained Hotmail return-address in the body. When I reported it to Microsoft through SpamCop, I received back this weird response from “Micorsoft [sic] Customer Support <report_spam[at]css.one.microsoft.com>”:



Since the original message was a very short, typical multipart message with only text and html parts, I am perplexed. Has anyone else had trouble recently with reporting spam to Microsoft?

Regards,

Basically it is not worth the effort, period (followed by exclamation mark)!

Yes, I have had trouble reporting spam to Microsoft, they seem a bit arbitrary in whether or not they accept reports (and lord knows whether they act on them). They tend to be very eager to find reasons to treat spam reports as having been misdirected, even where these reasons don't actually exist.

As for the message under discussion, a tracking link would be very helpful.

-- rick

Ah, yes. Here you are:
http://www.spamcop.net/sc?id=z3185225336ze...bb5f923c6a1daaz

Thanks folks, I held back from making my normal 'negative' response by not posting the request for this obvious bit of data, appreciated that someone else noted its absence, and thanks again for providing it.

Can't help but draw comparisons to another recent discussion at http://forum.spamcop.net/forums/index.php?showtopic=10518 .. this appears to be yet another attempt by someone else at trying to provided a "standard format spam report" .. but whoever developed this self-described spam detection software, running on the system "two.acitia.com" apparently ignored other aspects of various RFCs. Although X-: lines can be generally ignored as just extraneous data that can be inserted anywhere by anyone, my first reaction was seeing that the general 255-character limit on a single line has definitely been trashed. As Microsoft/HotMail do use X-: lines themselves, it's not too hard to guess that their parsing code would also look at these lines. If I had o guess at this point, I'd go with their parser choking on this too-long line but then selecting a wrong error-code/definition of the problem.

That'd be my guess too, there's no obvious MIME problem and no real MIME attachments. I've a feeling that the MS abuse folks, like those monkeys in the science experiments, have a bunch of buttons to push in order to send each incoming report down the appropriate slot; it might be easy to hit the wrong button if the report doesn't conform to expectations.

-- rick

I’m confused about what you are talking about. This is a pretty standard SpamAssassin 3 installation and as far as I can tell, none of the X-spam-* lines are longer than 84 characters. I thought maybe you were talking about the total header length, but I read RFC 2822 and as far as I can tell it only specifies that a single line can be a maximum of 998 characters — nothing specific about the total length of a header as long as it’s been line split properly, and nothing about a 255-character limit anywhere.

Interestingly, despite the error message auto-response from their system, I got a response back from a human (a human!) that said they had terminated the spamming account. So it seems that it wasn’t a fatal error.

The 'X-spam-Report:' block is all one 'line'. Indenting is a continuation of the line, not a new line. I guess the indenting itself even counts towards the total characters. That's 2031 characters, including the header name.That's great - all's well that ends well then.

I don't want to seem argumentative, I am just trying to understand.

The actual RFC says:

From my reading, this says that folding headers is a workaround for the 998 character limitation. Unless your argument is that "Each header field should be treated in its unfolded form for further syntactic and semantic evaluation" means that the rule in 2.2.1 applies ... but in such a case, why would they have said that folding was to deal with the character limitation?

Keep reading (of course, I'm making an assumption as to the source of what you're looking at .. I've got http://www.faqs.org/rfcs/rfc2822.html pulled up right now) ....

The "foldsing" was to try to work around the 78-character line length issue .... the 998-character thing still stands. The 'magic' is in the tailing paragragh of your referenced section 2.2.3;

The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation.

In order to try to resolve yet another issue, just what character-set do you have your browser set to use?

I really, really hope that people don’t make changes to RFC documents and repost them on the Internet. Though, in a twisted way, that would a rather clever scheme for really confusing some people. (I was looking at the faqs.org copy, for reference.)


I guess I really don’t understand why they would add confusion by writing “998/78” there instead of just “78”. In a section called “Long header fields”, no less. Clearly, the people writing the specs aren’t Aspergian enough for me.


So then I was correct in thinking that this is where the spec indicates that the 998-limit applies to folded headers. I understand now, though I still think it’s not terribly clear. (Nor do I think it’s particularly smart for the spec to enforce an arbitrary maximum length on the data portion of unstructured header fields, but I can at least understand the reasoning behind it.)


UTF-8, because your Web server returns “Content-Type: text/html; charset=UTF-8”. HTML 4.0 § 5.2.2 states that HTTP header takes precedence over meta http-equiv.

Cheers,

If I recall right, this was to provide developers of mail-handling software with maximum buffer sizes. SMTP is very old, as you probably know, and back in the day a 1000-character buffer in a daemon-type program was a very big and expensive deal, not like today when my toaster-oven can probably process that much text.

-- rick

As Rick states, the 998-character bit came along later ... but one shouldn't skip over the words in secton 2.1.1, which does point back to olden boxes and code. Although the 'net' and e-mail have eveolved since the gok old bang-path days, there is still a lot of that old stuff still hanging on the wires.

It's not the 'spec' that enforcesx an arbitrary limit, it's the code and hardware found around the world that's supposed to handle and process the traffic. When "the world" has all moved to 64-bit processers (or aven larger) one might expect these 'arbtrary numbers' to possible increase also ...????

OK, however, the actual answer seems to be "en-GB" (based on server log content) ... looks like I need to take keyboard mapping into account also.

Oh, I know, and that’s where I understand the justification to be. However, RFC 2822 was written in 2001, when there was enough memory to deal with more than 1kB of header data at a time. Since they were changing other more integral things, such as the datetime representation, I am surprised that this limitation was not removed.

But when the code is written to comply with the spec, and the spec says MUST, it is the spec that enforces the limit.

I guess it depends on what the problem is that you’re concerned about. Accept-Language is all about preferred language and doesn’t have anything to do with keyboard layout, by the way. This is actually a US English keyboard.

If you’re trying to resolve the problem with bungled characters in edits, fix Invision Power Board to be consistent with what character set it reports and uses. Quick edit seems to assume ISO-8859-1 which breaks all the non-ASCII UTF-8 characters. If you run the pages through a validator you’ll find there’s a lot lacking in terms of standards-compliance in IPB anyway, but that’s neither here nor there. This is extremely OT so feel free to send a PM about it or something if you want to continue the discussion.