"This is a broken PGP/MIME message from MS-Exchange" RRS feed

  • Question

  • A colleague of mine just reported receiving a message with error "This is a broken PGP/MIME message from MS-Exchange" . 

    I Googled to see whether there was a solution. I find many other people having this problem, but it looks like every involved party is pointing to others. Like in https://gpgtools.tenderapp.com/discussions/problems/51432-messages-received-as-asc-attachments and many more ( https://www.google.nl/search?q="This+is+a+broken+PGP%2FMIME+message+from+MS-Exchange" ).

    I do think Exchange is playing a big role. Could Microsoft be so great and nice and take the lead and coordinate to see how this can be solved in general (so not specific (client of sender, client of receiver, in between servers etc) to the situation of my colleague)?

    • Edited by MrT2 Wednesday, February 21, 2018 1:33 PM
    Wednesday, February 21, 2018 1:33 PM

All replies

  • Hi,

    At present, we couldn't provide the general solutions before we get the details of the issue.

    To confirm with you:
    1. Are you using Exchange for mail? If so, what is your Exchange current version and build number?
    2. Are the receivers Exchange users? 
    3. What client are you using for mail? Outlook, OWA or other?
    4. Is there any intermediary device between your mail server and the external network?

    We could analysis the message header in ExRCA first for troubleshooting. 

    You are welcome to provide more details without sensitive message.
    Let me know the result.


    Manu Meng

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Thursday, February 22, 2018 2:52 AM
  • Thank you for the fast response. It would be great if you could route this problem internally, as i think it is a more generic problem.

    But i've checked with my colleague about the questions you pose, and his respons:

    1. Exchange Version is 15.0, Build 13220.4
    2. Sender and receiver are on the same machine (it concerned an email that was sent to me by a direct colleague that is working on the same Exchange server)
    3. Sender works with Apple Mail on MacOS, receiver uses Thunderbird on Linux
    4. Not as far as we know (checked with internal IT).

    I understand this is a complex ballet between OS's, clients, PGP and Exchange. I hope the finger pointing can stop and one of the parties works with others to solve this for many users.

    • Edited by MrT2 Thursday, February 22, 2018 10:35 AM
    Thursday, February 22, 2018 10:35 AM
  • Hi,

    I understand you but we still need more details.

    Please check if all the Mac users have the issue, we can check if issue persists in OWA.
    Also check this: S/MIME for message signing and encryption.


    Manu Meng

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, February 27, 2018 9:39 AM
  • Hi,

    I do have the same issue and did some testing:

    I use my microsoft email account at outlook.com and use Thunderbird as email client!

    The error always shows up at the receiver's end of the emails I send. No message arrives correctly if I send it with Thunderbird using my outlook account. If I use any other mail provider it always works, even if outlook.com is the receiver!

    That's what I tested with different email accounts:

    I sent emails

                 FROM:     Outlook.com       Web.de       gmail.com

    Outlook.com               error               ok                 ok

    Web.de                       error              ok                 ok

    gmail.com                  error               ok                 ok

    It really looks like a microsoft issue. Any ideas?

    Sunday, April 29, 2018 4:08 PM
  • I have this exact same problem with colleagues using Thunderbird / Office365 on MacOS/GnuPG. I am using MailMate as my user agent, but the same thing happened to me when I tried to send encrypted messages via Office365 using Thunderbird, or Mac Mail. Exchange corrupts the message resulting in the error seen above. The same thing works perfectly with GMail and these MUAs.
    Wednesday, September 26, 2018 2:54 PM
  • I am getting the same thing: I have an outlook email address and the solution I found that in the settings under Composition, I UNCHECK the default pgp/mime feature and let it just encrypt in front of me before sending and it works, no more error and no extraneous attachments as a result. I don't know if that hurts my pgp security on the message or not but try unchecking that feature on the account - close out Thunderbird and then restart and see if that fixes your problem. If this is harmful to the pgp security on encryption let me know and I will have to find the solution some other way.

    • Edited by crollinsphoto Wednesday, October 24, 2018 8:50 PM
    • Proposed as answer by crollinsphoto Wednesday, October 24, 2018 8:50 PM
    Wednesday, October 24, 2018 8:44 PM
  • Hey all,

    I've investigated the issue a bit more in-depth and noticed what might corrupt our PGP messages.

    I think the major culprit is as following: the outlook exchange servers change the content-type header. Upon sending the header is (at least by my client) as following:

    Content-Type: multipart/encrypted;

    When this email is then received by the other party, the header is magically changed to the following header:

    Content-Type: multipart/mixed;

    The rfc3156 clearly states that the only correct header for pgp encrypted messsages should be "multipart/encrypted", so this is potentially the culprit of these problems. When I issue my mail client to 'repair' the received message, I noted that this was the only major change present, further strengthening my suspicion of it being the cause for the problems.

    Note that the boundary also changed, this is because the message is also automatically converted into a base64 format, which is of no influence (the rfc states that encrypted messages should be 7-bit data, in order to allow this).

    Another interesting thing I noted is that the Content-Disposition header is changed from inline to attachment. I don't think this contributes to the fact that the mails are not rendered correctly (it's not mentioned in any of the RFC's), but I think this should probably not happen.


    Content-Disp osition: inline; filename="encrypted.asc"


    Content-Disp osition: attachment; filename="encrypted.asc"; size=2573;
    	creation-date="Mon, 10 Dec 2018 09:31:04 GMT";
    	modification-date="Mon, 10 Dec 2018 09:31:04 GMT"

    @Manu Meng, could you follow up on this?

    Sincerely yours,


    P.S. it is impossible to post the "Content-Disposition:" header in a code-block, as it gets filtered out, probably some bad spamfilter behaviour (I suspect because they think I'm trying to inject the css-property 'position'). To work around this I inserted a malformed space in the header.

    • Edited by Johannes.B Monday, December 10, 2018 10:19 AM
    Monday, December 10, 2018 10:07 AM
  • Dear Manu Meng,

    it's six month after @johannes.b had provided very detailed information. Do you need further detailed information?

    Furthermore, a quote from RFC 1847: 'Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted'
        The entire contents of the multipart/signed container must be treated
        as opaque while it is in transit from an originator to a recipient.
        Intermediate message transfer agents must not alter the content of a
        multipart/signed in any way, including, but not limited to, changing
        the content transfer encoding of the body part or any of its
        encapsulated body parts.
        Source: https://tools.ietf.org/html/rfc1847#page-4


    • Edited by doak doak Monday, June 24, 2019 12:54 PM Added addintional information
    Monday, June 24, 2019 12:49 PM