On 9 Oct 2004, John R Levine wrote:
Instead, I'm suggesting applying S/MIME or PGP to the *server-to-server*
communications. In effect, the first hop MTA server e-mails to the last
hop MTA server the end user's e-mail, both headers and message body, as a
signed e-mail attachment.
What's your transition model? It'll be a long time before we can assume
that recipient MTAs understand MIME and how to unwrap encapsulated
messages.
I think its fairly clear that almost all MUAs used now talk MIME and that
99.9% of email being sent is MIME (by that I mean any mail that has
"Mime-Version:" header, some emails may not have mime parts if they
consist of just one piece of text).
Now the reason why MTAs don't support MIME is simply because they don't
need it. All MTAs do right now is use RFC2821 data and send email on
its way based on that (and add Received header, which process does not
need MIME). This has existed for historic reasons since before MIME was
not used quite as much as it is now.
But I think its fairly safe to assume now that email coming through MTAs
are all MIME capable and that if MTA need to work with MIME we can make
it possible. Writing support for it should also not be all that difficult
since there are both free and commercial MIME libraries available for
pretty much all operating systems.
Now its entirely different story if we want to require email to be
S/MIME and encapsulate text MIME part inside complex MIME tree. Then we
better make sure first that close to all MUAs can understand this and
that may not be true.
---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net