From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 BuildID: 20011112012 I am in the habit of composing long emails in a different editor, and then pasting them into the Mozilla editor before sending. Unfortunately, Mozilla misinterprets the "> " quote prefix at the beginning of lines as *not* being a quote, and inserts a space before the beginning of the line. Mail clients that interpret quote prefixes for format=flowed content will therefore render the mail incorrectly. Specifically, mutt's colorization feature doesn't work. If pasted or typed text matches the approproate quote prefix, Mozilla must not "reinterpret" what the user told it. Pasted text should be *literal* text; why else would I bother to paste it? Alternative solutions: + Provide (and document) a method for turning off format=flowed in mail sent from the Mozilla mail editor. + Provide a way to invoke an external editor. This would be my favorite, although I suspect the NIH factor will prevent this from making it into the official tree. Reproducible: Always Steps to Reproduce: Write an email containing "> " at the beginning of quoted lines in an external editor. Paste into the Mozilla mail editor. Send. Actual Results: What comes out on the other side is not what was pasted. There are spaces before the ">" characters. Expected Results: No inserted spaces before the ">" characters in pasted text.

Confirming on 2001121703, Win95, following suggested steps. It is easy to see that blank leading character in View->Message Source->Select All. Marking as new, OS->All.

->Editor:Core

format=flowed shouldn't have anything to do with this, since it takes effect at save time, not at paste time. We shouldn't be adding spaces at the beginning of lines on paste whether or not the line starts with >. I wonder where the spaces are coming from? Is this bug on plaintext mail compose, or html mail compose? The description doesn't say.

Not sure about the reporter but plain text for myself.

My problem was with the plain text mail composer, but I just verified (against 0.9.7) that the HTML composer has the same behavior. The format=flowed note had more to do with the client end. According to the RFC (about which I am *not* an expert), compliant mail readers are supposed to treat lines beginning with the "> " quote prefix specially, by doing whatever magic they want to make the quote appear quote-like. Lines that are supposed to begin with a literal "> " are escaped by adding a space at the beginning. My supposition was that the Mozilla developer decided that a user that *typed* a "> " at the beginning of the line wanted the literal text, and not a quote. While this sort of makes sense in a philosophical sense, it breaks the common case of a user pasting quoted text into the mailer. I don't believe the paste operation is part of the problem; I mentioned special-casing it as a compromise in case the response was "this is not a bug". :)

I wonder if it's possible that it's pasting html and treating the entity ">" as not being the same as ">"? (I still don't see why it would prepend a space, though.) But that doesn't seem likely if the copied text is coming from an external text editor.

There is just one more thing to this bug. As the reporter said, in format flawed;-) a whitespace appears before the pasted quote symbol. This is not true in the plain text editor when f=f is turned off, those pasted or just typed lines are not recognized as quotes by the editor, though. You see, that they are folded if they are to long. pi

Cc'ing Daniel: this is another example where space-stuffing is causing quoted text to be unquoted, even without the fix to bug 134439.

Yes, f=f rquires us to space stuff any line beginning with a '>' that we don't _know_ is a quote. We can never _know_ that a line beginning with a '>' is a quote. That's why f=f requires blockquotes and the editor to work really well. This has anything to do with pasted text. Anything the user writes or pastes are treated the same. What I would like to do is to recognize that the mail contains no flow, that it's prequoted and prewrapped, and then turn off f=f since the mail author already made it impossible to benefit from f=f. I don't think that would be easy though. In the best case it would probably require the serializer to run two times. Btw, has anyone contacted the mutt's authors and heard if they might be able to fix this in their end? Most (mutt was the first I heard of) readers seems to cope just fine with the inserted space.

>Yes, f=f rquires us to space stuff any line beginning with a '>' that we don't >_know_ is a quote. We can never _know_ that a line beginning with a '>' is a >quote. That's why f=f requires blockquotes and the editor to work really well. I think it should be the other way round. By default, a > at the beginning of a line should be treated as quotes. This is what people use to mark quotes. I did that above. Another exampe is, that the quotes are manually cut from one line into two to add comments like this: > This is one sentence. Here another Becomes: > This is one sentence. Reader's comment goes here. > Here another ~ enter manually More reader's comment here. This is broken by current behavior. It is another example of a program trying to know better what the users means. pi

