User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Build Identifier: version 2.0.0.23 (20090812) I sent a message with an attached file that contained a "From " line (because it was a message from a mailbox). I use Enigmail 0.96.0. I chose to "Encrypt/sign each attachment separately and send the message using inline PGP". The attachment passed to Enigmail for signing apparently contained the unescaped "From " line. Enigmail created the signature attachment, and then apparently subsequently, Tbird escaped the "From " line to ">From " in the sent message, thus breaking the signature. Reproducible: Always Steps to Reproduce: 1.Compose a message 2.Attach a plain text file containing a "From " line 3.During sending, sign, but don't encrypt the the message and chose "Encrypt/sign each attachment separately and send the message using inline PGP". Actual Results: The line From xxxxx@yahoo.com Sat Nov 14 02:26:23 2009 in the attachment is changed to >From xxxxx@yahoo.com Sat Nov 14 02:26:23 2009 after the attachment has been signed. Expected Results: Either the "From " line should be escaped in the attachment before passing the attachment to Enigmail for signing, or the "From " should be dealt with differently after signing, e.g. by base64 encoding the attachment or QP encoding the 'F' This was reported to Enigmail as <https://www.mozdev.org/bugs/show_bug.cgi?id=22018>. They say in essence that it isn't their problem.

Duplicate of bug 121947 ? Cannot reproduce this with TB3 and Enigmail 0.97 (From lines appear to get escaped with '- ' and also unescaped)

I don't think this is a duplicate of bug 121947. That bug has to do with unescaping escaped From lines for display in the UI. That is not what this bug report is about. This bug is also not fixed in the released version of TBird 3.0 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0) with Enigmail 1.0 on Windows XP. The escaping with '- ' and unescaping does occur with From lines in the signed message body, but this report is not about that. This report is about From lines in attached files that are separately signed. It appears that the signature is created using the original attached file contents, and then the "From " line in the attachment is subsequently escaped to ">From ". Then when the message is received, and the attached file and it's signature are locally saved, the signature doesn't verify because the locally saved attachment still contains ">From ". This is easy to duplicate. 1) Create a .txt file containing a line beginning with "From ". 2) Compose a message and attact the file from step 1. 3) Send the message and during sending, sign, but don't encrypt the the message and chose "Encrypt/sign each attachment separately and send the message using inline PGP". 4) When the message is received, save the attached .txt and .txt.sig parts. 5) Attempt to verify the signature with pgp.

I think it's at least similar to bug 121947. In the case here it's not about displaying but when saving. But if done properly, then a fix for bug 121947 should also fix the bug here.

Difficulties in this bug. 1. Tb(and/or enig mail, ...) has to escape "From line" upon save of mail data into Unix Mbox file which Tb uses. 2. Once mai is saved in Unix Mbox file, it's impossible to distingush next two; (a) Mail data has ">From ..." since initial, and is sigened with it. (b) Mail data dosn't have ">" initially, and is sigened with "From ...". It's well known design flow of "Unix Mbox". If simple text mail, adding/removing ">"(and some other characters for escaping of "From line") won't produce severe problem, but it'll produce critical issue if signed mail. I think bug 121947 can't resolve all problems of this bug. I believe that "Stop to use Unix Mbox file" is mandatory to resolve this bug. Note: Tb currently uses " "(space) for escaping of composed mail if format=flowed, but uses ">" if non-format=flowed mail as old Mozzila does. When non-format=flowed mail is saved in Drafts, Tb saves with ">From ...", but Tb doesn't unescape it upon "Edit Draft". (Old Mozilla unescaped in this case.) bug 121947 can resolve this issue.

(In reply to comment #4) > Difficulties in this bug. [...] > 2. Once mai is saved in Unix Mbox file, it's impossible to distingush next two; > (a) Mail data has ">From ..." since initial, and is sigened with it. > (b) Mail data dosn't have ">" initially, and is sigened with "From ...". > It's well known design flow of "Unix Mbox". This entire situation could be avoided by qp encoding the message part and changing "From " to "=46rom " instead of changing "From " to ">From " in an unencoded part.

(In reply to comment #5) > This entire situation could be avoided by qp encoding the message part and > changing "From " to "=46rom " instead of changing "From " to ">From " in an > unencoded part. If draft mail(or Edit As New mail), there is no issue. Upon save, change to QP and use =46 or change to Base64, and upon Edit Draft, characters are properly displayed as text, and if user removes "From line", no escaping by QP/Base64 is needed. For copy of sent mail or downloaded mail: Such conversion means that mail data in Unix Mbox file is different from real mail data stream. Is it problem, isn't it? (Escape by ">From " has same problem too. And, ">From " corrupts data but escape by QP or Base64 won't corrupt data. "different from mail data stream" is far small problem than "mail data corruption". So I think escape by QP is very good idea. ) Escaping by "QP and =46" may produce problem if signed mail. No possibility of problem?

If "QP + =46 for F" is used, Tb should be torelant with special data from external - downloded mail, imported mail, imported mail from .eml(Tb3 supports Drag&Drop of .eml file to mail folder). - "From line" in message header => What should we do? What can we do? - Quoted-Printable part has "From line" : F to =46 is sufficient. - Base64 part has wrong "From line" => What should we do? What can we do?

Another case. - Downloaded mail is signed mail, and has "From " line in mail data. Unless unescaping is properly executed by Tb before mail data is passed to enigmail, similar problem to comment #0 occurs.