On 8/24/23 11:22, Murray S. Kucherawy wrote:
What aspects of email needed standardization and interoperability that didn't get it?
Given the grassroots nature of how the IETF generally does work, it seems like an interesting idea that we should be asserting ourselves over an area (and finding people willing to volunteer to do so). If the community didn't spontaneously demonstrate that momentum, I wonder what you think should've been done differently.
Mostly, we've failed to adapt email to changing conditions.
I won't say that we've made absolutely no efforts to do those
things. e.g. We've tried to make IMAP work better for mobile
devices. I'm not in a position to evaluate how successful we
were, but I do recognize that sincere and significant efforts were
made. And we also tried, long ago, to find ways of dealing with
spam. I remember how painful and fruitless those discussions
were, so I can understand why people are reluctant to wade into
those waters again. But conditions do change over time, and
changing conditions can bring new opportunities.
But some specific failures (in no particular order):
- We have, IMO, largely failed to make email interoperable in the presence of spam filters. Making email delivery reliable is currently, as far as I can tell, a dark art.
- The widespread use of email from mobile handheld devices has
had a tremendous effect on the usability of email for technical
collaboration, such as IETF does. I used to call this problem
"Blackberry disease" because I recognized that the people
reading email on Blackberry devices (i.e. some of the first
handheld devices to support email) were completely unwilling to
read a message more than a few lines long. You might think
IETF would be in a good position to address those issues, as we
have long and deep experience using email for collaboration on
long technical documents.
The fix to this might be as simple as defining a "read later on a desktop" IMAP flag and encouraging MUA vendors to put explicit support for it in their products, but we haven't tried.
- We've completely failed to make email end-to-end secure, not because the problems aren't solvable, but because we've let a very small number of people talk us out of trying.
- We've failed to adapt SMTP/IMAP/POP authentication standards (and for authentication in other application protocols) to a world where multi-factor authentication is increasingly required, and where hardware authentication tokens are widely available.
- We've done nothing to explore the potential for interactive
email, or even examined what support is needed in email
standards to enable it.
- We haven't made emailed HTML work well, or even predictably, from one MUA to another.
- We have failed to keep email relevant, in the public's view, except perhaps for business-to-business communications.
- Thirty years ago many of us would have said that email was the
killer app for the Internet. In particular it was a ubiquitous
service that would enable anyone with Internet access to
communicate with anyone else who had Internet access, without
prior arrangement. These days email is often considered the
communications method of last resort, despite that it is in
almost every way more functional than social media platforms and
other messaging services. This isn't because the service
provided by email is less relevant today than it was in say
1990, but rather, because email as experienced by users is much
less reliable than it once was. We used to say that email was
reliable because SMTP implementations were persistent in making
delivery attempts. Nowdays it's not reliable at all, and
people trying to correspond by email routinely maintain multiple
email addresses at different services in the hopes of
circumventing spam filters.
I realize of course that the increasing scale of the Internet and the ease of spamming have changed the situation since 1990. But we haven't even identified an alternative model to "without prior arrangement" that could make email provide a ubiquitous service again.
- We haven't made email portable from one MSP to another, even
though the protocol support to do that mostly exists. (This
does require that each user get their own DNS name, but that's
possible, if expensive and somewhat awkward to do in practice).
- In practice non-interactive use of email is now hobbled because of some providers' authentication requirements.
I'm sure I could come up with other examples, but perhaps those
will do for a start.
Most of these problems aren't simple to solve, but that's no
excuse for ignoring them or pretending that they don't exist.
Keith