It's not "broken". You will still get the quote chars on the other side. The only issue seems to be that mutt doesn't color hand written quotes sent from Mozilla. (It would work if you pasted your text into a blockquote in the formatting editor instead of adding '>' yourself in the plain text editor) You're also contradicting yourself. First you say that Mozilla should discover quotes and understand what the user means (which is impossible from the written text). Then you say that Mozilla shouldn't be smart and do things for the user. You obviously want Mozilla to do what _you_ want without having to tell it, but other users have different needs. I, for instance, when I studied maths often wrote mails with lots of '>' as part of expressions. I wouldn't like to have them misinterpreted as quotes just because they are used as quote chars too. Anyway, the space stuffing is part of format=flowed. If you don't like it, you can disable format=flowed sending. Changing the default in Mozilla would require turning off f=f which I don't think we want to do. What we could do is making it turned off in cases where we have no use of it (no lines longer than 70 chars, no blockquotes), but I don't know how to detect that without causing a performance hit.

Sigh. I was really afraid of this "not a bug" response. Which is why I suggested this in the original report: + Provide (and document) a method for turning off format=flowed in mail sent from the Mozilla mail editor. Happily, it looks like it *can* be turned off. How? Will this stop the silent munging of my input data? The bottom line, to reiterate, is that Mozilla's mail editor behaves very badly when the user composes quoted text in an external editor. Blaming mutt, which is interpreting the RFC correctly and not colorizing the space-prefixed quotes, seems like bad form to me. If the decision is that format=flowed is incompatible with external editors, then that's fine. But there needs to be a fallback or workaround for those circumstances.

I see it over and over again. People just assume that they will send what they see (and this is a very reasonable assumption). Andy, you can get rid of format flawed: http://www.hmetzger.de/net6e.html#10 pi

The point of format=flowed is to be correct, not to guess. Assuming that lines starting with > are quotes is a guess, because they might not be. We (Daniel, akk and me) discussed this or a very related issue in another bug, but I don't remember which one it was.

That's just pedantic nonsense. The editor cannot possibly know what the intent of the user was, so any interpretation if makes of a quote prefix is, by definition, a guess. Given a choice between "guessing" that the prefix means what it has *always* meant (for 20 years!) or the meaning handed down by a poorly understood and poorly implemented (and widely loathed, c.f. format=flawed) RFC, you appear to have made the wrong choice. There is a real world (!) Use Case here of why mangling quote prefixes is a bad thing. It causes RFC compliant mail readers like Mutt to misinterpret quotes pasted in from an external editor as literal "> " prefixes. What can the possible real world reasoning be behind the mangling? Have you ever seen a literal ">" at the beginning of a mail line that wasn't a quote? Ever? I'm happy with the "turn off format=flowed" option as the answer here (although I dearly wish it were available in the GUI). I just boggle at the lack of respect among the developers here for obscure technologies such as "cut-n-paste". Let me rephrase your responses in a less charitable manner: Mozilla doesn't support cut and paste of quoted text into the mail reader. If you didn't type it here, it's wrong and won't display reliably. Does that sound as dumb to you as it does to me?

I fully agree with Andy. People do not understand what you call correct, Ben. So there are two possible solutions: 1) If people enter a quote character, i.e. >, let it be a quote. 2) If you don't want to allow people to enter quote characters, make it absolutely clear in the editor, that this is not a quote character, i.e. either do not allow entering one at the beginning of the line or add a space already there, clearly visible. I bet, that as soon as 2) is implemented we get a new bug for the "most frequently reported" list. pi

