Some good ideas, but also stops short on a few things.
* It talks about signing the message to prove the sender, but why stop there? We might as well extend it by having recipient public keys available via DNS records directly (or DNS specifying how to fetch them using some other protocol) and encrypting the contents of the e-mail as well. This alone could be the killer-app reason to adopt this thing.
* As the recipient of spam, I don't really care so much whether the sender owns the domain or not, because it's relatively cheap and easy for them to buy a domain and set up DKIM/DMARC if they had to. What I really care about is only receiving e-mail that I have opted into receiving. Whilst there will always be a need for some people to have public mailboxes that anyone can send to, for the most people it'd be better to have something where you can only send a mail to them if you have a token that grants you that right. My mail client should be able to fetch the potential sender's public key and sign a token that says this key can send mail to me until this date. Maybe every time you reply to someone, you send out a new token with a longer window. Maybe you need your mail client to prompt you to re-issue tokens to people you've previously been in contact with. But the ability to choose to end the conversation further would be great.
* Maybe for people who don't have a valid token to send to someone, there can be a way of requesting a token, maybe the sender's name, public key/address, a short sentence for justifciation and if the recipient agrees, then the sender can send the rest of the mail.
* Mailing lists would get a bit more messy, as they'd have to re-sign and maybe re-encrypt every message. Maybe that's not a bad thing though, as with re-encrypted contents it'd be harder to correlate the same message sent to different people as the same, thus tying them to the same list.
* As some other senders have said, I'm not sure full HTML is the answer. Markdown is better, because it would enable a client to unambiguously cut, quote and cite parts of the original. But people want all sorts of fancy formatting at times, so maybe we need a better markdown and/or restricted set of features. Most people also, don't really need all those colours etc, they just want something that's visually different to the rest of the conversation so you can tell who said what in a very jumbled thread. Maybe the markup should be required to identify which bits of copied content came from where.
That said, getting critical mass of adoption is going to be hard, and there's not really any money to make from implementing it, only expense. The article correctly points out that something will only happen if it gets critical buy-in from all the big names, but of them probably only want to do it if they can get up controlling something and being the gatekeepers of the rest of the internet.
> We might as well extend it by having recipient public keys available via DNS records directly (or DNS specifying how to fetch them using some other protocol) and encrypting the contents of the e-mail as well.
That's just OpenPGP. There's even an OPENPGPKEY DNS record type. We all know how that went. It requires users to know what public keys are.
Yeah, some way of authorizing senders would be nice. I don't think this will ever happen, but one can dream.
When registering on a website, the "validate email address" step would then be an auth flow, instead of "we send you an email and you click that link". And there's no need to authorize the website to send you messages, since successfully completing the flow would be good enough verification.
Could be based on OIDC or IndieAuth.
Forgot password for that website? Enter email, get redirected to your auth flow, verify. (Or just do something like "Login with Google", but with this thing instead).
The website abused the auth flow and requested permissions to send you messages, and now you're getting spam from them? Click some button that says "I don't want to receive messages from [NAME] anymore", where "[NAME]" is whatever name associated to that token, and it revokes that token.
Getting a weird message from some unknown site? Same as above, plus you would know who sold your token without needing email aliases or anything.
> * Maybe for people who don't have a valid token to send to someone, there can be a way of requesting a token, maybe the sender's name, public key/address, a short sentence for justifciation and if the recipient agrees, then the sender can send the rest of the mail.
It won't be long before you start getting request from Mr. "Buy MyProduct" and Ms. "Visit MyWebsite".
* It talks about signing the message to prove the sender, but why stop there? We might as well extend it by having recipient public keys available via DNS records directly (or DNS specifying how to fetch them using some other protocol) and encrypting the contents of the e-mail as well. This alone could be the killer-app reason to adopt this thing.
* As the recipient of spam, I don't really care so much whether the sender owns the domain or not, because it's relatively cheap and easy for them to buy a domain and set up DKIM/DMARC if they had to. What I really care about is only receiving e-mail that I have opted into receiving. Whilst there will always be a need for some people to have public mailboxes that anyone can send to, for the most people it'd be better to have something where you can only send a mail to them if you have a token that grants you that right. My mail client should be able to fetch the potential sender's public key and sign a token that says this key can send mail to me until this date. Maybe every time you reply to someone, you send out a new token with a longer window. Maybe you need your mail client to prompt you to re-issue tokens to people you've previously been in contact with. But the ability to choose to end the conversation further would be great.
* Maybe for people who don't have a valid token to send to someone, there can be a way of requesting a token, maybe the sender's name, public key/address, a short sentence for justifciation and if the recipient agrees, then the sender can send the rest of the mail.
* Mailing lists would get a bit more messy, as they'd have to re-sign and maybe re-encrypt every message. Maybe that's not a bad thing though, as with re-encrypted contents it'd be harder to correlate the same message sent to different people as the same, thus tying them to the same list.
* As some other senders have said, I'm not sure full HTML is the answer. Markdown is better, because it would enable a client to unambiguously cut, quote and cite parts of the original. But people want all sorts of fancy formatting at times, so maybe we need a better markdown and/or restricted set of features. Most people also, don't really need all those colours etc, they just want something that's visually different to the rest of the conversation so you can tell who said what in a very jumbled thread. Maybe the markup should be required to identify which bits of copied content came from where.
That said, getting critical mass of adoption is going to be hard, and there's not really any money to make from implementing it, only expense. The article correctly points out that something will only happen if it gets critical buy-in from all the big names, but of them probably only want to do it if they can get up controlling something and being the gatekeepers of the rest of the internet.