See 384842 comment 30.

Comment on attachment 394718 [details] [diff] [review] proposed patch Basically, I think Magnus' "fix" you are porting here is wrong. If I enter a hundred spaces in the subject, my mailer should cope with it. If this violates any RfC, it should handle it in a different, compliant way, if possible. In this special case, the (violating part of the) subject could/should be MIME-encoded (which probably may need a backend fix). Furthermore, with this fix the subject will be altered just by answering (an answer) which shouldn't happen either.

(In reply to comment #1) > In this special case, the (violating part of the) subject could/should be > MIME-encoded (which probably may need a backend fix). RFC 2047 is for next. > http://tools.ietf.org/html/rfc2047 > (1) textual message bodies in character sets other than US-ASCII, > (2) an extensible set of different formats for non-textual message bodies, > (3) multi-part message bodies, and > (4) textual header information in character sets other than US-ASCII. If RFC 2047 is applied to continuous long spaces, it can be said another RFC violation of above (4), if Subject: header contains US-ASCII characters only. I don't think change by Bug 384842 is absolutely wrong. I think that change can be said; RFC 2822 doesn't permit space only line, then shorten long spaces in order to be compliant with RFC 2822, without issuing annoying dialog to ask user. > If I enter a hundred spaces in the subject, my mailer should cope with it. >(snip) > Furthermore, with this fix the subject will be altered just by answering (an answer) which shouldn't happen either. At where of what RFC "shouldn't" is written? When composition, "asking user to reduce length of continuous spaces based on RFC 2822" is reasonable action of mailer. Even when reply, it's same. Subject of replying/forwarding mail is mealy a subject of a new mail. Keeping same subject is for "threading by subject when no reply-to: etc." and readability, and "change or keep same" is up to user, isn't it? > If this violates any RfC, it should handle it in a different, compliant way, if possible. What is possible way do you think, which is perfectly RFC compliant, convenient for users, and reasonable/acceptable for users.

(In reply to comment #2) > RFC 2047 is for next. > > http://tools.ietf.org/html/rfc2047 > > (1) textual message bodies in character sets other than US-ASCII, > > (2) an extensible set of different formats for non-textual message bodies, > > (3) multi-part message bodies, and > > (4) textual header information in character sets other than US-ASCII. > If RFC 2047 is applied to continuous long spaces, it can be said another RFC > violation of above (4), if Subject: header contains US-ASCII characters only. No. What you didn't quote is the preamble to these four points: | This set of documents, collectively called the Multipurpose Internet Mail | Extensions, or MIME, redefines the format of messages to allow for ===== In other words: while MIME was created to solve (1)-(4), it's not against its spirit (let alone its words) to use it in other cases, e.g. for mere ASCII text or plain white space aggregations. It's usually not useful to encode ASCII words in MIME, but it's permissible. It's not common to use MIME for encoding white space, but it's legal and sometimes even useful (like in this case here). I extensively did read through the MIME stuff, but didn't find any violation which would prevent encoding whitespace as MIME words to create legal header folding. Please don't hesitate to correct me if I'm wrong! > I don't think change by Bug 384842 is absolutely wrong. > I think that change can be said; > RFC 2822 doesn't permit space only line, then shorten long spaces in order > to be compliant with RFC 2822, without issuing annoying dialog to ask user. Well, not "absolutely wrong". But destructive enough to shun it, especially if better solutions exist. > > If I enter a hundred spaces in the subject, my mailer should cope with it. > >(snip) > > Furthermore, with this fix the subject will be altered just by answering (an > answer) which shouldn't happen either. > > At where of what RFC "shouldn't" is written? These "shouldn't" aren't written in RfCs as such. - programs are expected to do as told unless real limitations (like RfCs) apply - not fiddling with e.g. the subject as far as possible can be seen as kindness to other mailers (e.g. threading by subject); you might want to create an obligation to not alter it from RfC 5322: | 3.6.5. Informational Fields | ... | The "Subject:" field is the most common and contains a short string | identifying the topic of the message. When used in a reply, the field body | MAY start with the string "Re: " [...] followed by the contents of the | "Subject:" field body of the original message. > When composition, "asking user to reduce length of continuous spaces based on > RFC 2822" is reasonable action of mailer. Well, not really. It would be if there were no other way out. But there is... > Keeping same subject is for "threading by subject when no reply-to: etc." > and readability, and "change or keep same" is up to user, isn't it? Yes, see above. It's not a hard requirement as such unless you want to nitpick RfC 5322 by the word. > What is possible way do you think, which is perfectly RFC compliant, MIME. > convenient for users, and reasonable/acceptable for users. MIME: users don't need to be asked, get what they want and don't even need to care!