> There is a real world (!) Use Case here of why mangling quote prefixes > is a bad thing. It causes RFC compliant mail readers like Mutt to > misinterpret quotes pasted in from an external editor as literal "> " > prefixes. So what RFC says that a "quoted" line must begin with a > and mustn't contain any whitespace before the '>'. At the contrary, RFC 2616 forbids us to send > at the start of the line if we doesn't _know_ that it's part of a quoted paragraph. I know I've said it before, but I'll say it again. You're putting things out of their perspective. All this about breaking display, that is really about a bug in mutt not understanding that a line starting with " >" is a quote. Have you ever seen a line that starts " >" that isn't a quote? Isn't that a bug in mutt? The mails look fine to me in Netscape 4, Mozilla, Outlook, OE, Eudore, less, pine, gnus and Pegasus. I haven't got any other mail programs to check with but I think it covers somewhere about 99% of all mail users. You say pasting into Mozilla is broken, but you can paste text into Mozilla and you can send the mail and the receiver can read all the text with the quote chars in front. So what else beside mutt's coloring isn't "working" as you would like it to? Everything you say suggest that it's a bug in mutt's AI - where mutt decides how to color lines. > What can the possible real world reasoning be behind the > mangling? Have you ever seen a literal ">" at the beginning of a mail > line that wasn't a quote? Ever? Yes. Not often but it happens. Let's as an experiment think about what would happen if this was fixed as you would like it to be fixed. Then every line starting with a ">" would have to be marked as a quoted paragraph. That seems fine, but what if the receiver decides to display each quoted paragraph a vertical margin? Then you would get a very sparse text and that would be much worse than "no coloring in mutt". In this case you're tricking the sender because the marking says "This is a quoted paragraph". Right now we just produce quotes that mutt's not well written enough to understand. A second solution would be to disable format=flowed when someone enters a "> at the beginning of the line, but wouldn't that be magic? How should a user know why it sometimes send f=f and sometimes don't. A program must be predictable. That could be an option anyway if it turns out that there really are some issues with the current handling, and I don't want to hear about mutt's coloring any more. Take that with mutt's author, not us. A third solution would be to detect quoted paragraphs and do automatic (implicit) rewrap. Don't take us there.

> All this about breaking display, that is really about a bug in mutt > not understanding that a line starting with " >" is a quote. Have you > ever seen a line that starts " >" that isn't a quote? Isn't that a bug > in mutt? > The mails look fine to me in Netscape 4, Mozilla, Outlook, OE, > Eudore, less, pine, gnus and Pegasus. I haven't got any other mail > programs to check with but I think it covers somewhere about 99% of > all mail users. This is patently false. Mozilla's reader has exactly the same behavior. Send a message that contains a quote prefixed by " >" and read it. It doesn't look like a quote, because the RFC promises that it is not a quote. Why doesn't it look like a quote? Because the editor space-stuffed garbage into the beginning of the line to make *sure* that it didn't look like a quote. Why did the editor do this? Because the editor thought it was smarter than the user about what a quote was. I'll take users over editors in a brain war any day of the week. > You say pasting into Mozilla is broken, but you can paste text into > Mozilla and you can send the mail and the receiver can read all the > text with the quote chars in front. So what else beside mutt's > coloring isn't "working" as you would like it to? And here we come to the real issue. It's not a bug, because you don't find it important (note the telltale use of the quoted "working" to indicate your disdain for the issue). I do; I've had several people complain (to me, not to you) that my mail is bad because the quotes don't colorize like they do from every other mail editor in the world. I've carefully formatted this message to have the same brain damage. Snip it out, and send it verbatim (via a command line sendmail or somesuch). Note that the first paragraph above is a quote (and remains a quote when you reply). The second is not, and displays verbatim ">" characters when you reply. > Let's as an experiment think about what would happen if this was > fixed as you would like it to be fixed. Then every line starting > with a ">" would have to be marked as a quoted paragraph. Again, untrue. You haven't read the RFC carefully enough. Successive lines beginning with the quote prefix are treated as part of the *same* paragraph, not different ones. The only way to get the behavior you posit would be to stuff extra line endings in. > Right now we just produce quotes that mutt's not well written enough > to understand. Or Mozilla. Maybe we should just chuck all these broken mail readers and go with outlook. :)

Ah, you use the auto-detection of quotes that Ben wrote for Mozilla? I don't and that's why I not see the difference. I apologize for my memory lapse about the standard and paragraphs, but my point still stands.

