2015226 - The “Reply with Template” filter sends the body encrypted with the sender's PGP key if encryption is enabled.

Status: RESOLVED DUPLICATE of bug 1937660

(MailNews Core :: Security: OpenPGP, defect)

Description

[uxfail]

Attachment: thunderbird template bug.png

Steps to reproduce:

1. ensure that you have a working PGP encryption configuration for your main e-mail account
2. create and save a new template for your main e-mail account. note that by default the "encrypt" button will be selected. Leave this button selected, do not unselect it. Choose a meaningful subject (i.e. "test template"), and enter some meaningful text in the body. save the new template, making sure that from the File menu you elect to Save As... Template, because if you select "Save" instead of "Save As... Template" then your changes will not be saved...
3. create and save a new Message Filter Filter Rule for your main account that will match e-mails sent from a test e-mail address. The test address should not be configured with any PGP encryption, meaning there is no PGP key created for the test address. The Filter Rule should Perform the action of Reply with Template using the "test template" that you configured in step 2.
4. send a test e-mail from the test address to the main account. If it matters, I sent the e-mail from the test address using the main account, by editing the "from" field" of the test e-mail before I sent the test e-mail.

Actual results:

Whenever my PGP-configured main e-mail account receives an e-mail from the not-PGP-configured test e-mail address, my Message Filter sends a reply to the test e-mail address using my "test template", and this reply e-mail is PGP encrypted, which is pretty weird considering that the test e-mail address does not have and never has had a PGP key associated with it. This PGP encrypted auto-reply e-mail can not be decrypted, which is not surprising considering that it is not possible to encrypt an e-mail without a public key, and the address to which the e-mail was sent does not have any public key associated with it.

Expected results:

When the mail filter sends the auto-reply e-mail to the test e-mail address, considering that the test e-mail address does not have and never has had a PGP key associated with it, I would guess that maybe the sent auto-reply e-mail should not be encrypted. Please see attached screenshot of the encrypted e-mail.

Comment 1

[uxfail]

Please note that in step 2 above, if you de-select the "encrypt" button so that you save the template without the "encrypt" button selected, the bug still happens.

Comment 2

[uxfail]

errata: I'm sorry, I must correct my original description here. It turns out that I was confused by Mozilla's somewhat poor user interface design which misled me into believing that opening the template would actually open the template. (I know, that's too much to expect.) Instead it turns out that opening the template actually opens a portal to some alternate dimension in which opening the template actually instantiates a new e-mail object from the template, this, without any warning or indication that this has happened.

It turns out that when I choose the menu option for "Edit Template" (which I had not originally thought to look for, because, I just expected double clicking to like, open the thing, the way double clicking works everywhere else in the universe) I then discover that the template has the "Encrypt" button selected, and the "Encrypt" button can not be deselected. Well, it can be deselected, but saving the template unfortunately does not save the deselected state of the "Encrypt" button. :-( So this would seem to be the problem here.

So this seems to be a pretty straightforward minor bug that can probably be fixed without too much difficulty. Sorry for the initial confusion caused by Mozilla's somewhat problematic UI design philosophy.

Comment 3

[uxfail]

after running more tests, I have determined that the fault is probably not with the Message Filter. Instead, the fault is that the Template itself is always saved with encryption, even when you deselect the "Encrypt" button.

Comment 4

[uxfail]

I found a workaround, as follows: Create and save your Template inside a mail account that does not use encryption, and then drag and drop your Template from the Templates folder of your mail account that does not use encryption into the Templates folder of your mail account that does use encryption. This will allow for the correct functioning of the "Reply with Template" function of the Message Filter Filter Rules, in other words, the "Reply with Template" function will send unencrypted reply messages to recipients who do not employ encryption. If at any point in time you need to edit your Template, you would need to first drag and drop the Template over to a mail account that does not use encryption, perform and save the edits, and then drag it back to the encryption-using mail account in which the Template is actually used.

Comment 5

[Alfred Peters [:infofrommozilla]]

I can confirm that the “Reply with Template” filter sends the unchanged body from the MBox file.

If the template was saved in encrypted form, TB sends it exactly as it is. Only the Content-Type header is overwritten. This renders the email unusable.
However, the recipient cannot decrypt the email anyway, as it was encrypted with the sender's PGP key.

Comment 6

[uxfail]

Thanks for looking at this Alfred. I should update with newly discovered information:

I believe that my above proposed workaround can be sabotaged by Bug 2015314 in which there are two different preference settings for encryption of new messages (global preferences, and account preferences) either of which can apparently force new messages to use encryption by default. So even if a template is not encrypted, any new message created from the template will apparently be created as an encrypted message if either the global preferences or the account preferences are set to create new messages with encryption.

I believe that my above proposed workaround can also be sabotaged by Bug 2015296 in which new messages are always saved as encrypted, even when you deselect the encryption option for that particular message. If this bug did not exist, then it would be possible to save a template without encryption.

Finally, as described in this present Bug 2015226, if a new e-mail created from a template does somehow end up created with encryption, the e-mail is sent without first checking if there is a key for the recipient.

Apparently when draft messages are encrypted, they are encrypted with the sender's key, and normally the draft message can not be sent until a valid recipient key is found so that the draft message can instead be encrypted with the recipient key before being sent.

Comment 7

[Magnus Melin [:mkmelin] (away until Aug 10)]

Right, the filter sends the message body as it was in the template. When the template is encrypted, what it sends is of course not useful.

Comment 8

[Magnus Melin [:mkmelin] (away until Aug 10)]

The setting (see bug 2015296) maybe shouldn't apply to Templates as well.