Jump to content

report_spam[at]hotmail.com reports odd attachment failure


snover

Recommended Posts

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>â€:

The following attachment(s) could not be processed by the system: . Please be aware of the following restrictions on e-mail the system can accept: 1. File size cannot exceed 1 MB. If you need to send in a larger attachment, please zip it before that. 2. Only the following attachments formats are allowed: cab, cap, csv, doc, docx, dotx, eml, err, evt, gif, gz, jpg, mp3, mpg, msg, nfo, pcap, pdf, png, potx, ppt, pptx, psf, pst, pub, rar, rtf, saz, tif, txt, vcf, vsd, wdb, wks, wps, wpt, xlr, xls, xlsx, xlt, xltx, xml, xps, zip. If you need to send attachment in another format please zip it before that.

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,

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

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.

Link to comment
Share on other sites

... as far as I can tell, none of the X-spam-* lines are longer than 84 characters. ...
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.
... 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.
That's great - all's well that ends well then.
Link to comment
Share on other sites

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.

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

The actual RFC says:

2.2.3. Long Header Fields

Each header field is logically a single line of characters comprising

the field name, the colon, and the field body. For convenience

however, and to deal with the 998/78 character limitations per line,

the field body portion of a header field can be split into a multiple

line representation; this is called "folding".

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

of course, I'm making an assumption as to the source of what you're looking at [...]

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

The "foldsing" was to try to work around the 78-character line length issue .... the 998-character thing still stands.

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

Each header field should be treated in its unfolded form for further syntactic and semantic evaluation.

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

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

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,

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

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.

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

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

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.

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.

Link to comment
Share on other sites

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

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.
But when the code is written to comply with the spec, and the spec says MUST, it is the spec that enforces the limit.

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.

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.

Link to comment
Share on other sites

  • 5 months later...
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?

I'm not sure whether to start a new topic, or revive this old one. Here goes...

For the past month or more, I am getting the same response to hotmail spamcop reports. The only difference is that they have corrected their from address, it now says microsoft and not micorsoft ;)

The following attachment(s) could not be processed by the system: .

Please be aware of the following restrictions on e-mail the system can

accept: 1. File size cannot exceed 1 MB. If you need to send in a larger

attachment, please zip it before that. 2. Only the following attachments

formats are allowed: cab, cap, csv, doc, docx, dotx, eml, err, evt, gif,

gz, htm, html, jpg, log, mht, mp3, mpg, msg, nfo, pcap, pdf, png, potx,

ppt, pptx, psf, pst, pub, rar, rtf, saz, stp, tif, txt, uccapilog, uccp,

vcf, vsd, wdb, wks, wps, wpt, xlr, xls, xlsx, xlt, xltx, xml, xps, zip.

If you need to send attachment in another format please zip it before

that.

http://www.spamcop.net/sc?id=z3650488888z1...5d213ede8ddee5z

We're using an out of the box spamassassin setup. Any ideas on how to resolve this, other than manual larting, would be appreciated :)

Link to comment
Share on other sites

I'm not sure whether to start a new topic, or revive this old one. Here goes...
This is a good place to post your query.
...http://www.spamcop.net/sc?id=z3650488888z1...5d213ede8ddee5z

We're using an out of the box spamassassin setup. Any ideas on how to resolve this, other than manual larting, would be appreciated :)

Off-hand I don't see a blessed thing that might trigger the 'wrong attachment/too big' response. Hopefully a SpamAssassin user might have an idea of two.

[edit] Well, I guess the Content-Type: text/plain; charset="big5" would be a suspect, somehow. Their whole submission process must be quite fragile if so. I tried looking at the "Preview Reports" with a copy of your spam loaded into a dummied (and subsequently cancelled) submission but could see nothing amiss there. They don't accept munged reports but SC would decline to send it if you tried (devnull instead).

Link to comment
Share on other sites

Thank You.

"fragile" indeed. Kinda sums up a certain North American software vendor's product quality quite succinctly ;)

As you noticed (or were already aware), they refuse to accept munged reports, so one must tick the box and accept the warning about sending un-munged. Other than that I can think of no other difference between these and other reports that I submit.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...