When a plain text message, with "format=flowed": Content-Type: text/plain; charset=us-ascii; format=flowed is being displayed on the screen (when reading messages) then on any line starting with 1 or more spaces, that line will be displayed with one less space. If the message lines are: 000 111 222 333 then they will be displayed on screen as: 000 111 222 333 The same thing happens in Print and Print Preview. However the lines appear correctly in View Message Source. (Editing the message as new results in the correct indenting, but as noted below, there is another bug which screws up what is sent and saved.) Removing "format=flowed" from the Content-Type headers fixes the problem. (For instance, I edit the message file on the IMAP server.) Configuring Mozilla not to respond to "format=flowed" in the header solves the problem as well. So the bug seems to be in the code which interprets "format=flowed" plain text emails. This bug hides the problem in the 1 year old bug http://bugzilla.mozilla.org/show_bug.cgi?id=141983 "Space added to indented line when sending or saving message" because it hides the extra space. But the extra space is in the messages nonetheless and is seen by all non Mozilla mail readers. The current bug seems to be younger than this "Space added" bug - because a year ago, reading the messages with Mozilla did not hide this "Space added" bug. As noted in http://bugzilla.mozilla.org/show_bug.cgi?id=86607 "[RFE] UI option for disabling format=flowed" the interpretation of "format=flowed" in messages being read is on by default and there is no user interface option for changing this. (Likewise, the option for sending plain text messages with "format=flowed" is on by default, with no user interface option to change it.) The workaround for both these bugs is to disable these features with the following lines in user.js: pref("mailnews.send_plaintext_flowed", false); // RFC 2646======= pref("mailnews.display.disable_format_flowed_support", true); For those who are more interested in using the program than chasing bugs, I will document how I get Mozilla and Netscape 7 to do what I want at: http://www.firstpr.com.au/web-mail/Mozilla-mail/ I observed this with Mozilla 2003050211 and Netscape 7.02 both on Win2k. I assigned it to component "Composition" because I can't think of what else to assign it to. - Robin
Spec mandates that, code follows spec, invalid. Please read RFC 2646 <http://asg.web.cmu.edu/rfc/rfc2646.html>.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
As Ben writes, this is indeed what sending with "format=flowed" is meant to do. http://www.rfc-editor.org/rfc/rfc2646.txt If a space-stuffed message is received by an agent which handles Format=Flowed, the space-stuffing is reversed and thus the message appears unchanged. An agent which is not aware of Format=Flowed will of course not undo any space-stuffing, thus Format=Flowed messages may appear with a leading space on some lines (those which start with a space, ">" which is not a quote indicator, or "From "). Since lines which require space-stuffing rarely occur, and the aesthetic consequences of unreversed space-stuffing are minimal, this is not expected to be a significant problem. Its still a problem for some users, as long as "format=flowed" is on by default, as is evident in bug 141983. But this is not a problem in the implementation of sending with "format=flowed".
Seems that this bug creates problems for GNATS users who submit PR's by email. The field delimiter is \n><field name>:<value>. Flowing breaks the GNATS parser. Explicit selection of flowing and disabled default flowing of outbound mail would be my preference. Rgs, Clark
You need to log in before you can comment on or make changes to this bug.