Open Bug 288700 Opened 20 years ago Updated 17 days ago

Handle delete/detach attachment feature with crypto-signed mails

Categories

(MailNews Core :: Attachments, defect)

Product:
MailNews Core
Component:
Attachments
Type:
defect

Tracking

(Not tracked)

People

(Reporter: BenB, Unassigned)

References

Details

Attachments

(1 file)

UI: delete/detach for attachment of signed message not available
86.47 KB, image/png
Details
Split-off from bug 2920 comment 419 and bug 2920 comment 60: If the mail client deletes attachments of a mail that happened to be cryptographically signed by the sender, the signature gets invalid. That's as designed, because the sig proves that the msg is not tampered with, in the state that the sender sent it, and that intentionally includes attachments, otherwise they wouldn't be included in the sig wrapper. The problem here is that our mail client shows a "broken" signature, which may be confusing to users. Question is what to do. - Comment 60 suggested as one solution to disable the "delete attachment" feature completely for mails that are signed. - Another solution would be to allow deletion of attachments, and then treat the msg as if it never had a signature. - Another suggestion (of mine) would be to show a special msg telling the user that the msg used to be signed by foo, but no longer is, because the attachments have been stripped. That poses the risk that users then treat the msg as if the signature was still valid, which would open (social) attacks where the attacker forges msgs which *pose* as exactly that.
Summary: Handle delete attachment feature with crypto-signed mails → Handle delete/detach attachment feature with crypto-signed mails
Why is the product (the discontinued) "Moz App Suite"? Shouldn't this be "Core" or "Thunderbird"? If not, should i file a new bug on "Core" or "Thunderbird"? (In reply to comment #0) > If the mail client deletes attachments of a mail that happened to be > cryptographically signed by the sender, the signature gets invalid. Not only "invalid" but completely *blank*. NOTE: This also happens with signed + *encrypted* messages (reword summary?). > - Comment 60 suggested as one solution to disable the "delete attachment" > feature completely for mails that are signed. That is a problem for users who sign *all* their e-mails; and for the futurewhen hopefully more users will be using digital signatures. > - Another solution would be to allow deletion of attachments, and then treat the > msg as if it never had a signature. That would be unfortunate. Perhaps add some text to the bottom of the message (below the attachment-removal note?): "The digital signature has been removed from this message because the attachment was removed, thus altering the e-mail." > - Another suggestion (of mine) would be to show a special msg telling the user > that the msg used to be signed by foo, but no longer is, because the attachments > have been stripped. That poses the risk that users then treat the msg as if the > signature was still valid, which would open (social) attacks where the attacker > forges msgs which *pose* as exactly that. This _may_ not be a big problem because messages with detached/deleted attachments will likely only reside on the detacher's/deleter's local machine, not the inbox (as unread), and not sent to someone (this would be a "reply/forward", which would strip the original sig anyhow - and validly replace it with the new sender's sig).
> Why is the product (the discontinued) "Moz App Suite"? Because bug 2920 is there. > not the inbox (as unread) Sigs are also important later on to prove (e.g. in court) that the msg was unaltered. > "reply/forward", which would strip the original sig anyhow Sure? I thought fwd as attachments retains the msg as-is (incl sigs).
(In reply to comment #1) > Why is the product (the discontinued) "Moz App Suite"? Shouldn't this be "Core" > or "Thunderbird"? If not, should i file a new bug on "Core" or "Thunderbird"? just filed bug 288981 for tbird.
*** Bug 288981 has been marked as a duplicate of this bug. ***
I'm moving this over to Core: MN attachments so that it can be nominated for aviary1.1 (which will also help me better with my queries).
Component: Security → MailNews: Attachments
Product: Mozilla Application Suite → Core
Version: unspecified → Trunk
nominating for tbird 1.1 (if there are cycles available!).
Flags: blocking-aviary1.1?
(In reply to comment #1) > > - Comment 60 suggested as one solution to disable the "delete attachment" > > feature completely for mails that are signed. The intention was to get rid of those huge Megabytes of attachments. It does not help if there are types left that can't be reduced. > That is a problem for users who sign *all* their e-mails; and for the futurewhen > hopefully more users will be using digital signatures. Ok, then it's important to have this feature for signed msg. too. Btw, in my opinion encryption is more important than signing. For real contracts I would prefer paper and ink. > That would be unfortunate. Perhaps add some text to the bottom of the message > (below the attachment-removal note?): Yes, this would also be my favourite. > > have been stripped. That poses the risk that users then treat the msg as if the > > signature was still valid, which would open (social) attacks where the > This _may_ not be a big problem because messages with detached/deleted > attachments will likely only reside on the detacher's/deleter's local machine, If it's an explicit wish of the user to alter the message, he should know what he is doing. The replacement message even proves that the signature was valid before. Of course somebody could break into the user's machine. But then also digital certificates could be altered. I don't see the problem. The message would not have a good reputation in court trials any more, but that's up to the user to throw away signatures or not. In a private environment I don't care much about signatures. Even for the usual business messages sigatures are irrelevant. You should let the user decide to employ them and how to handle them.
> Btw, in my opinion encryption is more important than signing. It's not, but irrelevant discussion here. > The replacement message even proves that the signature was valid before. No, it does *not*. That's what I said in my initial description. Any implementation would have to ensure that the msg can only be added by the local application. That means: Not in body or even headers, but stored in internal meta-data, in ways that provably cannot be seeded by incoming, fwrd etc. msgs, and displayed in the header pane. Note that this msg would be lost when looked at on IMAP on a different machine, after a copy to another machine etc., and definitely when forwarded (see above). THe msg would then appear completely unsigned (which it is). > Of course somebody could break into the user's machine. But then > also digital certificates could be altered. No, they could not. The display could, yes. But a break-in is not my main concern.
> this msg would be lost when looked at on IMAP on a different machine, > after a copy to another machine etc. unless there's a way to store that on the IMAP server. A manual copy or backup would have to include the meta-data. But that must not work with forwards and other transfers to third parties.
(In reply to comment #8) > > The replacement message even proves that the signature was valid before. > No, it does *not*. That's what I said in my initial description. Depends on your assumtions. Of course not for a court trial any more. You can't avoid that loss when removing the attachment. But the message is a marker for the mailbox owner that the signature was valid in the moment when he stripped the attachment. Of course with the assumtion that nobody broke into the mailbox and that the incoming mail did not already contain that message. But that's up to the recepient, quite obvious. More is not possible when the message was altered. The modification could be signed by the recepient, but that does not help him very much. With forwared messages the forwarder can sign again, that's already implemented. > Any implementation would have to ensure that the msg can only be added by the > local application. That means: Not in body or even headers, but stored in > internal meta-data, in ways that provably cannot be seeded by incoming, fwrd > etc. msgs, and displayed in the header pane. But that would mean new data structures and complexity for the implementation. The security gain is not very big. The case when the incoming new mail already contained that removal message is quite ovious for the recepient. He could simply delete that unauthorized mail. Or Mozilla would additionally add a comment like "warning: removal message forged" ... > Note that this msg would be lost when looked at on IMAP on a different machine, > after a copy to another machine etc., and definitely when forwarded (see above). > THe msg would then appear completely unsigned (which it is). Yes, but it would be impossible to secure such a long trust chain. We should stay with the simple "signature removed" marker. Everything else would be very difficult and could not improve security very much. > > Of course somebody could break into the user's machine. But then > > also digital certificates could be altered. > No, they could not. The display could, yes. But a break-in is not my main concern. I would agree that we assume trust for the own machine and mailbox. That is not sufficient for court trials, but if you want that we could not implement the removal feature at all. Securing the removal message would mean kind of local signing with local certificates. These could be altered by somebody with access to this machine. It would help when the messages are stored in an untrusted IMAP folder. You will run into really complex security issues. So, just keep it simple. Just strip off the signature and insert the removal message.
A dialog when stripping an attachment from a signed/encrypted message would be needed to warn the user of hidden consequences (loss of sig/encrypto). Since the dialog could get annoying, and especially since having locally stored message that are signed/encrypted is less important, one of those nifty "annoy me again?" checkboxes would be needed (UNchecked by default). +===========================================================+ | | | / \ Removing the attachment(s) will also remove the | | / | \ signature/encryption from this message. | | ----- | | Do you still want to remove the attachment(s)? | | | | [ ] Show this alert the next time I remove an attachment | | from a signed/encrypted message. | | | | [[ Yes ]] [ No ] [ Help... ] | +-----------------------------------------------------------+ Of course, the dialog would only appear when removing attachments from signed and/or encrypted messages. PS. Should bug 288273 and this bug (was Suite, now Core) be dupes?
Flags: blocking-aviary1.1? → blocking-aviary1.1-
(In reply to comment #11) Summary of this Comment: The key long-term consideration in altering any message is maintaining the chain of responsibility for the message's content. Users should understand that there are consequences in altering a message. Peter's suggested warning dialog box would work for me if it contained the option for users who remove attachments to "sign" that action with their own digital signatures, thereby establishing responsibility for the act of altering the message. Detailed Comment: I won't argue the case for the original bug (2920) here. I assume that all are in agreement that the fix is valuable. For me, this bug (288700) has been part of bug 2920 from the very start, because the vast majority of the messages I receive are signed -- well, at least the ones that I need to archive without attachments. Preserving the original signature is not necessary as long as the person who removes the original signature takes responsibility for having done so. The key issue is whether there is someone who takes RESPONSIBILITY for any changes to the original message, not whether there are any changes at all. At least, that's the long-term consideration for my purposes. Here's the criterion: My mail archives must constitute an accurate record of what happened -- a record of who did what, and when they did it -- that a historian can use 200 years from now to accurately reconstruct the progression of today's events. The burden of proof as to authenticity is mine. Yes...I understand all the arguments asserting that someone might break into my machine and somehow falsify the record, but let's assume for the moment that I've taken measures to make that virtually impossible. Let's assume that there's no (known) way for anyone (including me) to falsify the record without being detected (true). Let's assume that the situation is no more complicated than this: • I want to remove attachments (which entails also removing the original sender's signature) • I want to certify that I have done so by signing that action with my own identity-trusted signature • My digital signature on that action is good enough to establish the chain of responsibility for the message for archival purposes. Clearly, the responsibility for altering the original message in any way must be on the person who makes such alterations. If I absolutely need to have the original message intact (say, for use in a legal case) I will simply leave it intact -- end of story. But for any other purpose that I can imagine, it's perfectly acceptable to alter the message as long as that action is...er, "certified" by my digital signature. That puts me on the hook for having made the alteration, and also for ensuring that the entire process is secure -- by which I mean that I'm on the hook for proving that nobody else tampered with it. I wouldn't have altered the message if I weren't prepared to accept responsibility for it, but that's not relevant here. Here's the relevant question: Have we designed the application in a way that enables users to accept responsibility for their actions, and informs them that they need to make that decision? I believe that everyone has put enough thought into this bug to have addressed all the issues that we can reasonably be expected to have addressed. From an application design standpoint, our responsibility to do social engineering is minimal. The best we can do is enable users to take responsibility for their actions. Whether they choose to do so is up to them. That's why the warning dialog is such a good idea. The user should understand that there are consequences in altering the message. Peter's suggested warning dialog box addresses most of the requirements that the mail application should cover, except for "signing" the action as I've described above. In other words, Peter's dialog would work for me if it contained the option for users who remove the attachments to "sign" that action with their own digital signatures.
There seemed some great discussion on this 12 months ago, but nothing of late. Is anything being considered on this bug? It's infuriating when I digitally sign all my outgoing e-mails, but generally don't want to store them with attachments in my sent mail folder (where in fact it matters not in the slightest to me whether there is a valid digital signature or not). My sent mail folder has become unnecessarily huge.
(In reply to comment #13) The "Detach..." and "Delete" features exist in SeaMonkey, but as of version 1.0.2 they are useless for messages that are signed or encrypted (or both). Detaching (which allows saving the attachment) or deleting the attachment altogether breaks the signature and removes the entire content of the message body. The original idea behind the bug—which is to preserve the content of the message while deleting the bulky, unnecessary attachments—is completely ignored by the current implementation. You can either save the whole signed and/or encrypted message with the attachment, or you can "detach" everything from the message (but "detach" really means delete everything from the message...signature, attachment, and message body content -- everything is lost) except the header. Hence, for signed and/or encrypted messages the feature is utterly useless as a means of saving the message but deleting only the bulky attachment. BTW, I notice that there are still only two votes for this bug -- yours and mine. (sigh)
I ran into this bug today. Can an agreement on the fix be reached? I wouldn't mind creating a patch for this if it isn't too hard (I'm a beginning developer).
Removing the signature on removal of attachment seems good to me. But, one nit-pick. I think it should be "Don't ask me again" instead of "Ask me next time". It's consistent with the rest of the interface, and with this the user has to agree to not show it again, which seems to make more sense.
QA Contact: seamonkey → attachments
You can't detach/delete attachments from smime mails, at least on trunk it's disabled.
Product: Core → MailNews Core
(In reply to comment #18) > You can't detach/delete attachments from smime mails, at least on trunk it's > disabled. When did that change go into effect? That was NOT the case when this bug was submitted. Was there a bug number associated with that change? If so, what bug number?
That would be bug 288273, landed 2005-06-10.
So, to resolve bug 288273, someone decided to disable the feature rather than fix it. :(
(In reply to comment #19) > (In reply to comment #18) > > You can't detach/delete attachments from smime mails, at least on trunk it's > > disabled. > > When did that change go into effect? > That was NOT the case when this bug was submitted. > > Was there a bug number associated with that change? If so, what bug number? (In reply to comment #20) > That would be bug 288273, landed 2005-06-10. Does this makes this bug INVALID ?
No. The "fix" for bug 288273 was considered by its authors to be an interim measure. They designed a longer term fix that would allow attachments to be detached again (see bug 288273 comment 6) but did not implement it. Bug 288273 comment 9 says an RFE will be fixed to request that that feature be implemented. This "bug" is that RFE.
Flags: blocking-aviary1.5-
Just stumbled over this bug while searching the internet for a solution to remove attachments from signed mails. I'm aware of the implication that the signature would no longer be valid. Since I'm also signing all of my outgoing mails and my account is constantly growing I'd love to see a solution for this problem. Has this bug never been addressed since its submission over 7 years ago? Or is there already another solution I didn't find?
Assignee: mozilla → nobody
I've created a new report for an issue which is related but apparently distinct: Bug 838674 deals with removing signed attachments from *unsigned* e-mails. (The fix suggested in Bug 288273 Comment 6 isn't applicable, since there's no question of any signature being lost.) If I'm wrong please feel free to mark it as a duplicate of this one.
TB 31.7 still does not allow to delete attachments from signed messages. Attached is a screenshot that shows the delete/detach functions "greyed out" (disabled).
Totally agree with comment 25: I often send signed mails with big attachments, and I need to keep trace of the mails sent, the attachments attached, and the text of the mails, but I do NOT need the attachments themselves. While deleting/detaching attachments is impossible since 10 years, marking the attachment and hitting the delete button still works and leaves an empty message. The proposed resolution is clear since 10 years: remove the signature/encryption when deleting an attachment, and warn the user about it, preferably with option not to warn again. David Bienvenu, who proposed this RFE 2005, retired from this bug after 7 years without any proposed patch. Anybody there who is willing to implement this rather basic fix?
Unfortunately, it's _not_ a "rather basic fix," because the MIME handling code in Thunderbird is a mess which makes even seemingly small changes difficult. I believe someone is in the process of rewriting all the MIME handling stuff in JavaScript which will eventually replace the old, messy, C++ MIME code. Once that happens this fix will probably be easier to implement. _Probably_.
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Given the increasing number of security issues and fraud with emails, it becomes very important to sign emails. My organisation recently moved to signed emails but we really need a feature to delete/detach attachments from emails. Is there a way to get this feature implemented soon? e.g. as an add-on? I'm happy to test that and give feedback. Apparently, several people in the community would love to have this feature. See also: https://support.mozilla.org/en-US/questions/1128673 Thank you in advance for your help.
It cannot be that difficult to finally solve this problem. What I've been doing as a workaround for years is the following: * use any tool/editor capable of manipulating the email (header), e.g., the HeaderToolsLite extension. * Change in the "Content-Type" entry the "multipart/signed" to "multipart/mixed" and remove (or even better, rename) the "protocol" parameter, e.g.: replace Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01D1D126.351C61F0" by Content-Type: multipart/mixed; protocol="application/x-pkcs7-disabled-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01D1D126.351C61F0" * As a result, the email is not considered signed anymore, while the signature is now treated as a regular attachment. * Detach/detect any attachments as you want. Note that this way there is still an indication that the email was signed originally, yet without a disturbing "broken signature" symbol being shown. In case you later restore the signature MIME header after manipulating the attachments (or the remaining body), the signature will of course show broken. If you did not change anything in the body including the attachments (or restore it), you can easily restore the valid signature by reverting the small header changes mentioned above. BTW, TB apparently blocks deleting/detaching attachments as long as it finds "application/x-pkcs7-signature" as a substring(!) of the Content-Type entry, which is bad hack. It should rather check that there is a parameter with (full) name "protocol" and (full) value "application/x-pkcs7-disabled-signature" Hope this helps as a hint how to design and implement a solution smoothly.
Oops, correcting a copy&paste error in my but-last paragraph above: BTW, TB apparently blocks deleting/detaching attachments as long as it finds "application/x-pkcs7-signature" as a substring(!) of the Content-Type entry, which is bad hack. It should rather check that there is a parameter with (full) name "protocol" and (full) value "application/x-pkcs7-signature"
David, thanks for the workaround. It seems that this and other tickets a more about dealing with errors about broken signature and not about the thing that a user should be able to deal with attachments no matter if it will show an error or not. +1 annoyed Thunderbird user
@wroot, if you more carefully read my post of 2016-06-28 01:49:32 PDT you will see that my workaround does not only prevent an error message, but also does enable removing attachments. I also indicated a sloppiness in TB's way of detecting that a message is signed (when determining whether it allows to remove attachments). The whole issue could have been solved pretty easily already some ten years ago, but like with most other reported bugs/problems, nobody actually takes it up.
David, yes i understood that correctly and was able to remove attachments;) My second statement wasn't directed at you, but at the situation in general.

Hi everybody,
more or less daily I send out emails with attachments, and I like the idea of having my emails signed. But the attachments are blowing up my email folder size on hard disk, so I have to stop signing them. And I want to read them in 25 years still without any special tools installed.
Please make it possible to remove attachments from sent and signed emails. All I need is, that the recipient receives my emails signed - I don't need them signed on my own system (a flag showing "Sent signed" would be sufficient). The same applies to encryption.
I'm using Seamonkey myself, but hope to get this fix one day from Thunderbird into Seamonkey (or I will switch to Thunderbird for the case there will not come any update to Seamonkey anymore).
Friendly greetings,
Torsten

I don't think bug 1282701 is a duplicate of this. Original post talks about sign icon being broken after an attachment is deleted. Referenced bug talks about inability to easily remove attachments in signed emails.

See Also: → 838674

I tried to "clean" some (actually many) of my e-mails (I wanted to keep the text while reducing the file size by deleting the attachments) and this still seems to be a big problem after 16 years (!)... as I use TB in a corporate environment, many of the e-mails are signed and thus they become blank when deleting the attachment (the text ist still there when exporting to .eml and using some text editor to read them, but alas, that's not the way to read an archived email :)...

Is there a possibility that somebody fixes this and somehow makes it possible that the text is still readable and - as suggested before - a message appears with something like "The digital signature has been removed from this message because the attachment
was removed, thus altering the e-mail."?

Dear all,
The impossibility to remove attachments of signed emails is actually very annoying. The size of my mail box is limited and I need to delete some attachments, which I cannot currently. This problem seems to be already 16 years (!) old. Is there anyway to make this topic visible again for the developers?

Thanks in advance for this and btw. thank you very much for providing us with Thunderbird. I'm using it for years now and expect this issue, I have always been very satisfied with it.

(In reply to Jean from comment #41)

The size of my mail box is limited and I need to delete some attachments, which I cannot currently.

If doing some one-off housekeeping is urgent for you, a fairly simple workaround would be to use a different e-mail client to delete the offending attachments. You can install it just for this purpose and then uninstall it once you're done. IIRC KMail is able to delete attachments from signed e-mails; probably there are other clients which also have this functionality.

(In reply to Tristan Miller from comment #42)

If doing some one-off housekeeping is urgent for you, a fairly simple workaround would be to use a different e-mail client to delete the offending attachments. You can install it just for this purpose and then uninstall it once you're done. IIRC KMail is able to delete attachments from signed e-mails; probably there are other clients which also have this functionality.

Thanks for the tip! When having a lot of folders, however, it takes quite a bit of time to go through them all. Deleting the attachments as they come would be for sure a more practical solution for the future.

I am another annoyed TB user, which need to ged rid of big attachment of signed e-mails. And as many others I do not mind that after removing attachment the mail is not correctly signed anymore - I do not need emails in my mailbox to be signed. I just need to be able read old emails without dealing with giant mailbox because of attachment I know I do not need to keep.

And it is bad that I have to use a hack like changing the email source to be able to remove an attachment. That is not user friendly approach at all. And (as by many other softwares) we all can see what is the result: user friendly advice "use another software". It is a good way how to slowly loose users. Which is sad, while I like Thunderbird and wish him long life with happy users...

Severity: normal → S3

And still we cannot get rid of attachment when someone is signing its emails, even with non valid signatures. Because all our messages will likely be under some Court investigation, and we should not decide on our own what to keep and what to delete (but we can delete the whole message, so...)

Anyway, who would have thought ~20 years ago that this plain-and-simple BUG would have survived so long! Super.

First: Thanks for all the work!

I would like to add my plea for implementing one of the two solutions that allow deleting attachments: My Thunderbird folder already exceeds 6 GB even without attachments and deleting my client's e-mails just because they happened to both sign them and attach a few megabytes of only temporary use is not really an option, is it?

One of our suppliers started signing all his e-mails (with an invalid signature anyway!), and I cannot delete the attachments anymore. This is still really annoying after 20 years!

Somebody mentioned above that KMail should be able to delete attachments from signed e-mails. Installing KMail would however pull loads of KDE dependencies which I don't really want, so I just Evolution 3.44.4-0ubuntu2, which comes with Ubuntu MATE 22.04.

If you delete an attached text file, Evolution replaces its contents with this text line:
File "filename.txt" has been removed.
That is, it does not really completely remove the attachment like Thunderbird does, but it should reduce its size drastically.

However, I couldn't remove an attached PDF from a signed e-mail with Evolution. There was no error message, but the removal just didn't work.

That is similar to the behaviour of Thunderbird's add-on "Attachment Extractor": it does not remove the attachments of signed e-mails, but it does not complain either. It just fails silently. I am guessing that this add-on is just a convenience wrapper to apply Thunderbird's attachment removal logic to many e-mails at once.

I would be grateful if anybody else could mention some other e-mail client, add-on or command-line tool which could delete attached files from signed e-mails.

I had a brief look.

Our existing code doesn't work for signed messages.

When allowing to execute our code on a signed message, we create a corrupted message structure, where the plain/html message part is appended at the end of the message structure - after the trailing MIME layer boundary. As a result, those text is no longer shown.

This was with the simple signature structure that uses MIME layering.

Someone would have to write new code for rewriting such messages.
And that code would have to handle both the simple MIME layering (where the original MIME text is directly visible inside the message, and an additional signature part is present ) and also the opaque signing transport mechanism (where a single MIME part contains the transported data inside a binary encoding).

This isn't deliberately preventing anyone from using the feature, it's because nobody has written the code that would be required to implement deatching/deleting for signed messages.

(In reply to R. Diez from comment #48)

I would be grateful if anybody else could mention some other e-mail client, add-on or command-line tool which could delete attached files from signed e-mails.

I'd suggest FairEmail to delete attachments in signed emails. It works flawlessly and it is open source.

(In reply to Bob G from comment #50)

(In reply to R. Diez from comment #48)

I would be grateful if anybody else could mention some other e-mail client, add-on or command-line tool which could delete attached files from signed e-mails.

I'd suggest FairEmail to delete attachments in signed emails. It works flawlessly and it is open source.

Nice - as long as one has access to an Android phone and FairEmail can get hold of the email,
which is not the case for non-standard (M$ Exchange) accounts.

As I wrote here 8 years back: https://bugzilla.mozilla.org/show_bug.cgi?id=288700#c32
here is a basic workaround I came up with many years before - shame this issue is way too old!

Use any tool or editor capable of manipulating the email (header), e.g., the "Header Tools Improved" add-on

  • Change in the "Content-Type" header entry the "multipart/signed" to "multipart/mixed" and rename the "protocol" parameter, e.g.:
    replace
    Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
    by
    Content-Type: multipart/mixed; protocol="application/x-pkcs7-disabled-signature";

Then the email will no more be considered signed and the signature will show up as an additional attachment that can be ignored.
Now the email attachments can deleted/detached as usual.

(In reply to Kai Engert (:KaiE:) from comment #49)

Someone would have to write new code for rewriting such messages.
And that code would have to handle both the simple MIME layering (where the original MIME text is directly visible inside the message, and an additional signature part is present ) and also the opaque signing transport mechanism (where a single MIME part contains the transported data inside a binary encoding).

As I wrote 8 years back, the simple workaround I just shared again indicates that it cannot be that hard to implement a fix within TB.

(In reply to Kai Engert (:KaiE:) from comment #49)

I had a brief look.
[...]

Thanks for looking.

An alternative could be to provide a way to remove the digital signature from an e-mail as a first step. Afterwards, the normal logic to delete attachments should work.

There is a Thunderbird add-on called "Disable Signature" for that purpose, but it is not compatible with modern Thunderbird versions. I am guessing that its source code could also be used as inspiration.

Some people are using invalid signatures, or one which requires manually installing some certificate which you may not want to actually install and trust. Therefore, an option to only remove the digital signature may be useful in other scenarios too.

(In reply to David von Oheimb from comment #51)

As I wrote here 8 years back

Thanks for the reminder. I decided to test your method, and this is what I found:

  1. Searching for add-on "Header Tools Improved" within Thunderbird provided no hits.

I am using Thunderbird version 115, which comes with Ubuntu MATE 22.04. Thunderbird version 115 is not actually very old: it was released on September 5 2024 (about 18 days ago), and there is only a newer version, namely Thunderbird128.

However, searching for add-on "Header Tools Improved" on the Internet did show version 4.7, which should be compatible with my Thunderbird (compatible with versions 115.0 - 125.*).

I manually installed that version, and the add-on seemed to work fine.

On addons.thunderbird.net, I clicked on other versions, and I then saw a new one labelled "version 4.8", compatible with "Thunderbird 126.0 - 132.*". That is probably the reason why Thunderbird was not showing the add-on at all. This is all very confusing.

  1. Menu item "Header Tools Improved" only shows up in the context-menu, and only in the message pane. If you open the e-mail in a separate window, like I tend to do, then there is no way to access the add-on. The shortcoming with the pop-up menu is actually documented: "Due to changes in Thunderbird this add-on now only works with messages opened in the Message Pane. The Message and Message list context menus only appear when a message is visible in the Message Pane. The Message menu submenu had to be removed."

  2. Option "Change header details" is not enough, you have to use "Edit full source".

There is no find function in the text editor, so you have to visually scan for the "application/pkcs7-signature" you mention. In the particular e-mail I tried this with, there were quite a few headers to go through.

  1. The e-mail had been sent from some Apple Mail software. Instead of "application/x-pkcs7-signature", the Content Type was "application/pkcs7-signature" (without the "x").

This procedure is definitely not for the average Thunderbird user.

Other than that, your procedure did work. After making the change to the content type line, an additional attachment called "smime.p7s" appeared. I was then able to delete both the original attachment and smime.p7s too.

deleted

I deleted comment 55 because it was an incorrect statement.

I confirm the strategy described in comment 53 works.
(edit message, replace content-type, then delete attachment works, message text still readable.)

Magnus, besides the delete attachment / detach attachment functionality, are you aware of any simpler code that we have, which modifies a message and replaces its storage (either local or on the server)?

That code is rather complicated. I wonder if we have any simpler implementation (e.g. that doesn't need to go through C++).

We could potentially use the the following implementation:

When building the list of right-click-menu actions, we currently check for the signature content type. If we find it, we disable the delete/detach attachment actions.

A suggested enhanced implementation, with a minimal UI change, could do the following:

When we detect the signature content-type, we change the wording of the menu command to
"remove message signature and delete/detach".

When the user selects that, the simplest implementation could do a two-phase action.
In a first step, we transform the message content-type. I'd suggest to go through all of the message, and replace all content-types that start with multipart/signed with multipart/mixed (reusing the suggested stragegy from the earlier comments).

I think it would be sufficient to simply leave the additional attributes in place.

So the first step loads the message, changes the content-type everywhere in the message, the replaces the message in storage.
Then, as a second step, we call the existing code to delete/detatch the attachment.

If we can find a simple way to do step 1, this might be rather straightforward to implement.

Just a note to myself:
The action happens in AttachmentDeleter::InternalStartProcessing
which uses the URL parameters &del= and &detachTo= to signal which part is treated,
and the constructed streamconverter will run through mimemult.cpp, MimeMultipart_parse_line.
The code for case MimeMultipartHeaders writes a text/x-moz-deleted header.
See also obj->options->state->strippingPart

If we don't find an easy way to rewrite the existing message with different content types,
implementing this feature would require similar code that executes a similar sequence of steps,
but instead of stripping, just replacing content-type headers.

(In reply to Kai Engert (:KaiE:) from comment #57)

Magnus, besides the delete attachment / detach attachment functionality, are you aware of any simpler code that we have, which modifies a message and replaces its storage (either local or on the server)?

Not that I can think of.
However, we currently disable the menu, but is it actually not working? I thought we disabled it since it would invalidate the signature.

I wouldn't change the wording, but instead have a don't-remind-me-again warning dialog explain that this will turn this signature invalid.

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

[...]
However, we currently disable the menu, but is it actually not working? I thought we disabled it since it would invalidate the signature.

By the way, did you just disable the menu?

If I open the signed message in a separate tab, I can open the menu "Message", "Attachments", and options "Detach..." and "Delete" are disabled for each attachment.

But options "Detach all..." and "Delete all..." are still available. However, when you try to use them, they do nothing, and there is no error message.

That is yet another small bug, but this behaviour also suggests that something in the code is disabled, and not just the menu items.

Whenever modifying a signed message (to remove an attachment or for other reason) by whatever means,
I propose keeping the signature blob in the form of an attachment as a reminder of the message originally having been signed.
Then the user has the choice to remove the signature in case (s)he is not interested in keeping it.

This is automatically fulfilled when using the mentioned simple strategy (adapting the message content type).

Duplicate of this bug: 1944813

The current situation of not being able to delete the attachment of signed messages is problematic for the case where the attachment contains data that must be deleted, e.g. for legal reasons. Right now I am forced to delete the entire email. I'd much rather accept a "broken signature" warning (with an indication like "you removed the attachment, hence the signature can no longer be verified") or so, that would still be better than having to delete the entire email.

(Sorry for the 2nd message, I forgot to add this in my first post.)

The other issue that that currently, the UI gives no feedback as to why the items are disabled, which is quite frustrating -- the user will likely wonder whether they are doing something wrong.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: