We might need a protocol update, but many mail providers disabled IMAP for non-premium users already because they tried to force people to use shitty web apps.

Why?

IMAP is antiquated and suboptimal with today’s clients and use cases.

You still send data through a TCP port, there is not much difference. Yes the protocol is in itself different, but that's expected - it's a different protocol after all.

That sound more like fud than fact. Van you back that up?

https://jmap.io/index.html (Scroll to FAQ: Why is JMAP better than IMAP?)

Very trustworthy coming from the site that advocates that protocol. But I agree with some points.

Even a cursery look into my languages Wikipedia notes that IMAP compared to JMAP is statefull and verbose which causes problems with mobile clients. Can you do some research on your own?

Kinda disagree with that. IMAP Idle works just fine for mobile.

JavaScript, embedded, in email is, pejoratively, a bad idea by putting too much power into a transmitted email.

Too many security holes, discovered and undiscovered with JavaScript, not to mention JMTP.

Better yet,

Hashing the local part of the email address and retrofitting mail clients to do the mapping and rejection is the best way to delete unwanted and unsolicited emails.

Couple that with new decentralized lookup of sender’s PKI (as well as DKIM).

That should add years/decades to SMTP viability and usability.

I was under the impression JMAP was just a sync protocol and had nothing to do with js in email. Is that incorrect?

JMAP is not JavaScript embedded in email. Are you thinking of something else?

But it does nothing to prevent JS in its payload.

I can also put JavaScript in a DNS TXT record; the protocol does nothing to stop that!

There is no "JavaScript" in JMAP in the sense that it's supported by the protocol, and the specification explicitly warns against email clients interpreting JavaScript.

Now you are getting the idea of how to design a new network protocol in contrast to adding the supporting numbers of parsers and validators.

Potential and actual vulnerabilities explodes, like the chronic problems of Microsoft Macros.

sure, but that's not a feature a protocol should have. Because the protocol itself does not interact with it in any way. It's clients that process that javascript and execute it. The protocol is about moving 'emails' from one place to another. If you don't want javascript in your email and run your own email stack you can certainly filter out javascript blobs if you want. Or you can chose clients that disable or simply don't even know what javascript is.

While it is a bit late to close the door on JS usage within SMTP protocol, choices of client SMTP becomes paramount given its legacy stage of SMTP protocol.

again, the protocol should be dumb, its a way to move bytes. If there is js encoded in those bytes the rotocol will not and should not know or care. It's up to a client do decide what it wants to do with the bytes it receives.

the client should be responsible for not executing embedded JS in a message

> JavaScript, embedded, in email is, pejoratively, a bad idea by putting too much power into a transmitted email

The exploits writers would like to politely disagree. /s

You cannot read this email until you disable your adblocker.