TB 1.0, etc. If you set the plain-text wrap column to zero, the text normally gets sent one line per paragraph: no newlines except those typed by the user. With a very long paragraph without a newline, Mozilla will break the line at column 990[1], so as to fall within the SMTP limit of 1000-characters per line (maybe also an NNTP limit?). The problem is that the break is not smart -- it will (sometimes) split a word, or break between a word and the space following which will screw up the reflow of the text processed as f=f. To reproduce: 1) Set wrap column to 0 2) Open a plain text mail compose window. 3a) Type in "123456789 " -- then copy and paste nine of those in. Resize the window so that this text just fits on one line, copy the entire line and paste it onto the end of the first line, nine times -- this gives a 1000 character "paragraph." 3b) Replace the last "123456789" with some other, lengthy, identifiable string (say, FINALTOKEN). Type a few CR's at the end of the buffer. Copy the entire paragraph (including the CR's), then paste again so that there are a total of five paragraphs 3c) Edit the penultimate word (the last "123456789") in the first two paragraphs so that it's "1234567890"; in the fourth so that it's "12345678"; and in the last paragraph so it's "1234567". 4) Send it (or Send Later) and look at the resulting buffer. [1] Or at 991 for the first line (OR?? "if f=f is turned off" -- per bug 169395 comment 0) Actual results: Paragraphs are wrapped as follows: ... 1234567890 <- zero trailing space [line length = 991] FINALTOKEN <- one leading space ... 123456789 <- zero trailing space 0 FINALTOKEN ... 123456789 <- zero trailing space FINALTOKEN ... 12345678 <- one trailing space FINALTOKEN ... 1234567 F <- zero trailing space INALTOKEN Expected results: ... 123456789 <- one trailing space (at column 980) 1234567890 FINALTOKEN ... 123456789 <- one trailing space (at column 980) 1234567890 FINALTOKEN ... 123456789 <- one trailing space (at column 990) FINALTOKEN ... 12345678 <- one trailing space (at column 989) FINALTOKEN ... 1234567 <- one trailing space (at column 988) FINALTOKEN

Whoops, I erred slightly: in the third paragraph of the sample, the actual results are: ... 123456789 <- zero trailing space FINALTOKEN <- one leading space

When re-editing such a received mail as new, the result is: ... 123456789 <- extra newline FINALTOKEN Probably related: Bug 155622 and its many dups.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Apparently a duplicate of Bug 169395. Still present in TB 3.0b4.

Related, but not a dupe.