> 2) If you don't want to allow people to enter quote characters, make it > absolutely clear in the editor, that this is not a quote character, I may get pilloried for this, but it's sounding more and more to me like we should consider the option of showing quotes in plaintext mail with the "blue bar" when f=f is being used. If lines beginning with > aren't going to be sent as real quotes (i.e. lines beginning with >) then we're doing the user a disservice by displaying real quoted lines (lines sandwiched in a quote span, which will not be space stuffed) the same as other lines that currently begin with > but will eventually be space-stuffed. I know many plaintext mail users hate the blue bar; but the reason they hate it is that it indicates that "something different" is going to be done to the message before it's sent (that it will be sent as something other than what they see in their compose window), so in this case we'd be only being honest. jfrancis' CSS patch to bug 83378 will do a bit along these lines: "real" quotes (which won't be space stuffed) will be shown in plaintext compose as blue (but still show >, not the blue bar). (It will do this always, not only when f=f is on.) Daniel: > The mails look fine to me in Netscape 4, Mozilla, Outlook, OE, Eudore, less, > pine, gnus and Pegasus. "Fine" meaning all the quotes were shown as quotes, not just as space-stuffed unquoted lines beginning with >? Were you using the default settings on these mailers? I would have guessed that most of these mailers would do quote detection and show quoted text differently (I'm sure nearly all of them have that option). Didn't Netscape 4 show quotes as blue and italic by default? Pine doesn't colorize them by default, and neither does mutt, but it's easy to enable the behavior. It would be interesting to have stats on which mailers highlight quotes by default.

> "Fine" meaning all the quotes were shown as quotes, not just as space-stuffed > unquoted lines beginning with >? I just meant that I saw the text as quoted text, not mangled in any way. There might be extra formatting for quotes that weren't applied, but in that case I didn't notice it. Maybe I'm just not having as I high requirements on the display as some.

*** Bug 134341 has been marked as a duplicate of this bug. ***

I'm not sure, if this is the same bug, but I see this "space-adding" in more places (I _only_ use the plain-text editor): 1. I have a signature, that looks like this: /"\ ASCII RIBBON PS2-Assistent \ / CAMPAIGN X AGAINST HTML Jan Schnackenberg: snb@fh-wedel.de / \ IN MAIL AND NEWS Unfortunately Mozilla always adds a space before the "X" in the 3. line. If I view a message send by me in mozilla everything looks fine. In every other browser the 3. line is indented by one space. (Mozilla-users can see the space by displaying the message-code) 2. If I compose a message, which is formated into a table-like structure, and save that message as a draft or template, after reopening the message I see that every line, that started with a space, is indentet by one more space. Additionally I want to mention, that the behavior described by "pi" in comment #10 makes editing replies a real pain for me. And I do editing like that a lot (or I would do it, if it would work). I'm not sure, if there _is_ a RFC that describes how a quote in an e-mail/newsposting should look, but if I type an ">" at the beginning of a line, I _expect_ that that char stays exactly there without any spaces added before it. (Just like I don't expect the spaces that are added in the above mentioned cases) If that line is "wrongly" colored/highlighted as a qoted line in any other readers, that is _my_ (read the mail-writers) fault. But if Mozilla adds additional characters (without showing them in the editor) I don't even have the chance to "correct" it's missconception about knowing better than I do.

Akkana, you say: [the following quotes hand-marked, would not work wit f=f;-)] > I may get pilloried for this, but it's sounding more and more to me like we > should consider the option of showing quotes in plaintext mail with the > "blue bar" when f=f is being used. I agree, that would do it. This (or similar) is in bug 133741, which is already marked as blocked by this bug. pi

jan wrote: > Additionally I want to mention, that [this] makes editing replies a real pain > for me. And I do editing like that a lot (or I would do it, if it would work). Are you saying that you cannot edit quotes (e.g. replace parts of sentences with "...") (with the quote still being recognized as that)? This would indeed be very broken, but that's *not* this bug. It would e.g. be solved by akk's suggestion of using blue bars (which I think would be a good idea, if the blue bars didn't have that "HTML taste" and would thus alienate plaintext composer users), which still leaves this bug open - you'd still be unable to manually insert ">" as quote marks at arbitary places. Jan, what you are critizing with the doubled spaces is format=flowed, not Mozilla's implementation (I think). > I _expect_ that that char stays exactly there without any spaces added before > it. I guess we have some clash of POVs here. You want to compose the msg as it will be sent *on the wire*. I am not sure that's possible or a good idea. IMO, you cannot express all which (even plaintect composer) users want to express with the 7bit US-ASCII or at best 8bit Latin-1 characters that we are restricted to in plaintext on the wire. As soon as we need to exceed that, e.g. - compose Japanese mails - add rare characters - make the msg readable on anything else that 80-char-wide displays - reliably mark quotes we have to use some additional encoding standard. That encoding will often (sometimes necessarily) break the assumption that one typed character equals one byte in the msg on the wire. Now, if both the sending and the recieving mailer support the same encoding standard *and* the standard is designed to be non-altering (i.e. input=output - not sure, what the right term for that is), only then can you assume that the recipient will see the same that you see. That is, unless the standard (probably intentionally) leaves the implementor or user on the recieving side freedom to display the msg as he likes, within some limits - in the case of format=flowed, the line-width is a preference of the recipient. But, if the recipient doesn't support the same encoding, then you do not see the same that you composed. That's the problem you hit here and why Jan's sig looks correct in Mozilla, but not in some other mailers and not in View Source. Note that traditional plaintext mail is *not* such a non-altering standard - there are several circumstances, where you have to "munge" (non-reversibly change) the msg to process it further. For example, a dot on its own line terminates the msg on SMTP (the mail transport format of the internet). Thus, such a line, when written by a user, has to be altered to transmit the rest of the msg. Similarily for "From " at the beginning of a msg (this time, it's popular software that doesn't like such lines, including Sendmail (IIRC) and Mozilla). So, in summary, your expectation that you send - on the wire - what you wrote is wrong, and that's not a bug, but inevitable. Back to this bug: I suggest to 1. assume that bug 133741 (color real quotes in plaintext composer) will be fixed 2. preserve the quote while editing, similar to the HTML composer. I don't know, how to achieve that. 3. give the user some way to insert new quotes (similar to the HTML Composer's Paste As Quotation) I don't think that demanding support for external plaintext editors is reasonable. Maybe we'll do that explicitly in the future (other RFE), but in the meantime, I think that being able to disable format=flowed in the backend prefs is sufficient. Frankly, I find it surprising that you complain about missing color coding in mutt, saying that we didn't send what you wrote, when mutt displays the mail *exactly* as you composed it, just without the usual prettying-up. How is that a bug worth enough to discuss that long? Or a bug at all? We have far greater problems.

Ben wrote: > Are you saying that you cannot edit quotes (e.g. replace parts of > sentences with "...") (with the quote still being recognized as that)? Uhm, actually, that was not exactly what I was saying. Still I seem to have made a fool out of myself there, though, because I never noticed, that the behaviour I was wishing for (splitting a quote into 2 parts in the middle of a line, with the second part being recognised as a quote after prepending a ">" to its first line) is now working. Sorry. Aside from that Ben gave me something to chew on (read: think about). Thanks for some clarification about some cases where the code of "plaintext" messages has to be altered. Just one question remains: I'm aware of the need to "code" some Information (like the "." or the "From: " for example) but I don't understand why there is a need to put spaces in front of an ">". Someone has to have written the code to do that, and maybe I'm blind, but I just cannot understand the reason for this extra work from the comments in this bug. The user types an ">" at the beginning of a mail, and as far as I know Mozilla is the only MUA that prepends a " " to such a line.

The space is part of format=flowed and any RFC2646 compliant MUA add that space. I just tested Eudora and it added the space as well. Any MUA recognizing format=flowed also removes the space when displaying the mail so if you read mail in one of those you might just not have noticed. The space is there to be able to see the difference between quoted text and text written by the user. Some people here want to automatically convert any line starting with a ">" to a quote when sending, but that wouldn't be very nice. What we do need is a way to insert text as quoted. Eudora has it, both with "Paste as quotation" and "Increase/decrease quote level".

For comment 26: > Uhm, actually, that was not exactly what I was saying. Still I seem to have > made a fool out of myself there, though, because I never noticed, that the > behaviour I was wishing for (splitting a quote into 2 parts in the middle of a > line, with the second part being recognised as a quote after prepending a ">" > to its first line) is now working. Sorry. Are you saying, that you enter a > at the beginning of the line and it is not space stuffed? pi

pi: correct. Steps to reproduce: - take a message in your inbox, start a reply to it and replace the recipient by yourself. - take any line inside a quoted paragraph an insert a linebreak there - you notice that the "remainder" of the original line doesn't have the quotation-">" - insert a ">" at the beginning of said "remainder" - send the message (to yourself) - view the message -> there is no space in front of that ">" and it is recognized as being "quoted"

> 3. give the user some way to insert new quotes (similar to the HTML Composer's > Paste As Quotation) ... which we already have, right there in the edit menu (also ctrl-middleclick on linux). Of course, on linux the one in the edit menu always seems to be greyed out, but that would be a different bug (some kind of command enabling problem in the mail compose window) which I hope is already filed. > - take any line inside a quoted paragraph an insert a linebreak there > - you notice that the "remainder" of the original line doesn't have > the quotation-">" > - insert a ">" at the beginning of said "remainder" That's because the block of text is already marked as a quotation since it was the second half of a quoted block that got split. When Joe's fix to turn quoted text blue goes in, the difference will become more obvious. (Hmm, Joe isn't cc'ed on this bug; he should be.)

OK, after reading this *very* long discussing I believe that I have a sequence of steps that is more clearly a bug: 1) Start replying to a message. 2) Highlight several lines of quoted text. 3) Edit -> Cut (or Edit -> Copy) 4) Go to another place in the message (not inside quoted text) 5) Edit -> Paste 6) Send message. Expected: pasted text is sent as quoted (is this scenario we *know* for sure that is was quoted, no guessing necessary). Actual: pasted text gets "space-stuffed" quotes. If some of the original quoted text remains, you'll see a weird-looking ugly mixture of real quotations (displayed with a grey blockquote bar by Mozilla), with "> "-prefix quotations... P.S. You get the same result if you cut&paste across two composition windows instead of within the same one. This is useful if you want to respond to two messages from a single person in one message. P.P.S. The only workaround I know is to do "Paste as quotation" instead of "Paste" and then to delete on every pasted line the second ">" symbol from resulting ">> " prefixes. I so hate having to do this every time...

