No more "Save all" / "detach all" / "delete all" for attachments

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).

nominating for tbird 1.1 (if there are cycles available!).

(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?

(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 ...

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.

*** Bug 300148 has been marked as a duplicate of this bug. ***

You can't detach/delete attachments from smime mails, at least on trunk it's disabled.

(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.

*** Bug 453490 has been marked as a duplicate of this bug. ***

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?

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.

Created attachment 8622054
UI: delete/detach for attachment of signed message not available

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

*** Bug 1282701 has been marked as a duplicate of this bug. ***

I don't think 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.

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...

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.