Subject: Exchange garbles RFC3156 PGPencrypt mail

From: Gunnar Lindberg <[email-masked]>
Date: Tue, 18 Aug 2009 16:40:33 +0200 (MEST)

I've been off this list for some time, so maybe the subject has
been beaten to death already. My excuses if so.

Also, I do understand that the IETF has no means of enforcing RFC
compliance. However the IETF is the standardization body for the
Internet and as such one could hope that a note from the IETF/IESG
may at least have some impact.

If you send a PGPencrypt:ed mail in RFC3156 ("PGP Mime") format
to a Microsoft Exchange server, the result is garbled to an extent
that programs like Thunderbird/Enigmail can no longer cope with it.

RFC3156 Example message:
    Content-Type: multipart/encrypted; boundary=foo;
       protocol="application/pgp-encrypted"
    ...

Exchange version:
    Content-Type: multipart/mixed; boundary=bar;
    ...

So, Exchange converts the message "type" (Mime top level) from
something that is quite well defined (multipart/encrypted) to
something that can be almost anything (multipart/mixed).

Two URLs:

    http://social.technet.microsoft.com/Forums/en-US/exchangesvrtransport/thread/0f90b1be-6e7e-4658-b577-2bcfec02f7c9

    http://mozilla-enigmail.org/forum/viewtopic.php?f=4&t=425

	Gunnar Lindberg

Exchange version, slightly more complete. The base64 encoded parts
contain the original mail. The base64 encoding is annoying but much
worse is that those parts are fairly much out of context.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      From: xxx <x@y>
      To: xxx <x@y>
      Mime-Version: 1.0
      Content-Type: multipart/mixed; boundary=bar;

      --bar
      Content-Type: text/plain; charset="us-ascii"
      Content-Transfer-Encoding: quoted-printable

      --bar
      Content-Type: application/pgp-encrypted;
        name="PGPMIME version identification"
      Content-Description: PGP/MIME version identification
      Content-Disposition: attachment;
        filename="PGPMIME version identification";
        size=76; creation-date="Fri, 03 Jul 2009 15:35:18 GMT";
        modification-date="Fri, 03 Jul 2009 15:35:18 GMT"
      Content-Transfer-Encoding: base64

      VmVyc2lvbjogMQ0K

      --bar
      Content-Type: application/octet-stream; name="encrypted.asc"
      Content-Description: OpenPGP encrypted message.asc
      Content-Disposition: attachment;
        filename="encrypted.asc"; size=2044;
        creation-date="Fri, 03 Jul 2009 15:35:18 GMT";
        modification-date="Fri, 03 Jul 2009 15:35:18 GMT"
      Content-Transfer-Encoding: base64

      LS0tLS1CRUdJTiBQR1Ag ...

      --bar--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: [email-masked]
Date: Tue, 18 Aug 2009 17:41:18 -0700 (PDT)

> something that can be almost anything (multipart/mixed).

I guess my question to you is why, out of the many thousands of compliance
issues in thousands of products from who knows how many vendors, many of which
result in far more mainstream interop issues that affect far more users, is
this particular worth singling out for action?

Heck, this isn't the only, or IMO the most serious, interop problem Exchange
has. For example, some versions of either Exchange or its clients refuse to
process calendar attachments that contain any sort of Content-disposition:
field. (It doesn't matter what the disposition value is - the simple presence
of the field triggers this behavior.) We run into this issue regularly and are
forced to implement mechanisms that strip such headers from all calendar
attachments, which can then cause interop problems elsewhere. Ick.

Mind you, I think draining the incompliance swamp would be a great thing to do.
I'm just skeptical that having the IETF/IESG weigh in on even a fraction of
them is remotely practical. We're more likely to drown than get the level down
by much.

				Ned