Aleksey, your description is correct. There is another work-around, which is to switch of format flawed. pi

Aleksy, to quote from two messages, reply to one of them, then select the second in the message list pane and choose "Options » Quote Message" in the compose window. (I do this all the time!)

I hope the blue text for message-compose quotes is at least helping folks detect this situation, and helping them remember to paste as quotation when that's what they need to do. I don't know why kin wons this bug. Is there anything in the editor that is doing any of this? If so I don't know about. I assumed it was the serializer at copy time.

How about detecting that someone pastes text where lines start with '>' characters and ask the user if she wants to paste the text as a quotation? It doesn't seem very easy to me, but neither is any other "solutions".

We need to do something. It is really annoying that cut and paste fails badly. pi

*** Bug 199776 has been marked as a duplicate of this bug. ***

*** Bug 226200 has been marked as a duplicate of this bug. ***

I was going to submit a bug per the situation described in msg #31. Space-stuffing "> " into " >" violates POLA, the Principle of Least Astonishment. Let's pretend that some user wanted to use Mozilla to send mail automatically, perhaps via copy-n-paste, or perhaps via a script of some sort: 5-sec% echo 'From: chuck To: chuck Subject: a test... You called on the phone, and asked: > Hungry? Let's go to Maganaro's and eat... ...in order to test what would happen if you emailed back a response. -- -Chuck ' | sendmail One could use another MUA like /usr/bin/mail, or pine, mail-mode in Emacs, or even a different MTA like Postfix instead of sendmail. I don't know whether Mozilla has a command-line "mozilla-mail" application to which one could pipe a message into, but let's pretend it did. mozilla-mail should behave like other MUAs in that it should add certain headers (eg, "Date: ", "Received: ", et al), perhaps MIME content type info if needed considering the message contents, the user's locale, and so forth. Let's imagine looking at the results of sending that message above via all of the various MUAs, local delivery, remote delivery, MTAs, and so forth, and then consider what happens to the line "> Hungry? ...". Oddly enough, and unlike what Mozilla does, they all refrain from mangling the "> " into " >". Everybody hum together now: One of these MUAs is not like the Others, One of these MUAs is not quite the same... Section 4.4 of RFC 2646 makes the following comparision: "(Note that space-stuffing is similar to dot-stuffing as specified in [SMTP].)" And indeed, people familiar with RFC-2822 and MTAs like Sendmail or Postfix et al, know that they provide an option as to whether or not to do so: -i Ignore dots alone on lines by themselves in incoming messages. This should be set if you are reading data from a file. [ ...or... ] -i When reading a message from standard input, don't treat a line with only a . character as the end of input. What flag does one need to use for my imaginary mozilla-mail MUA, or what user-preference does one need to set in the real-world Mozilla application, to not space-stuff ">" analogous to the way "sendmail -i" works? Either that, or give me an explaination that I can satisfy a User why that User can't send an email message with a ">" symbol in the first column of a line of text? -- -Chuck

