Okay, just to set the stage...
What kind of world do we find ourselves in (regarding email
protocols...), and why, at some point in the future, might we want to
migrate to something new? What are the driving factors that might
change how we use email and therefore what we want email protocols to
do for us?
- Managing complexity
Because of the extreme success of the Internet in general and email in
particular, both SMTP and MIME have been extended to the point that they
are getting fairly baroque. ("baroque" in the sense that the term is
applied to programming languages - meaning they lack coherence and
regularity, and there is a tendency for features to compete with one
another and sometimes conflict.)
Every new extension adds complexity; that much is obvious. What is
perhaps less obvious is that extensions add more complexity because
they are optional and because they are implemented and deployed
independently of one another. This manifests in various ways.
If there are N optional features that each can be "off" or "on",
this potentially results in 2**N code paths on each of the sender
and receiver, which results in more code paths that need to be tested,
more opportunities for the system to fail in obscure ways (when
the code follows seldom-used paths), etc.
If all optional features were such that the sender or receiver could
enable them independently of one another, this would be (2**N)**2 total
sender/receiver code paths for one sender/receiver pair. If there
is a firewall between the two that modifies traffic it gets even worse.
Now multiply that times the (growing) number of different sender and/or
receiver implementations in widespread use. The above applies
to both SMTP and the message format. Now for SMTP, multiply that times
the number of hops a typical mail message traverses in getting from
origin to destination - any one of which can result in message failure.
This is of course exaggerated, because different options have different
effects, some of them are very simple and unlikely to fail, many options
cannot be enabled independently on both ends, etc. But it doesn't take
an exhaustively accurate mathematical model to show that incrementally
extending Internet mail protocols over and over again leads to a lot of
complexity that costs us in terms of implementation overhead, testing
time, product support costs, operational costs, and degraded
reliability. This is true for both SMTP and MIME but it's more true for
SMTP. And to a large extent the complexity results from having too many
different ways to do the same thing.
We're seeing this start to happen. It used to be unusual for two SMTP
implementations to fail to be able to talk to each other. Now it
happens occasionally, usually because one end or the other failed to
implement an optional feature correctly. Transparent firewalls
make failures even more likely.
This situation isn't horrible yet but it will get worse. What we might
need to do is have a solution for when it gets too bad, one that doesn't
involve further incremental extension of SMTP or MIME and haphazard
deployment of each new extension.
- Other factors
At the same time, email is starting to become a liability for
many people. Spam has given email a high noise-to-signal ratio -
so high that some people who were on the fringes of the net anyway
don't bother reading their email much anymore. Email-borne viruses
have made it risky to use a general-purpose computer to read email.
If we believe there is value in the email communications paradigm
(as opposed to say, SMS or downloading things from the web) we need
to fix the spam problem in an effective way. To some degree this
has been difficult because the norm for operation in the existing
email system is to allow mail from anybody without any kind of
authentication or tracability.
There is now pressure to extend the format of email addresses to
accomodate languages and names that aren't naturally representable
in ASCII (which is to say, most languages). This could require
changes to both the message format and the mail transport,
since addresses are used by both of these.
There is now pressure to make substantial changes to email protocols
to accomodate voice mail and fax systems, which can degrade further
interoperability of email if they're not done carefully. (I haven't
read the latest draft of the content-negotiation proposal, so I don't
yet know whether the problems with the old draft are fixed.)
- A bit of speculation
The way people use the Internet is going to change (again). There are a
lot more cell phones in the world than home computers, and it's
increasingly the case that new cell phones have some kind of Internet
access capability. The Internet is the most obvious fabric to support
convergence between dissimilar devices and communications paradigms.
This may result in even more pressure to adapt email protocols for new
purposes; it will certainly change how people use email in relation to
other communications media.
And then there's always a potential for IPv6 to put a wrinkle in
how email works, if we get to the point that there's substantial
divergence between the community served by IPv6 and that served
by IPv4. (There was once divergence in how RFC 822 was used between
BITNET/EARN and the Internet and in the UUCP world, so it could
happen again.)
----
Responses are welcome. But rather than arguing about these too much
at this stage I suspect it would be more productive if people
contributed their own ideas about what factors might compel us to
migrate to new or substantially changed mail protocols (or not).
Keith
--
He not busy being born, is busy dying. - Bob Dylan