On 31 Jul 2005, at 8:53 AM, Hallam-Baker, Phillip wrote:
I did propose a mechanism for use of S.MIME at the start of MASS, Jon
Callas of PGP pointed out that they have already implemented
essentially
the same mechanism and it does not work well enough in practice due to
forwarders.
A couple people have asked me about this, and asked me to make a
comment.
I have server systems that do automated OpenPGP and S/MIME encryption
and signing. I don't think I said precisely that.
We have found that it is in general difficult to create a generic
signed / encrypted message that will end up looking right on all client
systems. This is true for both OpenPGP and S/MIME, and is more true the
more you make a fancy message. If you have a message that has HTML,
embedded pictures, and so on and you want to sign it, you can't come up
with a way to encode the message so that it will generically work on
all MUAs. There are things that will look bad in any given MUA, and no
subset that you can stick to that is a lowest common denominator. Now,
if you know in advance which MUA someone is using, it's easy to know
what to do. I can easily code a message so Outlook will display it
sensibly. Ditto for Eudora, Thunderbird, Mail.app, etc.
Forwarders, in the sense of a unix .forward file, a mailing list, or
something like that don't cause breakage.
Forwarding, as in the MUA command, does frequently break things. This
is one of my peeves with MIME mail in general. This is a problem with
MIME, not with signing, however. I'm -- umm -- notorious? -- for my
dislike of MIME email of any sort, and the reason is that MUAs seem to
handle it so badly. For example, my usual airline insists on sending
itineraries in MIME with lots of prettiness in it, and if I want to
forward my itinerary to someone (and still expect them to meet me at
the airport), I have to render it into PDF and send the PDF.
This isn't the same thing as "forwarders" breaking security multiparts.
A .forward works just fine.
Jon