Re-thinking electronic mail
liw.fi
liw.fi
Alternate proposals have failed and will always fail due to the ingrained nature of email. Nobody is going to use a new email system that allows communication to zero or very few recipients, and the system can never bootstrap. And that's that, no alternative to email will succeed if its only claim to fame is that is "email done right", that's a much too weak feature to break SMTP's decades of first mover advantage.
To break this clinch, you need to either:
1. deliver a communication product that has much superior features, and incidentally does mail very very well; people will start to use it for the other features, play with its email subset functionally, and in many, many, many years, the email will wither and die. Up to now, despite many claims to the contrary, no one managed to do that. The average lifespan of instant messaging protocols is around two decades (anyone on ICQ or Yahoo anymore?), while email is going strong into its 50s.
2. backport those advanced features into SMTP so that they are interoperable with the existing infrastructure AND, at the same time, deliver a tangible benefit to the people using those features, AND deliver those benefits today, not into some distant future where most people start to use it (PGP, where are you). This is a very hard set of conditions and very few technologies have managed to fulfill them, as a consequence email has evolved very slowly.
So if you don't want to have the old "canned letter response making fun of your antispam system" rubbed in your face, you better start working on number 1. or number 2.
For example, the tag could be your public encryption key. Then, your email app, whenever it receives a public key from a sender, the app now knows their public key and can send them encrypted messages. Those without the public key, get the plaintext email.
This can all happen completely without any action on the part of the user.
Over time, it will gradually become ubiquitous, like https did.
How does the person rotate keys if we only talk occasionally?
Or, if we’re looking for a bigger, overall flaw: e-mail is fundamentally fire-and-forget via SMTP, so there isn’t a way to use the users pubkey to creat a per-message session key, and reusing a persistent key for encrypting data is a massive pitfall.
A more direct solution would be to leverage the DNSSec infrastructure and publish, say, an "MXK record" (MX Keyserver) for each compliant server. If such a record is present, then the mail domain vouches that you can find at that specific address a VKS keyserver that can resolve individual public keys for all its mailboxes. The whole exchange is encrypted and hierarchically authenticated, from the DNSSec root down to the individual mailbox, so it requires the cooperation/compromise of the specific level to break.
This way, when you type "user@host" in your email client's To: bar, the client can immediately resolve the public key of the recipient, and encrypt and sign the message accordingly with a high confidence that the encryption will be transparent and ensure the security of the exchange.
DANE was ditched not because of technical problems or political pushback, but simply due to lack of adoption. Massive network effects and existing investment in the broken CA model, sites don't care about interacting with two sets of PKI if customers will only reach them on one, therefore they don't publish DANE records, therefore the support is removed from major browsers after a few years essentially to reduce dead code and 1024 bit RSA keys. If you know otherwise please enlighten. So it's the same problem everywhere, lack of interoperability chains us to outdated protocols, a problem of course shared by my proposal too.
There's no learning curve with the scheme I proposed.
You trust it as much as you trust getting getting unencrypted email from your friends. The point, though, is that from then on, nobody else can eavesdrop on your communications with the person who sent you their public key. You can still verify it by calling up the person and asking if he sent it. Or you can have him send the key via snail mail.
> How does the person rotate keys if we only talk occasionally?
The same way you got the original key.
> so there isn’t a way to use the users pubkey to creat a per-message session key, and reusing a persistent key for encrypting data is a massive pitfall.
Is it that massive? SSH uses keys that aren't changed every time it's used it, and it's still viable.
Besides, it's as secure as any public key cryptosystem is, and that's a heck of a lot better than plaintext.
And, to say the underlying part out loud: an encryption system can be a heck of a lot worse than plaintext, because plenty of ways of handling encryption are trivially broken, but give the user an illusion that what they’re saying is secure.
For rotation: my specific question was around long delays. Say, for example, you email me today. I get your public key from this new tag we’ve added. A month later, you rotate your key, but the next time we exchange emails is when I email you a year from now. I’m using your old key, the one I have.
> but give the user an illusion that what they’re saying is secure.
I don't trust any encryption system with my life or the nuclear launch code. But for casual privacy, the scheme I proposed is fine.
> I’m using your old key, the one I have
Then my system should bounce it back saying the key is invalid. Of course, if I change my key the email app should send a "new public key" email to my address book.
I said long-lived keys for data encryption is a pitfall, you pointed out SSH uses long-lived keys, I said it doesn’t use them for data encryption, and now you’ve just said an unrelated true thing about SSH?
There’s a huge valley of users between “casual privacy” and “nuclear launch codes”. Most humans live there. If your pitch is that your system is a casual privacy tool, just use email. Casual threats aren’t doing dragnet email surveillance or hacking email providers.
The lock on my front door is easily circumvented by anyone determined to get in. But we still use door locks, and locks are far more effective than otherwise.
My proposal is ridiculously simple. All it requires is to standardize a single tag in the email protocol which provides a public key and agrees on a particular public key method. That's it.
Email apps can support it, or not, it still works. Even if just gmail supported it, or Thunderbird, or Outlook, it will be viable.
An Email is not analogous to a house, it's more akin to a tent, or a lean-to; A simple solution to a simple problem.
Tent: How can we build a serviceable shelter that can be quickly un/packed, built, and costs next to nothing?
Email: How can we enable everyone to send messages to everyone else with as little inconvenience as possible?
Both solutions solve the stated problem, and that's it. If I want a secure shelter, a tent alone will not suffice, I have to build a ditch&wall around it. Similarly, if I want secure communication, I have to encrypt the message before sending it via Email.
SMTP is not made to be secure, because that's not the problem domain it concerns itself with.
If it's happened for all of those things (and some of them going from a more useful platform to less useful), it can happen for email.
For communication platforms the network effects are paramount, no one will move to Mail2 just to send plain old emails that almost no one can receive. If you can build a new email with much more attractive features, then you can disrupt email, which is exactly what I said.
If it had been possible to send a Wave to an email address (some sort of embedding?) and receive email to your Wave address, I think it would have succeeded in replacing email.
Instead, for reasons I'll never understand, Google tried to replicate the limited number of invitations system that had worked for Gmail, despite the fact that only having a limited number of people you could communicate with made the product effectively useless.
It worked for Gmail because you could send email from Gmail to anywhere, and receive it from anywhere! Missing that Wave was fundamentally different to me is one of the worst tech marketing failures I've seen.
Should we tell smeej about Google's fifty OTHER failed IM marketing attempts?
A handful of credible alternative protocols are now in development:
DIME - https://en.wikipedia.org/wiki/Dark_Mail_Alliance
Math Mesh - https://mathmesh.com
TMTP - https://mnmnotmail.org (my work)
Email was designed in the 1970s & 80s for an Internet whose population and topology have dramatically changed since. We no longer need a messaging system that allows anyone, claiming any identity (i.e. "real name"), to send you any content, without limits. Federation was necessary for the topology of the early Internet, but today it is a drawback -- making email by far the most effective method to initiate cyberattacks.
I would even go further and alot email priorities, each high priority requiring a higher payment. So my bank notifying me of an attempted login might pay a little more, but that message goes to the top of my heap. Whereas aunt sally's digital birthday card cost her near nothing and I'll get to it when I'm done with all the attempted logins to my bank.
The best part of this system is that it really does not require actual money to be exchanged. If one prefers, he could just mine the coins he uses to send the mail with. That's a feature, not a bug, to keep the system inclusive for all low-volume senders but far less so for spammers. It also makes scamming far less lucrative.
If we’re building all this tech for coins or digital stamps, it seems like the existing system could work fine by rolling per-contact email addresses to give out. Traceability without having to kill any polar bears. Apple is already offering this through their Apple Sign-In
Yeah mining coins totally doesn't exclude poor people. If it costs less than the profit spammers make they will use it. You can't just handwave the thresold away, and pretend you are solving the problem by just asking for money(thereby excluding large swaths of people). Just use your iMessage.
That said, since this problem already exists in the world, it is often overstated.
If a stamp is a reasonable cost, and only a one time cost, it will be largely invisible. 25 cents (a price set by the recipient) to send a message from a stranger won't have a big impact on most people, and it's important to recognize it's only the first time.
It's further important to know it would even be possible to refund the cost of the stamp back to the sender once the message is sent. The recipient could have a button that says "Return stamp" which would then let the sender re-use or in some other way organize the stamp.
Now let's contrast to today... Let's say I want to send a message to a big movie star or a CEO. The chances that I will be able to get their address is relatively low. Even if I do, they likely have someone they pay to filter their messages before it gets to them.
Also, recipients could have deny-lists and automatically share them with others they trust. The deny-lists might be a list of senders' cryptographically generated IDs, in which case it should be reasonably hard to generate new ones (e.g. 10 minutes on an X86 cpu using an algorithm not conducive to parallelisation or special hardware).
No way am I going to solve captchas for incoming emails! Not any.
Stamps are just tokens, as in bearer tokens. How you get stamps is a different issue. Let me give you a couple of examples how one might do stamps without cryptocurrency:
1. Alice, "I'd like 100 Bob stamps please." Bob: "Please pay me $5"
2. Alice, "I'd like 100 Bob stamps please." Bob: "Can you please do some computational work on my behalf?"
3. Alice: "I'd like 100 Bob stamps please." Bob: "How will you pay for them?" Alice: "I could trade in 30 Carol stamps, would that work?" Bob: "Yes, let's trade Carol stamps for Bob stamps."
As for Apple Sign-In, I don't know what it is, so I can't speak to it.
Not only does this give you a nice way to really cancel, it also means you can track down if someone sold your address to a spam list. Or if it accidentally leaks, rotate it.
The problem is you can't give out "per-contact email addresses" to future unknown people when you can't predict who will legitimately send you email that's not spam.
The random-generated-rolling email addresses that hides real addresses such as systems in Apple/craigslist/ebay/domainWhoISprivacy can function because there's already a non-email type of _transaction_ or _activity_ to establish the first link for communication -- without requiring a reference to a person id. E.g. Consider that it's the _user_ that first enters the "fake" rolling email address into a shopping website. In that case, the activity is "shopping cart" and now the website can communicate back with that fake email.
That doesn't work for other real-life scenarios where the sender only has the person in mind to send a message but no transaction or other triggering activity to publish/discover a random email address. For that, you need stable easy-to-type addresses such as johndoe@example.com which you can put on business cards. But the problem is that spammers also know that non-random email address. So the cpu-puzzles approach was (attempting to) solve a different problem: people can publicize their stable email addresses but spammers also knowing it doesn't matter because they don't want to spend $$$ on cpu.
Of course you can use a QR code.
In the world where you can’t do this, you could have a request mechanism. It’s a link, you go there, and it requires one-time auth from _any site at all of note_. Some sort of social proof. And that gives you a link.
Though ultimately business cards are business cards are business cards. They’re pretty low-value and you probably want to put a less important email on there.
Sure but as I previously mentioned, that proposal is another variation of a "solution" where you must do some non-email activity first such as ... authorize with login credentials from LinkedIn/Facebook/Google/Github/Apple/etc ... and then receive the generated rolling email address.
Yes, if the solution space is opened up to include doing non-email activity as a prerequisite to later communicating via email, there are many ideas. But many SMTP email decentralized purists think having to use centralized "social proof" sites such as Facebook for single-sign-on credentials is not an acceptable solution.
That's why the (failed) Hashcash idea had appeal for email enthusiasts that wanted the "proof" to reside _within_ the SMTP ecosystem. E.g. the extra Hashcash email header row would be something like "X-Hashcash: 1:20:1303030600:anni@cypherspace.org::McMybZIhxKXu57jd:ckvi"
The "sudoku-solving" hashcash "proof" as one might call it... is generated by the email sender and verified by the receiver without relying on a non-email entity. The "legitimacy score" of new emails from new unknown users can be calculated and assessed within the SMTP ecosystem. ... But it's not a solution that pleases everyone because there are inevitable tradeoffs: (1) cpu heat "killing polar bears" and (2) home computers (instead of spammers' computers) inadvertently expend the cpu because of infection by malware to become part of a bot army
So to go back to your idea of a non-email activity as a requirement to open up a new email communication link... this is not an unreasonable scenario as this was the way SMTP email in 1981 used to work. Before the general public accessed the internet in the 1990s, the email system didn't have a massive spam problem because the non-email activity to prevent it was being hired by University of XYZ that was part of the network linked by National Science Foundation. (That researcher had ".edu" address.) Or the person wanting to send an email was a government worker in the Department of Defense. (That government worker had a ".mil" address.) So any new email users were already vetted by the hiring procedures of universities and United States government. It's like an ancient form of "social proof" without Facebook/LinkedIn/etc. As a consequence, a researcher "bob@xyz.edu" sending a new email to "alice@darpa.mil" -- was not likely to be spam. (Similar to users noticing that their company Slack channel doesn't have spam. Yes, it's because the people talking to you on Slack had to be hired first and therefore, your coworkers are unlikely to send you spam.)
But now that email is "opened up to everybody" -- including the spammers, the "hiring procedures" as the non-email activity to prevent spam doesn't scale up for a billion new users. So your proposal tries to re-create a barrier again... instead of University of Illinois vetting you before giving you an ".edu" email address, the similar idea for modern times is to have something like Facebook "vet" you with their sign-on credentials before revealing some random generated per-contact email address.
To summarize the meta categories of solutions for email spam:
- outside of email universe solutions: non-SMTP non-email activity prerequisite such as 3rd-party entity "social proof": e.g. 1980s old days of being hired by USA government or educational institution, or today's proposal of 3rd-party SSO credentials from centralized websites such as Facebook
- inside the email universe solutions: proof-of-work, Bayesian text filtering, domain and ip reputation blacklists, etc
(But domain and ip reputation blacklists solutions can arguably be categorized as "outside" of email system because it requires a big entity that can scan millions/billions of email traffic to create the blacklists. A residential SMTP server sending a new email to another residential SMTP server won't have that reputation list.)
Your bank is going to increase your fees to cover the cost of sending mail to you, so the process is a pointless waste of resources in that case. This illustrates the need for a free mechanism between parties that trust each other.
It could, if you choose, cost them your business.
And allow recipients to whitelist senders who don't need payment.
If, instead of creating that template, somebody had made Thunderbird send PoW headers and priotize those that had it, maybe we would have been in a freer world.
The basic problem with the proposal is that it fundamentally misunderstands how the economics of spam works. Especially when it comes to the idea of using proof-of-CPU time to generate the cost to send mail. Spam generally comes from compromised machines, so the people who would actually be paying the cost of sending mail are not the spammers, but those who own the compromised systems. In effect, you'd be making everyone but the spammers pay for their email. (And the idea of being able to pay extra to get higher priority is going to be a godsend to spammers--historically, spammers were the most eager to implement anti-spam technologies such as SPF because of the boost it gives the spam.)
I think he was replying to this that the gp wrote: "The best part of this system is that it really does not require actual money [...] , he could just _mine_ the coins he uses to send the mail with."
> using proof-of-CPU time to generate the cost to send mail. Spam generally
> comes from compromised machines
This applies whatever the cost values is; if it's low, it's low for spammers. If it's high, it's high for individuals. And wherever "low" or "high" is, someone you like will think it expensive enough to be in the way and someone you dislike will think it cheap enough to be no problem.
[1] if the bank stopped the attempted logon, I don't care. If the login was actually me messing up, I already know. If they didn't stop the logon, then they didn't detect it was fraudulent and wouldn't be emailing or calling at all.
It's generally very easy to identify spam email, and delete it. I can almost always do this by the sender and subject line alone, without opening the message. It takes less time to do this than it does to periodically peruse your spam folder for false postives.
Encryption/digital signatures that rely on any kind of PKI architecture won't work, because most people don't understand it or won't trust it or both.
What might work is ssh-like "trust on first contact." You get a signed email from a friend. You get a little notice "you haven't seen this signature before, do you want to trust it." You can turn it off if you don't want to bother with this, and you need to be able to easily revoke the trust if you make a mistake (so even this is getting complicated). The keys need to be generated with no more complexity than "ssh-keygen" (and I work with many people, college-educated, who can't manage even that).
I'm in tech, I do it for a living. I don't sign my email, and I don't verify signatures on the signed email I get. If I don't think it's worth the bother, my mom certainly won't.
And all it cost was IP reputation systems that undermine email’s claim to be decentralized, language heuristics that undermine its claim to be reliable, and greylisting that undermine its claim to be fast.
Deltachat is working like that and I can't wait for the day everyone switches to an alternative client that behaves like it is from this century, like deltachat, instead of the last one.
Who actually needs the following ?
- open a different window (ie a different context) than the one you're currently in - a greetings line - quoting the entire mail you're replying to - the choice of whether you include an attachment inline or as a real attachment - threads that you can't have a glance at because messages are in different mailboxes (inbox, archive, Sent, ...) - having to click on each message to read the conversation instead of having it all in one view that you can just scroll (thanks Gmail for doing this correctly) - a custom signature no one really reads
Email's basis works, but we still use it like we wrote snail mail. No one writes snail mail anymore. It's time we use it in a more modern manner.
- open in different window: all the time. I am writing one email and searching/reading email archive for context. Also just keeping an individual message open in a separate window as a reference, while using main email window regularly.
- greetings line: I don't think it's a "feature" but I use it when starting a thread, especially when writing to people who I am not very familiar with.
- quoting entire mail: pretty frequent, for example when adding a new person to an email thread. Also handy for selective reply, it is easier to delete parts you don't need from quoted email than to start from blank and copy from original email.
- inline/attachment toggle: I don't think my email program has this
- threads split across mailboxes: not very helpful. But the multiple mailboxes is must-have.
- clickable message list: situational but occasionally helpful. Mostly when the is a thread with lots of messages, and you are looking for this rare message from the specific author.
- custom signature: I am don't have one personally, but some people put their position, office location and phone number there, and this is pretty helpful.
The email is different than instant messaging - it is harder to use, but is much more powerful if you learn to master it. The deltachat (judging by screenshots on their website) seems like a very basic and low-featured client, which unfortunately promotes bad habits in email, like writing short messages and expecting instant replies. I am glad it has not caught on.
The internet is unfortunately not user-centric enough, there is much more value in sending crap html emails "only 10 hours left 50% discount" and scanning your emails than there is to provide users with secure communications.
let's all sign our emails to raise awareness of google's & outlook shortcoming
P.S : we tend not to sign our emails since it is not the standard, standard is de-facto dictated by google and outlook now.
P.P.S : seeing an unsigned email would raise suspicion if the standard was the opposite, a filter could even classify between signed and unsigned
P.P.P.S : you would only bother to verify the identity for the emails you care for
P.P.P.P.S : if you think google does not dictate the standards, feel free to point to me the part of the rfc that mention that residential ips are not valid.
No standard says, or even suggest, that “residential ips are not valid.” However, reputation is an important par of mail security. Most, if not all residential IPs won’t be sending enough mail to even register a reputation (look up your own on https://talosintelligence.com/). This is the main challenge for self-hosters. That and a significant majority of residential ISPs block SMTP traffic, for very obvious reasons. This isn’t some Google/Microsoft conspiracy. SMTP is fundamentally a plain text format that has been abused for the last 30 or so years - 30, because that’s when MIME became a thing.
Fwd/Rev DNS Match Yes Last Day Vol. 0.0 Last Month Vol. 0.0 Block Lists 1 BLOCKED IN: pbl.spamhaus.org Email Rep. Poor
The vast majority of email routes through a few major email service providers, with gmail the largest, but MS (via O365 hosting) and Yahoo are also likely double-digit market share.
Are you proposing that they mark every mail spam that's not on the contact list of user? Otherwise checking signatures doesn't do anything, spammers already use dkim.
The root problem is that we treat anonymous email (unsigned) the same as email from people we know (signed by such a person). Treating anonymous email with normal suspicion pretty much solves the problems with email ... as pointed out in the article.
I think there is a tendency to want to solve a technical problem, even when no such problem exists. This will ultimately have to be solved at the people level.
I have a rule in Thunderbird that directs all email from senders not in my contacts list to a separate folder instead of the inbox.
Lets walk through the proposed solutions to this issue, because this is the biggest problem I see with the proposed new way of mailing:
> In the simplest case, the server might never give out stamps
For me, that's not feasible. I hand out my mail addr. with cards, as signature, its on websites, in READMEs, etc. I knowingly invite people to contact me via mail.
> The server might require the putative sender to solve a CAPTCHA of some kind.
How does that work if the mail is generated automatically, eg. a coworker makes me the recipient of a customers monitoring system? How does this work if the mail is generated without a GUI, eg. using a terminal mail-client?
> The server might require the sender to write a short sentence of why they want to reach the recipient. If that contains keywords chosen by the recipient, the server issues the stamp.
How does this solve the problem of being able to be contacted by strangers? The would-be sender has to know the keywords. If these are publicly available, eg. in a README, then there is no security, if they are not, sending a mail becomes guesswork for the sender.
> The server might require some sort of proof of work.
Let's forget for a moment how much trouble is caused by the energy consumption of cryptocurrencies, but how would that work on, say, a mobile device with already limited battery power?
> The server could require a very small payment.
The article points out the problem with this already. This would mean companies that can afford the fees are now free to spam me with advertising, but someone from an underprivileged community, who found a bug in my project, may think twice about contacting me.
-----
Edit: In my opinion, spam and phishing are not problems that should be solved by changing or replacing SMTP.
Don't get me wrong, I am not defending SMTP. It has a lot of shortcomings that need to be addressed, the biggest are an incabability to transmit binary data without resorting to base64 encoding, and the lack of built-in encryption support.
But spam and phising are issues to be solved at the application level, not the protocol level. Spam isn't that different from portscans, and we don't change TCP/IP to prevent these.
One of the things that I think many people don't really understand about the proposal I made for Stamps is that POW is not required for stamps. Stamps can be given in any number of ways.
For example, someone could simply issue them, with money. For example, if Alice wants to contact Bob for the first time, Bob might say "It will cost one Stamp please", and then Alice will need to get a stamp, maybe it costs 25 cents. Then Alice gives the stamp to Bob, and Bob lets the message pass.
I think proof-of-work systems are incredibly wasteful, and would think that should be an absolute last resort.
Say a purchase representative wants to contact another company with inquiries about purchasing options for their product.
To draw a clumsy analogy: Imagine a supermarket charging an entrance fee. How many customers would they have?
90% of European supermarkets (and some Canadian supermarkets) require you to put money in them to unlock them. It's either 1 euro or 1 Canadian dollar.
You get your money back when you give the cart back.
> How many customers would they have?
shrug
Guess you've not heard of port knocking.
It's implemented at the application layer via a daemon listening for knocks and opening the firewall on demand.
Some have contact lists and email from the same provider and synced to the cloud (e.g. gmail/gcontacts; e.g. iCloud+ email hosting and icloud sync for contacts). One would expect these data sources work together, but it seems that today at best one informs the spam filter of the other, and not necessarily server side. There is potential in moving the smartness to earlier stages of the transmission where the sender is also bearing some of the costs.
JMAP (sic!) is a good step to standardize syncing here. Still think there is untapped potential even there.
One of the big revolutions in antispam was reputation-based, which is used in all large email providers. Effectively, every email domain gets a reputation based on their email history. Someone like @gmail.com that sends a lot of mail to the server that isn't spam is going to get through easily. Someone like @spammymcspamface.com that sends naught but spam is going to get black holed. Someone like @whoami.com who hasn't sent anything is going to get throttled until they can establish a reputation as not-spammy.
I am concerned that charging even a penny per email would make it harder for people in developing nations to send mail (you need to understand how insanely poor some people are), and those are the countries that spammers might take advantage of. We should be very careful in today's world not to make technology that negatively affects the most vulnerable.
This idea mostly already exists in proprietary e-mail relays like Craigslist email addresses, but it would be nice if it were a standard.
a) I agree email is forked up.
b) I think a stamps-like solution could possibly work, but it's not the email part that makes it hard, it's the ecosystem around email that makes it hard. For example, once you send an attenuated capability to someone else, you've lost it, which means your system needs to be aware that what you're sending is a capability token and not an identity token.
If what I've said doesn't make sense- I'll explain a bit later on in this post.
c) I think it's nice to think creatively about message systems, including email, XMPP, ActivityPub
Now I'll say where I see the problems here being:
1. Overlaying on top of email
The problem with a protocol such as email is once it's in place, it's in place. Stamps (which is the idea the author references) could maybe be overlayed on ActivityPub- but I worry the time for that ship is either closing or it's sailed. I have many more thoughts on this point but it would be pages of thinking, so I'll leave it at that.
2. Cryptography not required
The author wants public keys, emails signed, etc. You don't need any of that for this to work.
What I proposed for AP (and still do) is that we can have a "public" address and then private, revocable addresses. You can then combine that with a bearer token exchange system. It's actually very simple, though I'm oversimplifying it too much here.
3. The author says I got it from Christine Webber, and "who knows where she got it from"- She got it from Mark Miller's Ph.D thesis, as well as the work done by Chip Morningstar. The theory behind all of this is called Object-capability Theory (https://en.wikipedia.org/wiki/Object-capability_model)
The email addresses are what the OCAP folks would call a capability token- the ability to send an email is a capability, and the special email I give someone is a capability token, a bearer token in this case (though there are other patterns in the OCAP world).
I can then make other attenuated capabilities, ie proxy capabilities that may act slightly different or serve a specific purpose- like a share link that only works for a week, or a share link that's upload only, etc.
Why is all this important? Because understanding the theory will help you understand the possibilities, and also the possible flaws.
Am happy to discuss further.
So you'd need to have a way to bind a capability to a sender, which naturally leads to PK, or treat them as short lived tokens you revoke as soon as you see they've leaked, which is identical to throwaway email addresses we already have.
They do if the entity doing the transfer is the issuing entity.
I'm not sure what you mean here.
For example, if Alice sends a token to Bob giving Bob a capability, Alice can sign it with her private key and Bob's public key, such that if Bob (or anyone else) wants to use that capability, they have to have Bob's private key to do so.
I don't see any reason we need keys here.
One of the more complex aspects of OCAPy design vs the we do things now is that in a fully ocap world, the token wouldn't just be a string, but possibly a reference to a living object that Alice owns.
Then the trade (and any use of the capability) always goes through Alice.
That's why you don't need crypto in a real OCAP world.
(1) I'm talking to someone on the phone and I want to give them my "email address". What would this look like?
(2) I sell canned soup in a store and want to put something on the can. What would this look like? (possible a QR code with an identity and a stamp?)
(3) How would you go setting up a "mail list" for a club with minimal friction, especially if everyone doesn't have their phone with them.
I do think, however, that use case of receiving mail from strangers is a much bigger case and can't be handwaved away.
I was thinking of something similar lately, coming at it from the social networks angle. I was thinking about personas in social network setting (what google+ attempted with circles), ownership of your data and social links, and the thought process led me to something very similar to what OP is describing.
It sounds like it would be in governments best interest to control this, so they can inject their own fake identities, much like they do with spies now.
Also, how does one revoke ones identity if one loses control of it. I mean, identity theft is common currently?
Eventually the identity registry will be decentralized, choosing the right blockchain is the tricky part.
E.g. spam/scam can be avoided by SPF (https://en.wikipedia.org/wiki/Sender_Policy_Framework),
identity verification and encpryption is solved by https://en.wikipedia.org/wiki/S/MIME.
Case in point: 90%+ of my spam is currently delivered by google. Either using fake accounts and/or hacked ones.
That spam passes _all_ the technical solutions we have put in place today: SPF/DKIM/DMARC. Sure, the SMTP protocol isn't that great in today's light, but you think changing the protocol would solve it?
Say hello to whatsapp spam, facebook's messenger spam, and so on...
The main issue is that email is designed to accept messages from strangers you don't know. Because you want that, and it's a core feature. You will have spam on any network where there this is possible.
If you remove the ability to being contacted from strangers, then email would stop being useful.
You don't even need to change the protocol if you wanted zero spam.
I have one email address where I accept only PGP-signed messages I trust with my known keychain, and discard everything else. I can publish this address anywhere. No spam gets through. There are a couple of other ways you could do this with fancy header tagging if you really wanted to, it's besides the point. The issue goes away as soon as you ignore the first contact problem.
Over past 6 or 7 years I have been using Google I remember only one case when valid mail was classified as spam. I receive about 10-20 spam a day and I get about one spam into my inbox per month.
In the past I would use catch all on my domain and give addresses like adobe.com@<my-domain> to companies.
It led to some fun stories like when I started getting a lot of spam to adobe.com@<my-domain> and Adobe support (I have been paying customer -- no more) claiming that they have absolutely not lost any of my information even though I could positively verify my adobe.com@<my-domain> address and password was available in one of publicly available databases.
Nowadays I am using more and more SSO + MFA and it kind of makes that pattern less useful.
What if sending a mail required a proof of work (the digital equivalent of a stamp)? Then sending mail in bulk would be costly enough to lessen the spate of spam. Unstamped mail would be spam unless the recipient agreed to accept it without the stamp. Legal bulk mail senders could obtain stamps in bulk providing they agree to abide by the rules (no tracking, easy unsubscribe etc.) and provide proof of doing so.
By allowing unstamped mail to be delivered, yet be contingent on the receipients choice, I think we can deal with older clients that can't be updated, noble causes etc.
Feedback welcome.
[1] https://www.dallasnews.com/business/technology/2021/09/28/do...
Privacy is the primary attraction of instant messaging. End to end encryption is OK but most users don't really need it and it tends to complicate operations.
Fixing the privacy issue doesn't require any changes to protocol or email clients. The solution is really just a configurable email forwarding service.
Every user should have both a public email address used for sending and a private email address used for receiving. The mail server automatically replaces the private address with the public address on all outgoing mail.
Received mail gets forwarded from public to private only if it meets certain rules setup on the mail server. Otherwise, the address is rejected as unknown.
A simple rule set would be a list of allowed addresses. If an address is not on the list, it gets rejected. Addresses are automatically added to the allow list by sending an outbound message to the recipient's address OR by sending a coded message to the mail server. Likewise, an address can be deleted from the list by sending a coded message to the mail server. If you actually want email from anyone, don't apply any rules.
What does a "coded message" look like? How about one addressed to the target but with an empty body and either "!ADD" or "!DEL" as the subject?
I have considered building this myself on occasion but all the reputation machinations currently in place that attempt but largely fail to address the spam problem act as a deterrent.
To solve it, I'd say a protocol extension is needed.
In the ideal case, you could have a certificate authority and everyone's email gets signed. Spam and get your cert revoked globally.
That would be hard to pull off though.
To solve it, I'd say a protocol extension is needed.
Or maybe a protocol reduction.
The relay system is the source of lots of evil and was really designed for a bygone era. Eliminate "open" relays --- only accept email directly from the source server --- and most spam goes away with a simple privacy filter as I described above. It is easy to "spoof" an address, much harder to "spoof" a server.