James M Galvin <galvin(_at_)acm(_dot_)org> writes:
I believe it is the design of RFC 1847 that makes interoperability
low.
In what way? Please explain.
Here are some of my issues with RFC 1847. I'm not sure a simple
revision of RFC 1847 can fix them, but I hope this is of some use
during the revision of the document at least. Some of these aren't
really technical arguments, but rather rooted in implementation and
operational experience.
* Assumes that MIME delimiters are immutable.
In practice, MIME delimiters are changed in transit. I haven't
found anything that explicitly forbids this in MIME, and the design
of MIME sort of suggests that decoding and re-encoding the document
is OK. Some IMAP servers are designed around this assumption, and I
can't say that I blame them.
* RFC 1847 assumes that applications have access to the raw
transmitted MIME blob, rather than a MIME decoded object. Some mail
access protocols, such as IMAP, can decode and split structured MIME
objects.
* It does not say that multipart/{signed,encrypted} parts (including
MIME delimiters) MUST be preserved as-is when MUAs forward them
using e.g. message/rfc822. Perhaps it is the odd one out, but the
"forward" function in Gnus decodes MIME messages by default, to be
able to display them properly in the message editing buffer, and
later re-encodes the message.
* Not the fault of RFC 1847, but some MIME applications does not
follow the MIME recommendation to treat unknown multipart/foo types
as multipart/mixed. So the parts are trashed, filtered, or marked
as "viruses" or something. This is a implementation problem, but if
a protocol can make implementation problems less likely to happen,
this should be considered in the design of the protocol IMHO.
* The MICALG parameter should be made optional. For some security
infrastructures, it isn't applicable. For OpenPGP, it is not clear
if the MICALG or the field inside the PGP signature blob should be
used. Some mailers (Mutt) have been sending MD5 in the MICALG field
and MIC:ing the message with SHA1.
Perhaps illustrating is to consider an alternative approach of
marrying mail security and MIME:
The MIME structure is left as-is, and the body part is altered to
include a "security" blob.
This path is chosen by some Outlook PGP plugins (surely because the
Outlook API is limited, and not by design, I am sure), and in my
experience it works better than PGP/MIME -- legacy applications
doesn't destroy the security blob and MIME aware message protocols are
able to to retrieve just one MIME part and have it be
verified/decrypted, everything else being equal. This solution is
probably a bit against the spirit of MIME (the Content-Type header
should be the sole specifier of how to treat a MIME body), so I'm not
seriously advocating it as a standard, but it could be useful to
compare the two approaches. One way to make this somewhat more MIME
friendly would to add a MIME Content-Type parameter "signed=pgp" on a
part that has undergone PGP treatment (and leaving the Content-Type to
text/plain, application/msword etc as is).