[ih] Design choices in SMTP

[Jack Haverty]

Personally I don't care whether something is enhanced or replaced. The 
important requirement is that the "new functionality" is easy for the 
end user to deploy, preferably being accomplished invisibly.   I've 
never heard of "JMAP", or seen any ISP or Mail software mention it, or 
any plan for deployment and transition. AFAIK, I'm still using IMAP.

Re a "problem statement"...

Fifty years ago, email was just starting but people who "got on email" 
could all communicate with each other.  For a while, several mail 
universes existed ARPANET, UUCP, MCI, AOL, etc.) and they typically were 
somehow interconnected so everyone could still communicate with each 
other.   Email was about as reliable as the underlying networks.  You 
could trust that an email you received from someone actually came from 
that person, and an email you sent would get delivered to the intended 
recipient.  Some such characteristics were mostly because of the 
collegial aspect of the network community at the time, but people were 
working on technological solutions (e.g., PGP).

Today, the email world is full of silos and walled gardens.   So I have 
to check my various SMTP mailboxes, LinkedIn, Facebook, Twitter, and 
other social media sites, and lots of "forums", plus SMS/MMS and various 
"secure" mailboxes for my accounts at places like banks and companies 
that don't trust SMTP mail, just to see if I have any message I should 
read or answer.   Sometimes it's called something different, like "DM" 
or "PM", but it's all persons-persons messaging.

It's difficult or impossible (or I just haven't discovered the magic 
incantations) to reply to, forward, save, search, or otherwise process 
mail involving correspondents who aren't in the same silo. If I want to 
find a message I saw a few months ago, I have to somehow remember 
whether it was on one of my SMTP accounts, or Facebook, or SMS, etc., or 
search all of them.   If I want to engage several others in a 
conversation, I have to do it in each silo they use.

Also of course I have to deal with all sorts of spam filters, settings, 
and mechanisms that seem to be sometimes good at blackholing legitimate 
messages while still delivering a lot of actual spam, and sometimes 
deliver messages that have been forged. I get mail purporting to be from 
someone (even myself) that isn't. Sometimes a message doesn't get 
delivered because it is deemed too large by some handler along the way.

It seems common now to hear "I never got your email", and also to be 
wary of acting on information in an incoming message.

I would like the reliability, pervasiveness, and trustworthiness of the 
70s email restored.  So, my "problem statement" would be something like:

"Provide a system for human-human communications that can be used on 
whatever kind of computer a person has at the time, accessing whatever 
kind of network that computer can utilize at the time, with high 
reliability, privacy, and guarantee of identity, for all humans, 
companies, organizations, governmental units, business partners, and 
other entities I want to communicate with, including the ability to 
store, archive, search, share, and authenticate messages sent and 
received over time.  The system must be inherently upgradable to reflect 
changes in underlying computers and networks, as well as its own 
internal evolution."

Multimedia of course...this is the 21st century.

Jack



On 2/7/23 12:20, Dave Crocker wrote:
> On 2/7/2023 10:44 AM, Jack Haverty via Internet-history wrote:
>> Seems like 40 years should be long enough.....maybe someone will take 
>> the next step. 
>
> Hmmm.  This seems too close to the "it's been around time, so it 
> should be replaced' assertion that is often made about long-standing, 
> successful protocols.
>
> What is typically missing is a) a very clear problem statement, in 
> terms that explain the very significant, real benefits to be sought, 
> and b) a constituency that is eager for that superior capability to be 
> delivered.
>
> A lesson of a number of protocols in use today is how well they have 
> supported enhancement, rather than replacement.
>
> So, yes, there will come a time, for each of these, when replacement 
> is better than enhancement.  But the extreme momentum of an installed 
> base at scale means there must be very strong market demand.
>
> By way of example, IMAP is generally assessed as having serious flaws, 
> with JMAP being developed as a replacement.  Have you heard of JMAP 
> before?  Any idea how its adoption curve is proceeding?
>
> d/
>