121946 - Need to escape "From " line in the message body when saving or copying message.

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Cavin Song]

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.

Comment 1

[Scott MacGregor]

double filed? 

*** This bug has been marked as a duplicate of 121947 ***

Comment 2

[Cavin Song]

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

Comment 3

[R.K.Aa.]

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

Comment 4

[Boris 'pi' Piwinger]

This is not limited to windows.

pi

Comment 5

[Rob North]

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.

Comment 6

[Mike Cowperthwaite]

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.

Comment 7

[Rob North]

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.

Comment 8

[Mike Cowperthwaite]

QP doesn't change the content-type; it's specified as:

  Content-Transfer-Encoding: quoted-printable

Comment 9

[Rob North]

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.

Comment 10

[Mike Cowperthwaite]

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

Comment 12

[Alessandro Vesely]

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

Comment 13

[Wayne Mery (:wsmwk)]

Ben, no longer an issue?