This bug is extended from bug 119441. We need to make sure that the way we escape "From " lines in the msg body during saving and copying msgs to local folders is consistent with the logic used in the Outlook and Eudora import code. Here is how escaping should wprk: If you have this line Escape it to Comment --------------------- ------------ ----------------- From now on >From now on >From now on >>From now on >>From now on >>>From now on >/>From now on >/>From now on No need to escape From now on From now on No need to escape Note that the above example lines start at the beginning of a line (ie, column #1). And we need to do it in the following scenarios: 1. When saving draft/template msgs to local folders. 2. When saving "Send Later" msgs. 3. When coping msgs from (imap) server folders to local folders.

double filed? *** This bug has been marked as a duplicate of 121947 ***

121946 and 121947 are different. One is to escape and another is to unescape "From " line.

Will this bug (and bug 121947) fix bug 120443? Note bug 120443 comment 3

This is not limited to windows. pi

This bug is also related to bug 194382. You may also wish to look at bug 194382 Comment #8, regarding the different mbox formats available.

Rather than escaping the From line, how about converting to quoted-printable when a From is discovered and changing the F to =46 ? xref bug 259564.

Would this work for plain ascii attachments? Would you want to transform plain ascii attchments to quoted printable before the message is entered in the mail store? What if you want to ask the question: What mime format did the sender use? This question cannot be answered, if attachment/body type is changed. I think the transform proposed in the description is best. It is a transform that is part of the mbox standard.

QP doesn't change the content-type; it's specified as: Content-Transfer-Encoding: quoted-printable

Indeed, my comment should have referred to the "Content-Transfer-Encoding" field. Therefore I'll re-state my argument in a less abbreviated, and more considered form: What I expect from a fix to this bug is something that prevents data loss. The current method of encoding "From " lines is not reversible. You cannot tell wether a ">From " in the mbox was present in the original message,or encodes a "From " line. Therefore there is data loss. The method presented in the bug's description prevents data loss, by a reversible encoding. Mike, your method removes data loss from the message body, and moves it to the "Content-Transfer-Encoding" field. Why? Because you have lost the ability to determine what encoding was used to send the message to you. You may ask why should anyone care about content transfer encoding? Because it can be useful in resolving problems with broken e-mails. If a problem with the encoding exists, then it should be possible to help the sender work around it. There is also another reason for accepting the fix proposed in the description... Because it is the accepted soloution to this problem by programs that use the mbox format. On the grounds of best practice alone, I'd prefer to fix the mbox format over modifying the encoding type.

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

The trend seems to be toward universally use UTF-8, in the body and header alike. I hope that quoted-printable and on-the-fly MIME autoconversion will fade out, and would not base new code on that stuff. RFC 3676 is primarily concerned with quoting. However, by space-stuffing all unquoted non-empty lines, one can provide for a portable, nice-looking method of escaping "from ". Space-stuffing, and setting format=flowed, could also be done without actually causing paragraphs to be re-flowed (as it may inadvertently happen when recovering from Drafts.) It can be considered just a standard escape: On generation, any unquoted lines which start with ">", and any lines which start with a space or "From " MUST be space-stuffed. Other lines MAY be space-stuffed as desired. http://tools.ietf.org/html/rfc3676#section-4.4