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.
> 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.