Open Bug 297314 Opened 20 years ago Updated 6 months ago

Allow detach/delete of attachments in signed/encrypted messages by unencrypting message

Categories

(MailNews Core :: Attachments, enhancement)

Product:
MailNews Core
Component:
Attachments
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: Bienvenu, Unassigned)

References

Details

spun off from bug 288273. We'll need to warn the user that the message will be unencrypted, and allow them to turn off that warning.
*** Bug 323760 has been marked as a duplicate of this bug. ***
Duplicate of bug 288700 ?
Assignee: bienvenu → nobody
OS: Windows XP → All
QA Contact: attachments
Hardware: PC → All
This bug overlaps bug 288700. That bug discusses detaching from messages that are signed, and explains that the signature must be removed. This bug discusses detaching from messages that are encrypted, or signed and encrypted, and suggests that the message must be stored unencrypted. (Actually, that's not exactly true. It is often possible to re-encrypt the edited result.) I would suggest that there is one common solution to both issues, one that removes both signatures and encryption from messages when detachment is done. There is a proposed UI dialog to handle both cases in bug 288273 comment 8 and in bug 288700 comment 11.
Product: Core → MailNews Core
All items extra to the message should be treated as attachments. This solution would give the control to the user, and avoid behaviour one does not expect. Those, who wish to remove also the certificate, should be able to do so. Those people, who wish to remove an attached picture, but retain the certificate, should be able to do so. If the certificate loses its integrity, it is a consequence they must put up with. The residual text of notice might contain an additional explanation, that the signature is no longer valid because this attachment is removed. One explanation per message. No duplicates please. I would also add an option to remove the residual text of notice after removal of attachments. But that can be achieved by simply copying or forwarding the text.
Andrew, i agree on all points, but i would give the priority to: allow to remove the attachments no matter the consequences.
Severity: normal → S3

I think the expected behavior especially in the context of something like Extract 'Em wouldn't be to just unencrypt the message, but to encrypt it again using the private key if available. I can't really think of a practical reason why users would want it left unencrypted on the server and prone to spying.

(Detaching not working on PGP mails also renders Extract 'Em's detach feature useless for anybody using auto-pgp-at-rest which many more privacy focused providers offer. So it can have a big impact.)

My original issue was that i was not able to detach delete attachments from emails that came encrypted. I already downloaded the attachment and i want to save space in my email storage and don't want huge files inflating my Inbox file, so i need to delete such attachments.

Same use case here. And unencrypting the message permanently on the server is in my opinion undesired for this use case.

People using POP may wish to unencrypt the message on detach/delete.

(In reply to Ellie from comment #8)

I can't really think of a practical reason why users would want it left unencrypted on the server and prone to spying.

That has been discussed multiple times.
People want keep their mail unencrypted for valid reasons.

In that case, please make it an option. And if a mail that is PGP encrypted is fetched via IMAP and the attachment is removed, it should probably be re-encrypted by default, or shouldn't it? Because it's easier to still unencrypt it, than to undo the damage of it having been revealed by a third party by accident.

(And my apologies for missing the obvious use cases. I didn't mean to take anybody's workflow away.)

See Also: → 1627962

Agreed it should then be re-encrypted.
An obvious issue is that signature is then broken, and broken signature is BAD.

There's many different needs and desires for data at rest. I think filters is the most obvious way to handle that - then to each their own...

For mails encrypted by yourself, which would always be the case for auto PGP at rest and your own PGP sent mails, the mail could just be automatically re-encrypted and re-signed when an attachment is removed. Doing this with filters is way beyond what the average user can figure out, especially when the detach is triggered by addon like Extract 'Em and not manually. I am quite technical and I don't dare touch that myself at the risk of messing it up.

Extract 'Em is basically doing a filter action though...

Sorry that I phrased my concern unclearly. What I mean is that the manual "detach" context menu should probably allow to re-encrypt and re-sign for user sent e-mails in an IMAP inbox, rather than hide that use case in the filter menu.

I don't understand the discussion, but dispite it I want to tell you my opinion.

My goal was and is that I can search in the text of my encrypted messages, what isn't possible. Therefore it would be helpful and the easiest way to have a filter that copies the encrypted message on an IMAP server to a decrypted message on a local folder. Also I have many old encrypted messages, encrypted on different implementations of Thunderbird PGP that I want also copy from local folders to local folders as decrypted messages, that I can search in them, what is not possible in encrypted messages. If this would be possible it would be excellent.
And I suggest to also encrypt the appendixes by this operation.
If someone then wants to delete all appendixes there should be in my opinion an extra filter, which removes all appendixes to make it not to complex.
See also:
https://www.thunderbird-mail.de/forum/thread/92249-filter-mit-entschl%C3%BCsselt-kopieren-funktion-aktion-wie-fr%C3%BCher/
https://bugzilla.mozilla.org/show_bug.cgi?id=1836268
https://bugzilla.mozilla.org/show_bug.cgi?id=1627962
https://www.thunderbird-mail.de/forum/thread/92249-filter-mit-entschl%C3%BCsselt-kopieren-funktion-aktion-wie-fr%C3%BCher/

See Also: → 288700
You need to log in before you can comment on or make changes to this bug.