1797510 - Replying to/forwarding an OpenPGP-signed plain text message adds one extra space to the beginning of each line originally starting with at least one space

Status: NEW

(MailNews Core :: Security: OpenPGP, defect)

Description

[id082]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

(1) Create a new plain text message containing, e.g.,

|Message, line 1
|  Message, line 2
|  Message, line 3
|Message, line 4

where "|" denotes the left edge of the compose text field. That is, lines 1 and 4 are not indented at all, while lines 2 and 3 are indented using two spaces.

(2) Set the message to be OpenPGP-signed, and send it to any e-mail address.

(3) Select the recently sent message in the Sent folder and click Reply (or Forward).

Actual results:

In the newly opened compose window (again, "|" denotes the left edge of the compose text field):

ACTUAL RESULT (Reply):

|> Message, line 1
|>    Message, line 2
|>    Message, line 3
|> Message, line 4

ACTUAL RESULT (Forward):

|Message, line 1
|   Message, line 2
|   Message, line 3
|Message, line 4

That is, lines 2 and 3 are in both cases indented using three spaces instead of the original two.

In some e-mail clients (e.g., Microsoft Outlook, Zimbra webmail, Gmail web interface), even the original message sent in Step 2 of "Steps to Reproduce" is displayed with the discussed extra spaces.

The problem described in this bug report is most noticeable in pre-formatted plain text email signatures (those following "-- "; not to be confused with OpenPGP signatures).

Please note that messages that are not signed using OpenPGP are not affected. However, the very old bug https://bugzilla.mozilla.org/show_bug.cgi?id=608514 may perhaps still be relevant to the present issue...?

Expected results:

EXPECTED RESULT (Reply):

|> Message, line 1
|>   Message, line 2
|>   Message, line 3
|> Message, line 4

EXPECTED RESULT (Forward):

|Message, line 1
|  Message, line 2
|  Message, line 3
|Message, line 4

Comment 1

[Calum Mackay]

confirmed.

I've seen it for some time, and kept forgetting to log a bug, so thank you.

For me, I see it with Edit-as-new.

And indeed it only affects composing of signed email; non-signed is fine. And the original message being edited itself is displayed fine, too.

Daily 108.0a1 (2022-10-22) (64-bit)
MacOS 12.6

Comment 2

[id082]

Thank you for the additional information. I use the respective feature ("Edit as New Message") so rarely that I completely forgot to test it alongside Reply and Forward.

As for the original message being displayed correctly, that is not universally true (as I mentioned in my original post). Because multiple different email clients (on the recipient's side) show the extra spaces, too, I would not discard the possibility that something fishy happens at the very beginning when the message is being sent. For example, a message reading ("|" denotes the left edge of the compose text field)

|m line 1
|  m line 2
|    m line 3

is base64 encoded by Thunderbird into

--------------<MSG_PART_ID>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

bSBsaW5lIDENCiAgIG0gbGluZSAyDQogICAgIG0gbGluZSAzDQo=

--------------<MSG_PART_ID>--

which, when decoded back using, e.g., www.base64decode.org produces

|m line 1
|   m line 2
|     m line 3

Note that in the decoded output above, the extra spaces are present (2nd line is indented by three spaces instead of two, 3rd line by five spaces instead of four).

Comment 3

[Calum Mackay]

thanks for clarifying; I ought to have added "in my experience, the original message generally seems to display fine". But not in all cases, it seems.

Comment 4

[Calum Mackay]

I was also ambiguous in my comments about signing.

For me, it's whether the original message was sent signed, or not, that is important. When I subsequently Edit-as-new that message, if that message was signed, I see the problem. If it wasn't signed, I don't. In both cases the new compose window, where I see the problem, has signing enabled by default.

It's the signed/non-signed status of the original message, that is being Edited-as-new (or forwarded, replied to) that is relevant. Not whether the new composition is signed or not. At least, that's what I see.

Comment 5

[id082]

For me, it's whether the original message was sent signed, or not, that is important.

Yes, that is exactly my experience. (Again, "signed" refers to OpenPGP, not the regular email signatures usually following "-- ").

Comment 6

[id082]

One more thing that probably is relevant: when the sample message considered a couple of posts before, i.e.,

|m line 1
|  m line 2
|    m line 3

is sent without an OpenPGP signature, in the message source one finds

|Content-Type: text/plain; charset=UTF-8; format=flowed
|Content-Transfer-Encoding: 7bit
|
|m line 1
|   m line 2
|     m line 3

That is, the extra spaces are present. I checked again and unsurprisingly, multiple different email clients do display the received (unsigned) message as

|m line 1
|   m line 2
|     m line 3

even though Thunderbird displays it as the sender had intended.

Although I am not completely sure as to how the message source after conversion to format=flowed should look like, couldn't the culprit be the -- possibly incorrect -- conversion itself?

Comment 7

[Kai Engert [:KaiE:]]

Does this extra space cause any problem?
(Besides the the fact that it shouldn't be there.)

Comment 8

[Paul Menzel]

Does this extra space cause any problem?

No, no “non-stylistic” problems as far as I can see.

Comment 9

[Calum Mackay]

It causes a problem if you're using spaces to align columns etc, obviously.

And I often do that, because using tabs doesn't seem to work reliably (or in the past it didn't at least).