Date: Sun, 07 May 1995 17:37:07 -0700 (PDT)
From: Ned Freed <NED(_at_)INNOSOFT(_dot_)COM>
. . .
Every MIME agent also has to be prepared to deal with non-MIME
material as well.
I thought that I was following what you were saying up until this
point.
If Every MIME agent also has to be prepared to deal with non-MIME
material as well, then what is the problem with using the 822
compliant X-PGP-Signed: header. I thought that you said that MIME
gateways would trash this header?!?
You have it backwards once again, I'm afraid. It isn't the header that gets
lost or changed (this can happen, but it has nothing to do with MIME vs.
non-MIME processing), its the data that changes. And any change to the data
will (obviously) invalidate the signature.
MIME gateways are in the business of converting the content of MIME messages in
some way -- either to some other format like X.400 or cc:Mail or Microsoft Mail
or whatever, or else applying some sort of conversion operation. For example,
when a multipart is encountered most gateways will parse it and convert it into
into whatever attachment format is appropiate -- X.400 as well as most of the
PC LAN systems support attachments of one sort or another. This breaks the
signature -- such a gateway isn't going to see your header lines and thus
doesn't know to turn off this conversion processing. And the next scheme that
comes along, with its own set of headers, will have the same problem. And the
next. And the next.
Security multiparts are another matter entirely. MIME gateways pay attention to
content types -- that's why they exist in the first place. And moreover, they
pretty much have to be extensible on a type by type basis, since the collection
of available type is open and growing and gateways have to be able to adapt. As
such, it is relatively easy to tell a gateway that multipart/signed and
multipart/encrypted (or any other type) require special handling -- they should
be treated as opaque objects and copied in their entirety, or else if you're
going to diddle the content you might as well remove, recompute (if you can),
or annotate the signature since its going to be toast. There's usually a table
of some sort that you use to do this sort of thing. (MAILCAP files are one
example of such a table.)
It took me a whopping 10 minutes total to implement proper handling in our PMDF
products, for example, and PMDF is more difficult than most because PMDF has
trusted mail gateway capabilities, which means we have some cases where we want
to parse and handle security multiparts and others where we don't. On other
systems, e.g. ones based on MetaMail, its nothing more than a one-time one line
change in a configuration file, and I believe the default is already what you
want anyhow.
Ned