User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20160210153822 Steps to reproduce: 1. Receive a mail on an IMAP account that is in HTML and contains embedded images (signatures, screenshots, etc.) 2. Make sure you are replying in HTML and from an account that has a certificate available and that the message is set to be digitally signed with it. The images should initially be visible in the email body. 3. Either wait a couple of minutes so that it saves to the Draft folder (also on IMAP) more than once (the more than once bit is important) or manually save the message at least twice (the first save seems to be fine, but subsequent ones break) 4. The images disappear and are replaced with a place holder and broken image icon. 5. Further attempts to either save to draft or send will result in the never-ending "Attaching..." message The embedded image should be one that is attached to the image and not one that is sourced from a remote server. Actual results: Images are not longer visible in the email body and additional attempts to save as draft or send mail results in endless "Attaching..." message Expected results: Images should be preserved and save and send should function, exactly as when sending an unsigned message.
This bug was created after a request on bug 532395, comment 185 to create a new issue specific to the problem when using a certificate to sign the email
I've started looking at bug 453196, so here some diagnosis for this bug here also. I'm replying to a message from my Inbox which has an embedded image. After hitting reply, the image is the reply is referenced from the Inbox like this: <img src="mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/jorgk.jorgk.com/Inbox?number=605&header=quotebody&part=1.2&filename=lijbmghmkilicioj.png" alt=""> After the first save, it's referenced like this, still the same. <img src="mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/jorgk.jorgk.com/Inbox?number=605&header=quotebody&part=1.2&filename=lijbmghmkilicioj.png" alt=""> After the second save, it's referenced like this: <img src="mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/jorgk.jorgk.com/Drafts?number=160&header=quotebody&part=1.2&filename=lijbmghmkilicioj.png" alt=""> So instead of referencing the original image from the inbox message, it now references into a draft. This is basically the same behaviour when *not* signing the message. However, when viewing the unsigned draft, there are MIME parts 1.1 and 1.2, when viewing the signed draft, there are MIME parts 1.1.1 and 1.1.2, so basically the reference is broken. Therefore a broken image is displayed. (I used the add-on ThunderHTMLedit to change "part=1.2" to "part=1.1.2" and that makes the image visible again.) Saving this one more time triggers the endless loop which is what bug 453196 is about. Summarising: Using a digital signature changes the number of the MIME parts. Consequently the image referenced cannot be addressed as before. This is the bug we need to fix here. Once this has happened, it's all downhill, since a bad reference leads to the endless attachment loop which is what bug 453196 is about. Terje, this is an important bug. You've been working in the MIME area recently. Perhaps you could work out what happens here.
This bug also affects Enigmail in a similar way. See https://sourceforge.net/p/enigmail/bugs/626/.
Fixed by changing the handling of embedded images in an access-restricted bug. Some details in the bugs depending on meta-bug 1322155. This work will ship with TB 52 ESR in March 2017. Users can try this in an Earlybird version TB 52a2 after Dec. 5th, 2016. Earlybird 52a2 is still not available at https://www.mozilla.org/en-US/thunderbird/channel/ but can be downloaded from here: http://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-aurora/ or localised from http://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-aurora-l10n/ This is for expert users only. Remember that Earlybird TB 52a2 is "alpha" software, so your PC might explode ;-)
(In reply to Birger from comment #5) > This bug also affects Enigmail in a similar way. See > https://sourceforge.net/p/enigmail/bugs/626/. https://sourceforge.net/p/enigmail/bugs/390/ also cites this bug 1251853