[avereveard]

I don't get it, I can have all of this on email right now, and still be compatible with the rest of the world

> choose the organizations/sites that relay your correspondence

SPF/DKIM

> select which members of a site can correspond with you

whitelists have been a thing in a while

> always know from which site a message originated

SPF

> can block anyone with whom you’ve made contact

blacklists have been a thing in a while

> may leave a site and never see traffic from it again

domain filter are a thing too. preemptive 'but you still receive emails' - no you can send a 550 early on and interrupt the transfer as soon as you get the envelope sender domain

> 2 To offer capabilities missing in traditional email, including

that's all client side stuff and you can do all of it as of today on top of email. first part of the protocol is to know which user sent you markdown before, so you can send markdown to them. for user that you don't know if they have a markdown clent, your own client send a multipart with markdown and the local markdown representation as html, so you have a two-in-one discovery/fallback mechanism

while the first one might be beneficial as you give more control from the sysad and into the user hand for point 1.5, the second part is a problem we already had and we already solved with the transition from text email to html email and it was never a protocol issue to begin with, so I don't understand why it has been rolled in here for more effort and little effective gains.

[networkimprov]

You can (sort of, with a great deal of effort) but you don't.

And there is no effective way to prevent phishing in SMTP/etc if the server accepts connections from the public Internet.

If you didn't, I suggest reading the protocol draft and "Why TMTP?"

[LoSboccacc]

you can check that the envelop and message sender header match at the mx level and let spf handle the rest