1673798 - Give a hint to the user that the mail format is invalid PGP/Inline message on email body and not able decrypt

Status: RESOLVED DUPLICATE of bug 1672851

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[robbinespu]

Attachment: Capture.PNG

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Steps to reproduce:

1. send plain email to [e-mail] and grab her public key when she replied (verified)
2. replied her email with your encrypted message and public key
3. She will reply with PGP message on email body (not as attachment)

Actual results:

Thunderbird not able to read (decrypt) [e-mail] email

Expected results:

Thunderbird should able to read (decrypt) [e-mail] email

Comment 1

[robbinespu]

using Thunderbird 78.4.0 (64-bit)

Comment 2

[Magnus Melin [:mkmelin] (away, back June 30)]

Is this the 3pane window? There is no OpenPGP button there?

Comment 3

[robbinespu]

(In reply to Magnus Melin [:mkmelin] from comment #2)

Is this the 3pane window? There is no OpenPGP button there?

Not sure how to define 3pane but yes the pgp button doesn't appear

Comment 4

[Magnus Melin [:mkmelin] (away, back June 30)]

3pane = The normal thunderbird window with folder pane, thread pane, and message pane. The main window, in it's usual configuration. As opposed to opening the message in it's own window.

Comment 5

[u617804]

I can reproduce with TB 78.4.0

Generally, nice idea, this Adele bot. Unfortunateley, this is crappy old stuff sponsored by German government from year 2003.
(see website http://www.gnupp.de/start.html)

Adeles public key is 1024 bit Elgamal from year 2002, which is consequent.

Finally, I figured out from the manual the crappy way how only to give Adele your public key:

You need to paste your pgp public key ascii-armored:

-----BEGIN PGP PUBLIC KEY BLOCK-----
......
-----END PGP PUBLIC KEY BLOCK-----

in an otherwise completely empty mail No other text nor attachment, nor signature and the like.

Then You get an encrypted answer, which TB does not decrypt, like in Robins screenshot.

The header is:

MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=us-ascii

So, with my limited understanding, the
-----BEGIN PGP MESSAGE-----
block is just plain text, no PGP inline MIME header or something.

Is this expected to be handled as encrypted mail text?
If yes, I would suggest to also give the opportunity to recognize Adeles public key (which she provides the same way) and offer to import it in TB. Currently, I did like written in the manual, copied the public key block from the mail body to the clipboard, saved the clipboard in a file and imported the file in TB.

Comment 6

[u617804]

After copying the received encrypted pgp message block from mail to clipboard to file, the file can be succesfully decrypted with "gpg --decrypt".

Comment 7

[u617804]

Looking at the mail format stated in bug 1651896#c0 I guess Adeles message format should be ok, too, and should be decrypted?

The error console stays empty when clicking on Adeles received encrypted mail.

Comment 8

[u617804]

Found the problem. The problem is the clear text after the
-----END PGP MESSAGE-----
line:

.......
-----END PGP MESSAGE-----

----------------------------------------------------------------------
NOTE: This email is sent automatically by Adele, the friendly OpenPGP
email robot, in reply to a received email. If you did not write to
<[e-mail]>, then someone might have abused your address.
If you feel annoyed by this email, and in other cases of data
abuse, please write to <[e-mail]>.
Adele is a service of G-N-U GmbH <http://www.g-n-u.de>.
----------------------------------------------------------------------

When saving the mail to file, edit the file by removing the text after the "end pgp message" line, and opening that modified file in TB, the message is shown properly decrypted.

Maybe there should be a warning to the user, saying e.g. "There is a pgp block in the mail, but there is plain text too, this is invalid and pgp block is not decrypted" ?

Comment 9

[u617804]

Reading the newcomer guide (German language) http://www.gnupp.de/pdf/einsteiger.pdf again, it is not expected by the service provider that Adeles mails are decrypted directly by mail programs, but the PGP key block shall be copied by the user manually to the clipboard and then being decrypted with the program WinPT (Windows Privacy Tray). So, one could say, Adele works as expected, and this bug is invalid.

But maybe this bug could be changed to feature request to enhance usability by giving a hint to the user that the mail format is invalid, see my suggestion im #comment8

Comment 10

[robbinespu]

hi bugzilla0248, nice finding on #c8

Comment 11

[Kai Engert [:KaiE:]]

(In reply to bugzilla0248 from comment #8)

Maybe there should be a warning to the user, saying e.g. "There is a pgp block in the mail, but there is plain text too, this is invalid and pgp block is not decrypted" ?

Exactly this should already happen - there should be a notice and a button. We need to investigate why this isn't happening. It would help to have a full copy of the message. (Use file save as, zip it, and send it to me by email. I don't need to be able to decrypt the message.)

Comment 12

[u617804]

(In reply to Kai Engert (:KaiE:) from comment #11)
It would help to have a full copy of the message. (Use file save as, zip it, and send it to me by email.

Bug should be easy reproducable for everyone by sending an email that has nothing but the senders public pgp key ascii armored in the body to [e-mail] .

I just sent you Adeles encrypted response to my mail to her.

Comment 13

[Kai Engert [:KaiE:]]

Thank you for sending me the example message.

I can reproduce using 78.x.
This looks like a regression caused by bug 1647039.

There's work going on in bug 1672851 to undo some of those changes.
Using the patch from bug 1672851, I can no longer reproduce this bug.

Comment 15

[Kai Engert [:KaiE:]]

I confirmed that it worked correctly in 78.3.3 and doesn't work with 78.4.0

Comment 16

[u617804]

I can confirm that bug is solved in TB 78.5.0.