From 0505fde180e65a898a96acb5e149fc176d2a60e6 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Sun, 12 Apr 2020 12:08:03 +0300 Subject: Change: rename email essay draft, drop obsolete draft --- email2-v2-draft.md | 371 ---------------------------------------------------- email2.md | 351 ------------------------------------------------- rethinking-email.md | 371 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 371 insertions(+), 722 deletions(-) delete mode 100644 email2-v2-draft.md delete mode 100644 email2.md create mode 100644 rethinking-email.md diff --git a/email2-v2-draft.md b/email2-v2-draft.md deleted file mode 100644 index bddd818..0000000 --- a/email2-v2-draft.md +++ /dev/null @@ -1,371 +0,0 @@ -Introduction -============================================================================= - -I am tired of the existing Internet email system, both as a sender of -email, as a recipient, and as an operator of an email server. - -There's spam, scam, and the email system is getting centralised in all -sorts of bad ways. This essay is about sketching what a good email -system would look like, if it were re-designed from scratch, using -everything we've learnt over the decades, and not necessarily using any -part of the existing system. - -As an anecdote, I am currently not on any active email discussion lists, -or groups, or subscribed to newsletters. I have a separate email address -that I give to online shops as contact information. My main address has -been used for free and open source software contribution for many years. - -I get less than two valid emails a day, usually from friends. Also, a -small number of notification emails from my own automated systems. I get -on the order of 400 spam and scam emails a day. They vary greatly in how -targeted they are. They are all unsolicited and unwelcome. -Unfortunately, despite honing my email filters for decades now, -sometimes a valid email from a new sender ends up being filtered as -spam, and I'm at risk of missing it. - -Sometimes those emails are important, such as questions about some of my -contributions. If I didn't skim my spam folder manually I would've -missed the email about some of my software being used in Africa to -provide local people with useful SMS services that would've been -financially impossible with proprietary software. - -There are good aspects the existing Internet email has that are still -valuable enough that I continue to use it. I am, however, getting closer -to the point that I'd like to make things radically better. - -This essay collects my thoughts about email and what a replacement -system might look like. I am not in a position to build the new system, -but I can at least try to inspire more people to think about this and -maybe the discussion will end up with something good. - - -Good aspects to keep ------------------------------------------------------------------------------ - -I find the following aspects of the current email system good and -valuable and would like a new system to retain them. - -* Ubiquitous. Approximately everyone on the Internet has email, or can - get it. - -* Anyone can email anyone. This lowers barriers for communication, - globally. It's especially important for free and open source software - projects, but also to allow people all over the world to easily - self-organise to build a better world in general. - -* Distributed: sender and recipient don't need to use the same server. - Anyone can set up their own server, assuming time, know-how, and a - little money. - -* Standardised: there are many implementations and they're mostly - inter-operable. - -* Supports off-line use. Not everyone can, or wants to, be online all - the time. - - -Problems with the existing email system ------------------------------------------------------------------------------ - -* Spam, or unsolicited bulk messages. Worse, anti-spam measures drive - centralisation, and are still ineffective, especially for those not - using one of the huge centralised providers. End result: you either - sacrifice privacy or you get tons of spam. - - - Spam is a result of the desirable feature that anyone can email - anyone, combined with the fact that sending an email costs - approximately nothing, even if you send millions of emails, and - aggravated by the fact that spamming has de facto no real financial - or legal repercussions. - -* Scam, or trying to convince people to do something that they shouldn't - or that's harmful to them or others. There is no widely used method to - digitally sign email, and thus criminals can easily fake messages to - look like they come from, say, Amazon, Netflix, Paypal, or other - companies the recipient is likely to use. Everyone needs to be - constantly on their toes to avoid mistakes. - - - There are standards for digitally signed email, but they're not - great, and the big providers of email software or service tend not - to support them, or support them badly. - -* Becoming centralised to a few huge providers. This is bad for - privacy and can be catastrophic for security. If one of the big - providers gets breached, up to hundreds of millions of people's - communications are at risk. - - - We're moving towards a future where hosting email yourself makes you - suspicious. It's already the case that it can be difficult for a - self-hosted email server to reach people on Gmail. - - - Worse, all the big email service providers have track records of - closing people's accounts with no warning. Sometimes this happens by - accident, sometimes due to nefarious policies. - -* No real privacy, even if you self-host. Email is by default in - clear text, and while there are standards for encryption, they are - not widely used, and tend to also leave metadata (headers) - unencrypted. It's difficult to hide who is sending email to whom. - -* HTML email is not well standardised, and is a security and privacy - risk. Different email clients implement HTML in different ways, and - the web standards are not followed very closely. - - - Worse, there's an assumption that HTML emails can embed images - from the Internet, which results in more security problems (images - are complicated data provided by a potential attacker, and just - viewing them is a security risk) and privacy issues (the image - hoster will be notified when you view the email, see tracking - pixels). - - There are moves to restrict this, but the problems have been known - since HTML email was introduced, and the problems continue to exist. - Some problems (such as embedding remote images) have gotten at least - partial solutions, but the problems shouldn't exist at all. - -* Attachments fill disks. Email is commonly used to share files, - because it's easy and ubiquitous, even if it's not very good at it. - There are services that make this better, but they are mostly - proprietary, and require extra effort, are not ubiquitous, and people - mostly don't use them routinely. - -* There is no good support for group discussions. Massive dumps of - forwarded discussions are commonplace in most large organisations. - Mailing list managers exist, but they tend to be clunky, and tend to - not be great for having discussions among large groups of people. - They're better at sending out announcements and newsletters. - - - Email threads work, technically, but tend to result in surprisingly - little communication happening, in the general case. People mix - topics in threads, split the same topic into new threads, and - generally don't use threads as intended. This is not the fault of - people, but the technology. - -* The technologies and standards for email are getting ridiculously - complicated. Email was originally designed for relatively short - messages in English only. To support non-English languages in a - backwards compatible manner, email has gained whole extended - families of ways to encode text and data: uuencode, base64, - quoted-printable, and header encoding, to start with. - - The email tech stack is getting so hard to understand that it's - difficult to even use, never mind implement correctly. Never mind - that the complexity results in more effort to operate and keep - the servers secure. - - -The spam and scam problem -============================================================================= - -There are a large number of problems. Rather than attacking all of them -at once, let's consider them one at a time, and let's start with the -most obvious problem: spam. As a side effect, the solution proposed -below should also solve the scam problem. - - -Problem statement ------------------------------------------------------------------------------ - -The spam problem can be stated as follows: - -> Anyone can send email to anyone else. There is practically no cost to -> sending many emails. It's difficult for the recipients to filter -> unwanted mail away automatically, because it would require the -> computer to understand human communication as well as humans. - -The scam problem can be stated as follows: - -> Anyone can send email that looks like it comes from someone else, at -> least sufficiently well that an unobservant recipient is fooled. This -> can be used to con the recipient to click a link in the email that -> leads to a fake web shop, for example, or a site that attacks the -> recipient with malware. - - -Overview of solution ------------------------------------------------------------------------------ - -* Every email user has one or more identities, represented by - cryptographic keys. - -* All email is digitally signed using the cryptographic keys. - -* No email is delivered unless it carries a digital stamp issued by the - recipient, or someone authorised to issue one on behalf of the - recipient. - -The idea for stamps comes to me from [@fedispam], who seems to have -gotten it from Christopher Lemmer Webber and Taler, and who knows where -it originated from. - - -Digital identities ------------------------------------------------------------------------------ - -In this approach, each email user can have as many email identities as -they want, and each identity is represented by a key pair for public key -cryptography. The identities are not necessarily linked, just like -personal and work email addresses are not linked. - -The key pair, consisting of a public and a private key, is used to -identify the email account and messages from the account. Every message -sent using an identity is signed with the key for that identity. - -This means misrepresenting the sender becomes much harder, reducing the -possibility for scam. - -Each identity (key pair) can have metadata associated with it, such as a -name. There can be digital signatures for the metadata for certifying -it, to avoid miscreants faking identities by creating new keys and -associating someone else's name on them. With the metadata signatures, -the recipient's email software can at least attempt to verify -correctness of the metadata. - -Alternatively, names are handled only on the recipient's side. If I get -a message from you, and I'm sure it's from you, I can tell my email -address book that the key you used to sign the message should have your -name. If a miscreant creates a new key, my email software won't say it's -from you, and the miscreant has to convince me that it's you. (This -needs further thought.) - - -Digital signatures ------------------------------------------------------------------------------ - -For the purposes of this discussion, assume a way to digitally sign -messages that covers the whole message, including its metadata. The -details of how that is achieved do not matter: digital signatures have -well-known, good solutions and since we are talking about a new system, -we don't have to be compatible with the problems of the existing email -system. - -For this discussion, assume each message can be securely verified as -having been sent by its sender identity. If a message claims to be from -an identity, but its signature can't be verified, the message is -rejected by the recipient's email software. - - -On encryption ------------------------------------------------------------------------------ - -To solve the problem of surveillance, email encryption is going to be -needed. However, it doesn't seem to be necessary for solving the spam -and scam problem, so it's not discussed, for now. A future version of -this essay may address that. - - -Digital stamps ------------------------------------------------------------------------------ - -A digital stamp is a digital token issued by a recipient which gives a -sender the capability to send one or more messages to the recipient. - -A digital stamp is more powerful than a physical, paper stamp. Paper -stamps can be transferred (sold, given) without limit. A digital stamp, -however, allows more features: - -* only the recipient can decide if it's still valid: the recipient can - invalidate otherwise valid stamps - -* digital stamps can have a complicated validity time: perhaps - they're only valid for three months? or only on Mondays? or only - during office hours? - -* digital stamps may be indefinitely usable, or single-use: you might - give someone new a stamp they can use only once, and if you don't give - them another, longer-lived stamp, you won't get further email from - them - - - for example, I might order a mug from an online shop and give them - two single-use stamps: one for sending me the order confirmation and - another for sending me a notification of shipment - -* digital stamps may be valid only for a specific sender: I might issue - a stamp to a shop and if they sell my contact information to a - spammer, the spammer can't use the stamp to send me email; further, I - will know the shop gave the stamp to the spammer - -As an extra twist, digital stamps may also be an authorisation to -someone else to issue stamps on your behalf. Rather than the stamp -allowing them to send you an email, it lets them create a stamp that -lets a third party send you an email. Your email software can put any -and all the constraints it puts on stamps you issue directly on the -delegation. - -For example, if you and Alfred have a mutual friend, Bruce, you can give -Bruce a stamp that authorises Bruce to issue single-use stamps to other -identities. If Bruce thinks you and Alfred should know each other, Bruce -can issue Alfred a stamp that lets Alfred send you a single email. If -you like Alfred, you can issue further stamps to Alfred. - -An employer runs their own email server, and that server determines -which stamps it accepts. This lets an employer issue stamps on behalf of -each of their employees. - -Email servers could also, if so configured, issue stamps to senders -with no previous connection to the recipient. This might be done by the -sender having to produce some proof of work, which can be made -arbitrarily costly in terms of computing resources. For example, the -proof of work might require using five seconds of CPU time. This is -costly enough that it makes large-scale spamming infeasible. (See -[@hashcash] for an early suggestion.) - -This makes the stamp system vulnerable to attackers who have enormous -amounts of computing power, perhaps by using a botnet. It would be -good to replace proof-of-work with something that's not vulnerable to -a botnet. - -Alternatively, the email server could require the person sending the -email to solve a [CAPTCHA][]-like puzzle, which can be made -sufficiently varied to make it difficult to solve automatically. The -actual puzzle does not need be standardized, only the mechanism by -which the user is pointed at it, and how the result is communicated -back to the mail server. There could, and should, be a very large -number of different puzzles. - -[CAPTCHA]: https://en.wikipedia.org/wiki/CAPTCHA - -Email servers could also sell stamps for real money. Even at trivial -costs, such as one US/EURO cent, this would be too costly for spammers. - -I emphasise that the recipient decides what stamps are valid. Their mail -server does not have to issue stamps to anyone who asks, if the -recipient doesn't want email from strangers. - -What next? -============================================================================= - -Do you think the solution proposed in this essay for spam and scam will -help? If not, why not? Can you see a way for a miscreant to circumvent -the proposed solution to get their unwanted message delivered to the -recipient? - -Let me know, preferably via the legacy email system, as a response to -this [fediverse thread][], or using the [GitLab issue system][]. If -you want to propose improvements to the essay, feel free to file a -merge request or send patches. - -[GitLab issue system]: https://gitlab.com/larswirzenius/ideas/-/issues - - - -References -============================================================================= - - ---- -title: "Re-thinking electronic mail" -author: Lars Wirzenius -abstract: | - There are many problems with the existing Internet email system, - such as spam, scam, surveillance, insecurity, centralisation, and - complexity. The problems are starting to outweigh - the benefits of the system. Fixing the problems by evolving the - current system seems overwhelmingly difficult. This essay examines - some solutions to the problems on the assumption that a completely - new, parallel email system can be built. - - This is not a proposal for a new system, but an exploration of the - solution space, meant to provoke constructive discussion. -bibliography: email.bib -... diff --git a/email2.md b/email2.md deleted file mode 100644 index c807871..0000000 --- a/email2.md +++ /dev/null @@ -1,351 +0,0 @@ ---- -title: Reinventing electronic mail -... - -Introduction -============================================================================= - -I am fed up with the existing Internet email system. There's spam, and -the email system is -getting centralised in all sorts of bad ways. This idea is about -sketching what a good email system would look like, if it were -re-designed from scratch, using everything we've learnt over the -decades, and not necessarily using any part of the existing system. - -Good aspects ------------------------------------------------------------------------------ - -* Ubiquitous. Approximately everyone on the Internet has email, or can - get it. - -* Anyone can email anyone. This lowers barriers for communication, - globally. It's especially important for free and open source - projects, but also to allow people all over the world to - easily self-organise to build a better world in general. - -* Distributed: sender and recipient don't need to use the same server. - -* Standardised, with many (many!) inter-operable implementations. - -* Supports off-line use. Not everyone can, or wants to, be online all - the time. - - -Problems with the existing email system ------------------------------------------------------------------------------ - -* Spam. Worse, anti-spamming measures drive centralisation, and are - still ineffective, especially for those not using the huge - providers. End result: you either sacrifice privacy or you get tons - of spam. - - - This is a result of the desirable feature that anyone can email - anyone, combined with the fact that sending an email costs - approximately nothing, and that sending a million email also costs - approximately nothing, and aggravated by the fact that spamming - has de facto no real financial or legal repercussions. - -* Scam. There is no widely used method to digitally sign email, and - thus criminals can easily fake messages to look like they come from, - say, Amazon, Netflix, Paypal, or other companies the recipient is - likely to use. Everyone needs to be constantly on their toes to - avoid mistakes. - - - There are standards for digitally signed email, but - -* Becoming centralised to a few huge providers. This is bad for - privacy and can be catastrophic for security. If one of the big - providers gets breached, up to hundreds of millions of people's - communications are at risk. - - - We're moving towards a future where if you host email yourself, - you're suspicious. It's already the case that it can be difficult - for a self-hosted email server to reach people on Gmail. - -* No real privacy, even if you self-host. Email is by default in - clear text, and while there are standards for encryption, they are - not widely used, and tend to also leave metadata (headers) - unencrypted. - -* HTML email is not well standardised, and is a security and privacy - risk. Different email clients implement HTML in different ways, and - the web standards are not followed very closely. - - - Worse, there's an assumption that HTML emails can embed images - from the Internet, which results in more security problems (images - are complicated data provided by a potential attacker, and just - viewing them is a security risk), and privacy issues (the image - hoster will be notified when you view the email, see tracking - pixels). - - There are moves to restrict this, but the problems have been known - since soon after HTML email was introduced, and at least some of - the problems still exist. - -* Attachments fill disks. Email is commonly used to share files, - because it's easy and ubiquitous, even if it's not very good at it. - There are services that make this better, but they are mostly - proprietary, and require extra effort. - -* There is no good support for group discussions. Massive dumps of - forwarded discussions are commonplace in most large organisations. - Mailing list managers exist, but they tend to be clunky, and tend to - not be great for having discussions among large groups of people. - They're better at sending out announcements and newsletters. - -* The technologies and standards for email are getting ridiculously - complicated. Email was originally designed for relatively short - messages in English only. To support non-English languages in a - backwards compatible manner, email has gained whole extended - families of ways to encode text and data: uuencode, base64, - quoted-printable, and header encoding, to start with. - - The email tech stack is getting so hard to understand that it's - difficult to even use, never mind implement correctly. Never mind - that the complexity results in more effort to operate and keep - secure the servers. - - -Possible solutions -============================================================================= - -This document tries to outline a possible solution to all the problems -above. - - -Overview ------------------------------------------------------------------------------ - -The shape of a possible solution might be something like this: - -* everyone has any number of "email identities", which are roughly - like email addresses; it's easy to create new identities, and to - optionally link them together; each identity has cryptographic keys - for encryption and digital signatures - -* all email is encrypted to the recipient(s), and signed by the sending - identity - - -Spam ------------------------------------------------------------------------------ - -Spam, or unsolicited bulk email, is probably the first problem to -solve, as the solution will likely constrain other aspects of the -system. - -The reason current email has a spam problem is three-fold: - -* anyone can send email to anyone -* sending any amount of email is basically free of cost -* there are no real consequences from sending unwanted email, except - for the sender's reputation - -What we want from the solution: - -* anyone can send email to anyone who wants to receive it -* sending email should be basically free of cost, if the recipient - wants it -* sending email without prior arrangement does not need to be free of - cost - -A possible solution might be a kind of digital stamps. - -* Alice can give Bob a stamp to allow Bob to send email to Alice -* Alice can give her friends permission to give out stamps on her - behalf, to allow friends to introduce new people to Alice - - as a variation, Alice might give permission to her employer to - give out stamps on her behalf to co-workers -* If Bob doesn't have a stamp, but still wants to reach Alice, his - email software can ask Alice's server for one, and this can be made - "costly" in some way so that it's hard for spammers to automate - -When Bob sends an email to Alice, the email will come with a stamp to -allow Alice's response to reach Bob. - - -Stamps ------------------------------------------------------------------------------ - -Digital stamps are not exactly like paper stamps. Paper stamps cost -money, and can only be used once. A digital stamp can be more -versatile: - -* might be used any number of times, or only once -* might be valid indefinitely, or only for a specific time span -* might be valid for any sender, or only for a specific sender, or - require specific keywords in the email, or have other filtering - rules -* might not allow sending an email, but instead might delegate the - power to issue stamps to someone else; the delegation might - constrain the kind of stamps the delegate can issue -* might be cancelled by its issuer at any time - -Stamps can be created manually via the mail user interface, -automatically when sending email, or when joining a mailing list or -signing up for a service. - -The format of stamps is open, for now. However, they should probably -be compact enough that they can easily be communicated manually. QR -codes might be useful. - - -Generating stamps to reach someone else ------------------------------------------------------------------------------ - -Each email server can issue stamps for an identity hosted on the -server, if the identity has delegated the server that power. This -would probably be a web service provided by the server to someone -requesting a stamp. - -* stamp issuing might be rate limited - per server, or per group of - collaborating server; possibly a group based on the social graph of - the issuer - -* the requester might need to do some work to raise the cost of - stamps: solve a cryptographic puzzle, or do some similar task; this - would be easy enough that it's not expensive enough if it happens - occasionally, but enough that it stops spammers from doing it en - masse - - - -Signing up for newsletters and services ------------------------------------------------------------------------------ - -Currently, the operator of a newsletter can add any email addresses to -their mailing list. It's more of a convention than a technical -requirement that the recipient must confirm they want the newsletter. -This is abused often by the less scrupulous operators. - -With the stamp model, the recipient would create a stamp (possibly -single-use, or limited to a time period) and provide it to the -operator to be added to the mailing list. The recipient can get off -the mailing list by cancelling the stamp. The mailing list doesn't -need to even have an unsubscription feature. Without a valid stamp, -the newsletter doesn't reach the recipient. Rejecting a stampless -message can be made cheap enough that it's not a problem. - -Likewise, when using a service (buying tickets to an event? flights? -stuff from an online shop?) that may need to send a message, the -customer would provide the service with a stamp for such information -messages. Such a stamp might be time-limited, and might delegate the -power to, say, issue additional stamps to a third party necessary for -providing the service (e.g., Amazon might issue stamps to the courier -to let them reach the customer). - - -Email identities ------------------------------------------------------------------------------ - -An email identity is not an address. Email addresses are tied to -locations (servers, domains). This makes it difficult to move one's -email to another location. - -An identity in the new system is a large randomly generated number -(UUID4). Routing messages is an unsolved problem. - -Each user can have any number of identities they like. - -To an identity some metadata is attached: - -* one or more names -* for each name, zero or more certificates from other identities -* zero or more other identities for the same person (optional) - - FIXME: give rationale for this -* one or more public key pairs for encryption, certificates, - authentication - -Each message is signed by at least one certification key of the -sender, and encrypted with every public key of every recipient. - - -Names ------------------------------------------------------------------------------ - -All names attached to an identity are decided by the identity's owner. -Others can certify that they believe the identity and name belong -together. This is similar to the Secure Scuttlebutt pet name system. - - - -FIXME -============================================================================= - -All of this needs to be thought about. - - -Routing messages ------------------------------------------------------------------------------ - -FIXME: this needs to be solved in some way. The SSB approach probably -doesn't scale. - - -Message format ----------------------------------------------------------------------------- - -FIXME: this needs to be sketched. For now, assume something that's -roughly on par with RFC2822, but with simplicity. Possibly JSON. - - -Group discussions, mailing lists, signing up for services ------------------------------------------------------------------- - -FIXME: this needs to be sketched. - - -Withdrawing or removing sent messages ------------------------------------------------------------------------------ - -Remove sent messages? At least to groups? - - -Encryption ----------------------------------------------------------------------------- - -Allow rotation of keys. Allow multiple keys per identity, at least one -per device. Allow future versions to change encryption algos etc. - -Perfect forward security? - -Revoke sent message? - - -Mobile as a first class citizen ------------------------------------------------------------------------------ - -About half the people using the Internet now are using mobile only. A -new email system should take that into account. - -That said, desktop/laptop computers are still hugely important and -can't be neglected. - -Ideally it would be easy to implement the client software in any -platform, to allow maximum diversity. - - -Specifications, conformance ------------------------------------------------------------------------------ - -All aspects of protocols and messages should be specified in -sufficient detail and clarity to allow independent, inter-operable -implementations. There should probably be a common test suite for -conformance, and some dedicated interoperability testing. - - - -SEE ALSO -============================================================================= - -Links to more information, sources, etc. - -* Preventing spam on the Fediverse. Serge Wroclawski. Suggests - stamps. Idea via Christopher Lemmer Webber from Taler, and it might - not have originated there. - - - - - -* Hashcash is a system where the sender proves they do some work - before the recipient accepts a message. - - http://hashcash.org/ diff --git a/rethinking-email.md b/rethinking-email.md new file mode 100644 index 0000000..bddd818 --- /dev/null +++ b/rethinking-email.md @@ -0,0 +1,371 @@ +Introduction +============================================================================= + +I am tired of the existing Internet email system, both as a sender of +email, as a recipient, and as an operator of an email server. + +There's spam, scam, and the email system is getting centralised in all +sorts of bad ways. This essay is about sketching what a good email +system would look like, if it were re-designed from scratch, using +everything we've learnt over the decades, and not necessarily using any +part of the existing system. + +As an anecdote, I am currently not on any active email discussion lists, +or groups, or subscribed to newsletters. I have a separate email address +that I give to online shops as contact information. My main address has +been used for free and open source software contribution for many years. + +I get less than two valid emails a day, usually from friends. Also, a +small number of notification emails from my own automated systems. I get +on the order of 400 spam and scam emails a day. They vary greatly in how +targeted they are. They are all unsolicited and unwelcome. +Unfortunately, despite honing my email filters for decades now, +sometimes a valid email from a new sender ends up being filtered as +spam, and I'm at risk of missing it. + +Sometimes those emails are important, such as questions about some of my +contributions. If I didn't skim my spam folder manually I would've +missed the email about some of my software being used in Africa to +provide local people with useful SMS services that would've been +financially impossible with proprietary software. + +There are good aspects the existing Internet email has that are still +valuable enough that I continue to use it. I am, however, getting closer +to the point that I'd like to make things radically better. + +This essay collects my thoughts about email and what a replacement +system might look like. I am not in a position to build the new system, +but I can at least try to inspire more people to think about this and +maybe the discussion will end up with something good. + + +Good aspects to keep +----------------------------------------------------------------------------- + +I find the following aspects of the current email system good and +valuable and would like a new system to retain them. + +* Ubiquitous. Approximately everyone on the Internet has email, or can + get it. + +* Anyone can email anyone. This lowers barriers for communication, + globally. It's especially important for free and open source software + projects, but also to allow people all over the world to easily + self-organise to build a better world in general. + +* Distributed: sender and recipient don't need to use the same server. + Anyone can set up their own server, assuming time, know-how, and a + little money. + +* Standardised: there are many implementations and they're mostly + inter-operable. + +* Supports off-line use. Not everyone can, or wants to, be online all + the time. + + +Problems with the existing email system +----------------------------------------------------------------------------- + +* Spam, or unsolicited bulk messages. Worse, anti-spam measures drive + centralisation, and are still ineffective, especially for those not + using one of the huge centralised providers. End result: you either + sacrifice privacy or you get tons of spam. + + - Spam is a result of the desirable feature that anyone can email + anyone, combined with the fact that sending an email costs + approximately nothing, even if you send millions of emails, and + aggravated by the fact that spamming has de facto no real financial + or legal repercussions. + +* Scam, or trying to convince people to do something that they shouldn't + or that's harmful to them or others. There is no widely used method to + digitally sign email, and thus criminals can easily fake messages to + look like they come from, say, Amazon, Netflix, Paypal, or other + companies the recipient is likely to use. Everyone needs to be + constantly on their toes to avoid mistakes. + + - There are standards for digitally signed email, but they're not + great, and the big providers of email software or service tend not + to support them, or support them badly. + +* Becoming centralised to a few huge providers. This is bad for + privacy and can be catastrophic for security. If one of the big + providers gets breached, up to hundreds of millions of people's + communications are at risk. + + - We're moving towards a future where hosting email yourself makes you + suspicious. It's already the case that it can be difficult for a + self-hosted email server to reach people on Gmail. + + - Worse, all the big email service providers have track records of + closing people's accounts with no warning. Sometimes this happens by + accident, sometimes due to nefarious policies. + +* No real privacy, even if you self-host. Email is by default in + clear text, and while there are standards for encryption, they are + not widely used, and tend to also leave metadata (headers) + unencrypted. It's difficult to hide who is sending email to whom. + +* HTML email is not well standardised, and is a security and privacy + risk. Different email clients implement HTML in different ways, and + the web standards are not followed very closely. + + - Worse, there's an assumption that HTML emails can embed images + from the Internet, which results in more security problems (images + are complicated data provided by a potential attacker, and just + viewing them is a security risk) and privacy issues (the image + hoster will be notified when you view the email, see tracking + pixels). + + There are moves to restrict this, but the problems have been known + since HTML email was introduced, and the problems continue to exist. + Some problems (such as embedding remote images) have gotten at least + partial solutions, but the problems shouldn't exist at all. + +* Attachments fill disks. Email is commonly used to share files, + because it's easy and ubiquitous, even if it's not very good at it. + There are services that make this better, but they are mostly + proprietary, and require extra effort, are not ubiquitous, and people + mostly don't use them routinely. + +* There is no good support for group discussions. Massive dumps of + forwarded discussions are commonplace in most large organisations. + Mailing list managers exist, but they tend to be clunky, and tend to + not be great for having discussions among large groups of people. + They're better at sending out announcements and newsletters. + + - Email threads work, technically, but tend to result in surprisingly + little communication happening, in the general case. People mix + topics in threads, split the same topic into new threads, and + generally don't use threads as intended. This is not the fault of + people, but the technology. + +* The technologies and standards for email are getting ridiculously + complicated. Email was originally designed for relatively short + messages in English only. To support non-English languages in a + backwards compatible manner, email has gained whole extended + families of ways to encode text and data: uuencode, base64, + quoted-printable, and header encoding, to start with. + + The email tech stack is getting so hard to understand that it's + difficult to even use, never mind implement correctly. Never mind + that the complexity results in more effort to operate and keep + the servers secure. + + +The spam and scam problem +============================================================================= + +There are a large number of problems. Rather than attacking all of them +at once, let's consider them one at a time, and let's start with the +most obvious problem: spam. As a side effect, the solution proposed +below should also solve the scam problem. + + +Problem statement +----------------------------------------------------------------------------- + +The spam problem can be stated as follows: + +> Anyone can send email to anyone else. There is practically no cost to +> sending many emails. It's difficult for the recipients to filter +> unwanted mail away automatically, because it would require the +> computer to understand human communication as well as humans. + +The scam problem can be stated as follows: + +> Anyone can send email that looks like it comes from someone else, at +> least sufficiently well that an unobservant recipient is fooled. This +> can be used to con the recipient to click a link in the email that +> leads to a fake web shop, for example, or a site that attacks the +> recipient with malware. + + +Overview of solution +----------------------------------------------------------------------------- + +* Every email user has one or more identities, represented by + cryptographic keys. + +* All email is digitally signed using the cryptographic keys. + +* No email is delivered unless it carries a digital stamp issued by the + recipient, or someone authorised to issue one on behalf of the + recipient. + +The idea for stamps comes to me from [@fedispam], who seems to have +gotten it from Christopher Lemmer Webber and Taler, and who knows where +it originated from. + + +Digital identities +----------------------------------------------------------------------------- + +In this approach, each email user can have as many email identities as +they want, and each identity is represented by a key pair for public key +cryptography. The identities are not necessarily linked, just like +personal and work email addresses are not linked. + +The key pair, consisting of a public and a private key, is used to +identify the email account and messages from the account. Every message +sent using an identity is signed with the key for that identity. + +This means misrepresenting the sender becomes much harder, reducing the +possibility for scam. + +Each identity (key pair) can have metadata associated with it, such as a +name. There can be digital signatures for the metadata for certifying +it, to avoid miscreants faking identities by creating new keys and +associating someone else's name on them. With the metadata signatures, +the recipient's email software can at least attempt to verify +correctness of the metadata. + +Alternatively, names are handled only on the recipient's side. If I get +a message from you, and I'm sure it's from you, I can tell my email +address book that the key you used to sign the message should have your +name. If a miscreant creates a new key, my email software won't say it's +from you, and the miscreant has to convince me that it's you. (This +needs further thought.) + + +Digital signatures +----------------------------------------------------------------------------- + +For the purposes of this discussion, assume a way to digitally sign +messages that covers the whole message, including its metadata. The +details of how that is achieved do not matter: digital signatures have +well-known, good solutions and since we are talking about a new system, +we don't have to be compatible with the problems of the existing email +system. + +For this discussion, assume each message can be securely verified as +having been sent by its sender identity. If a message claims to be from +an identity, but its signature can't be verified, the message is +rejected by the recipient's email software. + + +On encryption +----------------------------------------------------------------------------- + +To solve the problem of surveillance, email encryption is going to be +needed. However, it doesn't seem to be necessary for solving the spam +and scam problem, so it's not discussed, for now. A future version of +this essay may address that. + + +Digital stamps +----------------------------------------------------------------------------- + +A digital stamp is a digital token issued by a recipient which gives a +sender the capability to send one or more messages to the recipient. + +A digital stamp is more powerful than a physical, paper stamp. Paper +stamps can be transferred (sold, given) without limit. A digital stamp, +however, allows more features: + +* only the recipient can decide if it's still valid: the recipient can + invalidate otherwise valid stamps + +* digital stamps can have a complicated validity time: perhaps + they're only valid for three months? or only on Mondays? or only + during office hours? + +* digital stamps may be indefinitely usable, or single-use: you might + give someone new a stamp they can use only once, and if you don't give + them another, longer-lived stamp, you won't get further email from + them + + - for example, I might order a mug from an online shop and give them + two single-use stamps: one for sending me the order confirmation and + another for sending me a notification of shipment + +* digital stamps may be valid only for a specific sender: I might issue + a stamp to a shop and if they sell my contact information to a + spammer, the spammer can't use the stamp to send me email; further, I + will know the shop gave the stamp to the spammer + +As an extra twist, digital stamps may also be an authorisation to +someone else to issue stamps on your behalf. Rather than the stamp +allowing them to send you an email, it lets them create a stamp that +lets a third party send you an email. Your email software can put any +and all the constraints it puts on stamps you issue directly on the +delegation. + +For example, if you and Alfred have a mutual friend, Bruce, you can give +Bruce a stamp that authorises Bruce to issue single-use stamps to other +identities. If Bruce thinks you and Alfred should know each other, Bruce +can issue Alfred a stamp that lets Alfred send you a single email. If +you like Alfred, you can issue further stamps to Alfred. + +An employer runs their own email server, and that server determines +which stamps it accepts. This lets an employer issue stamps on behalf of +each of their employees. + +Email servers could also, if so configured, issue stamps to senders +with no previous connection to the recipient. This might be done by the +sender having to produce some proof of work, which can be made +arbitrarily costly in terms of computing resources. For example, the +proof of work might require using five seconds of CPU time. This is +costly enough that it makes large-scale spamming infeasible. (See +[@hashcash] for an early suggestion.) + +This makes the stamp system vulnerable to attackers who have enormous +amounts of computing power, perhaps by using a botnet. It would be +good to replace proof-of-work with something that's not vulnerable to +a botnet. + +Alternatively, the email server could require the person sending the +email to solve a [CAPTCHA][]-like puzzle, which can be made +sufficiently varied to make it difficult to solve automatically. The +actual puzzle does not need be standardized, only the mechanism by +which the user is pointed at it, and how the result is communicated +back to the mail server. There could, and should, be a very large +number of different puzzles. + +[CAPTCHA]: https://en.wikipedia.org/wiki/CAPTCHA + +Email servers could also sell stamps for real money. Even at trivial +costs, such as one US/EURO cent, this would be too costly for spammers. + +I emphasise that the recipient decides what stamps are valid. Their mail +server does not have to issue stamps to anyone who asks, if the +recipient doesn't want email from strangers. + +What next? +============================================================================= + +Do you think the solution proposed in this essay for spam and scam will +help? If not, why not? Can you see a way for a miscreant to circumvent +the proposed solution to get their unwanted message delivered to the +recipient? + +Let me know, preferably via the legacy email system, as a response to +this [fediverse thread][], or using the [GitLab issue system][]. If +you want to propose improvements to the essay, feel free to file a +merge request or send patches. + +[GitLab issue system]: https://gitlab.com/larswirzenius/ideas/-/issues + + + +References +============================================================================= + + +--- +title: "Re-thinking electronic mail" +author: Lars Wirzenius +abstract: | + There are many problems with the existing Internet email system, + such as spam, scam, surveillance, insecurity, centralisation, and + complexity. The problems are starting to outweigh + the benefits of the system. Fixing the problems by evolving the + current system seems overwhelmingly difficult. This essay examines + some solutions to the problems on the assumption that a completely + new, parallel email system can be built. + + This is not a proposal for a new system, but an exploration of the + solution space, meant to provoke constructive discussion. +bibliography: email.bib +... -- cgit v1.2.1