Re: Exchange garbles RFC3156 PGPencrypt mail

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]