Any motion on this bug? Have the people who think it's not a bug changed their minds? The issue is still present in current Mozilla and Thunderbird releases, and I continue to have to hack my preferences every time I install or use a new versions.

It certainly *feels* like a bug to me. I always use my own text editor to write e-mail and newsgroup posts. So far, I've been getting around the space-stuffing before ">" by saving the message to drafts, and then doing an "Edit as new" on it. Maybe there could be a "Paste literal" action? "Paste as Quotation" doesn't quite do it, because an extra ">" is added at the beginning of every pasted line, and the composer doesn't seem to have any ability to mark (select) a column. If the composer *must* change a ">" at the beginning of a line to " >", at least give us an easy way to edit out the extra spaces.

*** Bug 250529 has been marked as a duplicate of this bug. ***

*** Bug 264893 has been marked as a duplicate of this bug. ***

Not an editor function, the space-stuffing happens in the sending process.

(In reply to comment #44) > Not an editor function, the space-stuffing happens in the sending process. In that case is there a bug report for that? I am still unclear if I am talking about the same bug. I see a lot of emails generated by Thunderbird , Mozilla (including my own emails) which quote like this: > it hadn't occurred to me that an .xml template > would be in the middle of that list of users > in the "contacts" folder. That looked like a list, > exclusively for users. Or else, I would have > found it on my own These quote marks were "space-stuffed" at some point - I see it mor and more as TB is used more. I think this is serious, but am new to bug reporting, am I on the right track here?

The best workaround right now is to turn off the sending of f=f messages in your prefs.js file. user_pref("mailnews.send_plaintext_flowed", false); I have been doing this regularly for every Mozilla/Thunderbird installation I do for the last two years, and will probably be doing so on my deathbed. Folks, f=f is a disaster. It tried to shoehorn rich-text-like paragraph semantics onto a plain text framework in a bidirectionally compatible way, and it failed. It works well only in the utopian environment where users never touch the quoted text they see in their composer windows. Using it by default is just dumb. The benefit of this feature (paragraphs that wrap to the reader's window size) is minor at best, and the cost is a very confusing and erratic user experience, even for those who are supposed to be experts at this stuff. You literally need to read the RFC (or the elaborate FAQ in bug 168420) to understand why your quotes look wrong, or why the line wrapping is strange. Is that really the editor experience you want for your users?

(In reply to comment #45) Yes, what you are showing is a classic example of Mozilla space-stuffing quoted text. (In reply to comment #46) > Folks, f=f is a disaster. It tried to shoehorn rich-text-like > paragraph semantics onto a plain text framework in a bidirectionally > compatible way, and it failed. It works well only in the utopian > environment where users never touch the quoted text they see in their > composer windows. Using it by default is just dumb. format=flowed works just fine with Apple's Mail.app over in MacOS X. Mail.app handles pasting and editting of quoted text just fine, simply because it does not attempt to rewrite "> " as " >". > The benefit of this feature (paragraphs that wrap to the reader's > window size) is minor at best, and the cost is a very confusing and > erratic user experience, even for those who are supposed to be experts > at this stuff. You literally need to read the RFC (or the elaborate > FAQ in bug 168420) to understand why your quotes look wrong, or why > the line wrapping is strange. Is that really the editor experience > you want for your users? Nope, I just want this bug fixed properly. The rest of f=f, such as breaking up paragraphs at 76 columns for the 80-column impaired works just fine, the only problem is with the Mozilla Mail Composer re-formatting user-entered text.

*** Bug 252913 has been marked as a duplicate of this bug. ***

This looks to be related to bug 298485

*** Bug 298485 has been marked as a duplicate of this bug. ***

I said related , not duplicate of bug 298485. Bug 141983 also deal with corruption done by spacestuffing. And I would like to note that the .flf datafile in my testcase in bug 298485 have only 2 ">" qoutechars and none are at the beginning of a line , yet most of the file have been corrupted by space-stuffing. I can't see a logical pattern to which lines it will spacestuff and which it wont. It is possible however that this bug , bug 298485 and bug 141983 are all just multiple problems caused by one bug in the code. If bug 298485 is a duplicate of this bug then it is clear that the problem is more serious than first stated .. this doesn't just affect quotes but many other cases as well. This problem _needs_ fixing , you can't just say people affected by it should use the workaround in #46 - Most people don't know of this workaround and will switch to a working mail/news client (other clients does not foul up the testcase in bug 298485)

*** Bug 320071 has been marked as a duplicate of this bug. ***

*** Bug 363936 has been marked as a duplicate of this bug. ***