Bugzilla

To me it looks like this bug, at least as described in comment 0 and in several duplicates, is no longer an issue. The fix seems to be the fact that text attachments are now base64 encoded. This solution was suggested in comment 7 but I'm pretty sure base64 encoding of text attachments was not done in response to this bug but, as a side-effect, fixed this bug.

There also does not seem to be a problem with body lines beginning with "From " in general with TB generated mbox files since on composing "blank stuffing" is used so no text line begins with ```"From "``` but become ```" From "``` and the leading blank is removed before displaying the message. But this is not really the subject of __this__ bug.

I tried to duplicate Alessandro's comment 35 description. I composed an email with a leading "From " in the body and saved it to an imap mbox storage. The "stuffed blank" was present before the "From" but displayed with no blank. On copy to a Local Folder, the message was not quoted with ">" and had no leading space.  The Local Folder mbox file did contained the stuffed space before the From. But, again, this is not really the subject of this bug since it doesn't involve an attachment. Or does it, maybe I'm reading the memory dumps wrong?

So for now, I'm marking this as INVALID.

To me it looks like this bug, at least as described in comment 0 and in several duplicates, is no longer an issue. The fix seems to be the fact that text attachments are now base64 encoded. This solution was suggested in comment 7 but I'm pretty sure base64 encoding of text attachments was not done in response to this bug but, as a side-effect, fixed this bug.

There also does not seem to be a problem with body lines beginning with "From " in general with TB generated mbox files since on composing "blank stuffing" is used so no text line begins with ```"From "``` but become ```" From "``` and the leading blank is removed before displaying the message. But this is not really the subject of __this__ bug.

I tried to duplicate Alessandro's comment 35 description. I composed an email with a leading "From " in the body and saved it to an imap mbox storage. The "stuffed blank" was present before the "From" but displayed with no blank. On copy to a Local Folder, the message was not quoted with ">" and had no leading space.  The Local Folder mbox file did contain the stuffed space before the From. But, again, this is not really the subject of this bug since it doesn't involve an attachment. Or does it, maybe I'm reading the memory dumps wrong?

So for now, I'm marking this as INVALID.

To me it looks like this bug, at least as described in comment 0 and in several duplicates, is no longer an issue. The fix seems to be the fact that text attachments are now base64 encoded. This solution was suggested in comment 7 but I'm pretty sure base64 encoding of text attachments was not done in response to this bug but, as a side-effect, fixed this bug.

There also does not seem to be a problem with body lines beginning with "From " in general with TB generated mbox files since on composing "blank stuffing" is used so no text line begins with ```"From "``` but become ```" From "``` and the leading blank is removed before displaying the message. But this is not really the subject of __this__ bug.

I tried to duplicate Alessandro's comment 35 description. I composed an email with a leading "From " in the body and saved it to an imap mbox storage. The "stuffed blank" was present before the "From" but displayed with no blank. On copy to a Local Folder, the message was not quoted with ">" and had no leading space.  The Local Folder mbox file did contain the stuffed space before the From. But, again, this is not really the subject of this bug since it doesn't involve an attachment. Or does it, maybe I'm reading the memory dumps wrong?

So for now, I'm marking this as INVALID.

Edited P/S: Text attachments by default are not displayed inline unless pref mail.inline_attachments.text is set true. So, even without base64 encoding, text attachments will not, by default, cause a problem when lines begin with "From ".
However, 3rd party mbox or eml files that don't have "blank stuffed" or ">" escaped "From " lines will start a new message at that point when placed in a Local Folder (again, not a concern of this bug).

To me it looks like this bug, at least as described in comment 0 and in several duplicates, is no longer an issue. The fix seems to be the fact that text attachments are now base64 encoded. This solution was suggested in comment 7 but I'm pretty sure base64 encoding of text attachments was not done in response to this bug but, as a side-effect, fixed this bug.

There also does not seem to be a problem with body lines beginning with "From " in general with TB generated mbox files since on composing "blank stuffing" is used so no text line begins with ```"From "``` but become ```" From "``` and the leading blank is removed before displaying the message. But this is not really the subject of __this__ bug.

I tried to duplicate Alessandro's comment 35 description. I composed an email with a leading "From " in the body and saved it to an imap mbox storage. The "stuffed blank" was present before the "From" but displayed with no blank. On copy to a Local Folder, the message was not quoted with ">" and had no leading space.  The Local Folder mbox file did contain the stuffed space before the From. But, again, this is not really the subject of this bug since it doesn't involve an attachment. Or does it, maybe I'm reading the memory dumps wrong?

So for now, I'm marking this as INVALID.

Edited P/S: Text attachments by default are not displayed inline unless pref mail.inline_attachments.text is set true. So, even without base64 encoding, text attachments will not, by default, cause a problem when lines begin with "From ".
However, 3rd party mbox or eml files that don't have "blank stuffed" or ">" escaped "From " lines will start a new message at that point when placed in a Local Folder (again, not a concern of this bug).
PP/S: I found this bug report while browsing the Import/Export Tools code here:
https://github.com/thundernest/import-export-tools-ng/blob/master/src/chrome/content/mboximport/exportTools.js#L2001