I run one of the largest email sending services on the internet. I have been living the “mess” of internet email for over 20 years.
Here’s the thing: despite the internet’s email system being complex and confusing and riddled with problems, it is universally adopted and interoperable. No other open communication tool can boast of email’s massive interoperability.
Any new system will face the impossible burden of winning hearts and minds while the old system continues to chug along with billions of annual R&D spending and dozens of conferences full of smart people working on solving problems.
Even if “MX2” can peacefully coexist in the DNS, why would anyone spend the millions of dollars in engineering effort to move while their teams are busy building the latest layer that’s been invented to patch over the current system?
By all means if you want to propose a new email system, show up at IETF or M3AAWG and make a bold proposal. Someone will buy you a beer while they explain why you are much better off getting into the mud pit with the rest of us and working on the next pragmatic fix to keep things rolling along.
Also, they would school them on actual-world problems in the process:
- You can't wait until you receive the entire body to be able to compute a signature to then validate the sender as your first line of defense. It is just too expensive and opens you to DDOS attacks. People use IP reputation as a first line of defense because it is cheap, not because it is good.
- You cannot enforce people's behavior through RFCs. I can assure you that random guy next desk will not care about your "this is a top-posting-thread" header and bottom post there. Even if she has to manually copy/paste things around.
- Likewise, auto-generated plain-text versions of HTML (or other rich-text formats) are no better than what screen readers can achieve. Most poeple won't bother writing that alternate version, meaning the obligatory alt text is now less useful than when it was optional and only people who cared inculded it.
- Your largest client may not update their e-mail infrastructure to comply with the latest standards. If that happens, you don't tell them to update or otherwise you won't be answering them because their e-mails go to spam. You do whatever is necessary to ensure that their e-mails don't go to spam. Business always comes first.
1. Could a future protocol require an immediate initial message (a “hello”) stating exactly how much content will be sent, and until the “hello” is sent, it’s limited to, say, 128KB before the connection is immediately terminated? (And of course, if the content exceeds the declaration, termination and immediate IP temporary ban, safe to do as this is an obvious violation of a new spec?)
2. The goal is to make it easier for the email client which by itself will encourage good behavior. There’s also no requirement for the messages to all be in one massive blob.
3. The goal is that it would be automatically created by the client. For personal emails, this is easy. For enhanced HTML emails, that is where the requirement comes in. Email providers can come up with their own ways of enforcement from there (I.e. “if it’s only one sentence, you obviously didn’t do it”), though I get your point and that would become messy unofficial spec again.
4. Could a future emails system have versioning, allowing the server to clearly communicate (“Hello, I implement MX2 v3.1.”)? In addition, a business can obviously make their own settings that original email alerts do not go to Junk in their business mailboxes - but they do know they’d better get on it or their messages to clients might go to Junk.
SMTP already has the BDAT command where the size is sent first, and arbitrary bytes can be sent (unlike DATA).
SMTP already has versioning through extensions.
If you're banning an IP for exceeding a processing resource limit please keep the ban short. Presumably you can afford to process the first 128KB of one bad message per six hours, for instance. There should be no need to make a month-long or permanent ban, and these just hurt interoperability if the sender realizes their problem and fixes it, or if the address is reallocated.
Trying to limit data between the hello and the email data is futile, since the attacker can just flood you with random packets no matter whether you told them to stop (closed the connection) or not. You can only limit things you have control over, mostly your own memory usage, and how much data is accepted into more expensive processing stages.
> 128KB of one bad message per six hours, for instance. There should be no need to make a month-long or permanent ban
As someone who saw the actual bruteforce attempts, most bots abandon any attempts after an hour or two. Resources are cheap but even for spammers (almost unlimited resources) futile attempts are costly.
> I can assure you that random guy next desk will not care about your "this is a top-posting-thread" header and bottom post there.
We should move away from having a single mutable body for email. It should be a series of immutable messages that reference the message that it is replying to. Each message can contain a hash signed by the private key for the domain that wrote it. Then when you write your message it just gets appended to this chain.
How it is shown is up to the email client so that it can be done in the best way for the user.
What you’re describing is already possible with email as it is, using the In-Reply-To header or whatever its name was. No need for cryptographic signatures. The only issue is that common mail clients still automatically quote the whole message being replied to for no good reason. It should work like it used to on phpbb forums: no quote by default, quote selected part if text is selected.
> The only issue is that common mail clients still automatically quote the whole message being replied to for no good reason.
Here is a good reason: In-Reply-To is a reference, not content. The recipient(s) of your message might not have that email.
Also including the quote is a default. The sender can edit it, splice responses into it and remove irrelevant parts of it. Admittedly quoting norms are in shambles though for various reasons.
> Each message can contain a hash signed by the private key for the domain that wrote it.
Me being able to prove that I wrote something is good. Other people being able to prove that I wrote something… it's good under many circumstances, but not in general.
We do it like Hacker News. It's just another message, with > indicators. Globally, inline replies are A. Rare and B. Often used with prank intent (i.e. you can make it look like you're replying to something they didn't say).
I run several of the smallest email sending services on the internet. Been doing it for 26 years or so.
{rest of your comment ... verbatim!}
Email doesn't need fixing or a v2. I've run GroupWise, Exchange, Lotus (various flavours but never peppermint) and others too. For me, for little systems: Dovecot (IMAP) + Exim (MTA) is a golden combo.
Email_v1 itself is just complicated enough without being too funky. You bolt on TLS/SSL and the rest. MX records are a simplified form of SRV records (I think MX came first but the point holds) and remove the requirement for gateway load balancers and clustering technologies if you don't want to do all that stuff.
Nothing is perfect but email does deliver a lot more significant messages than any other method from before or since its inception.
If email didn't need fixing, spam wouldn't exist. There's more spam than there is legitimate email traversing the internet. That is a problem worth solving.
You could solve it with existing infrastructure to some extent, eg. your email address is actually a cryptographically generated guid rather than something easily guessed or harvested. If you combine that with a background handshake procedure for introductions, so that all of your contacts get their own guid alias mapped to your canonical one, then you can revoke any of those if they get compromised at any time. Spam is effectively solved.
This is basically like the web of trust, but for email.
> If email didn't need fixing, spam wouldn't exist.
Spam is not a technical problem, it's a societal problem. As usual the tech reflex is to find a technical solution but it is mistaken, once again. Societal proplems require societal solutions, not more tech. The only thing you will achieve with more tech is more segregation between those who have and those who don't, you'll create more issues than already exist
Email being so cheap and easy is is a significant component of spam, which is a technical problem to a degree. Spam on Signal, text message, voicemail, Discord, etc… is significantly less present for various reasons (cost, complexity, etc…)
Being cheap and easy is not a problem, quite the contrary. That we as a society make this a good thing for spam is a problem, but I don't want to make the system shittier just because of the bad use of it.
My work email is virtually useless at this point due to the absurd quantities of spam I receive. I think the OP suggestions would actually make email less shitty.
Any communication medium that is cheap and easy will be relentlessly abused by spammers.
> I suppose snake oil salesmen were a technical problem too?
Snake oil salesmen were not created because of lax technical infrastructure. Spam is not a technical problem because scammers exist, it's a technical problem because the technology is what lets them reach you. The technology can then be amended so they can't reach you and spam is solved. I'm not purporting to solve scams, but to solve the technical mistakes that lets scammers spam you.
wut. I guess we just need to wait for a big enough CME and we don't have to worry about spam anymore; so in that respect, I guess you are right. Though its like using a hammer on a window to screw in a picture frame.
> ...your email address is actually a cryptographically generated guid rather than something easily guessed or harvested. If you combine that with a background handshake procedure for introductions, so that all of your contacts get their own guid alias mapped to your canonical one, then you can revoke any of those if they get compromised at any time...
Here, you're kicking the problem further down the road, though, to another known attack vector: Directory Harvest Attack[1].
In this case, though, the directory (presumably) contains the guid mapping (which - by definition - would have to be a different guid than the object) and would have to process parsing these guids against the users. (This already occurs on recipient receive for some SMTP servers [just before BDATA/DATA] via the email address).
What would one bad email to an email guid do? Would it force rotation of the guid[s] throughout the entire forest? If so, how would that be communicated externally? How would you communicate it for just the one address, if you just changed the one guid?
Would you, instead, have to keep a guid history to check against -- or lose all of the email between possible compromise and the sender's database update? Would you just keep it in the Transport Queue, until manual intervention could check out email between the possible compromise of the guid and new mail would be received for the new guid? That wouldn't scale for large enterprises.
Keep in mind that nothing has to be sent for recipient validation to occur. The SMTP Server[s] just respond[s] to the recipient block with the next step -- but the caller doesn't have to complete the SMTP negotiation from this point, they already have validation if the addresses (even these proposed guids) are valid.
Tarpitting is somewhat of a viable option, here, but it isn't foolproof.
> Here, you're kicking the problem further down the road, though, to another known attack vector: Directory Harvest Attack[1].
Dictionary and brute force attacks don't work against cryptographic ids, so I don't see how this is relevant.
> What would one bad email to an email guid do?
I assume you mean, what would happen if you received a spam message and had to revoke a guid? First, revocation means the guid is no longer valid and to any incoming message, so it acts as if the guid simply doesn't exist.
Second, the idea here is that every entity gets their own guid designating you, so the same guid is not known by more than one entity. This is the purpose of the handshake protocol during introductions. If A and B know each other, B and C know each other, and A and C want an introduction, B triggers the introduction protocol which mints new guids for both A and C that are then exchanged with each other. This can happen transparently without the user seeing what's going on under the hood. Revocation is just a mark as spam button, and introduction is triggered by CC'ing more than one person in your address book (introduction is the trickiest part).
So if A gets a spam message from C, you just revoke the guid sent to C and you're done, any message from C now acts as if A's address no longer exists. This doesn't affect any connections to anyone else.
If B's guid for A is compromised in some way, you can trigger the introduction protocol again to mint a new guid after the compromise is resolved, then revoke the old one.
There is simply no way for spam to gain a real foothold here: they can't guess ids, and if they somehow obtain someone's address book, those addresses are valid only for one or two messages at best, before it gets revoked. The revocation and introduction protocols can happen using the existing protocols in a few different ways, like by exchanging some message types that are not seen by the user. There are definitely some details still to work out but I don't see any real roadblocks.
The only real "problem" is that now all email addresses are effectively private, eg. no globally addressable emails, which is not great for business purposes like info@mycompany.com. You could of course keep running the old email system for this.
Email can be delayed ... for days, hours, even weeks. What if I set up a dead-man email to you, you revoke the id, then I die? Would you somehow magically receive my email for a revoked id?
Well obviously I wouldn't get an email at a revoked address anymore than I would get messages at an email account that I closed. If you want to set up a dead man email, then set that up with an address that isn't shared with anyone else, then there would never be a reason to revoke it.
I don’t see that really working. I regularly delete personal tokens off of GitHub, especially if they haven’t been used in awhile. I could see the same cleanup happening (or even being forced by disk space usage).
Anyway, I don’t think this idea would work with normal human patterns. At work, we regularly saw people opening emails years after we sent them. Hell, I’ve emailed people years after not talking to them. I just don’t see this working.
Why would disk space be an issue? Guids are 16 bytes each. Even if you have 10k contacts, that's only 10k guids your email server has to store. That's 160kB. What's the big deal? You get more spam than that daily. Why wouldn't you persist 160kB to never get spam again?
> work, we regularly saw people opening emails years after we sent them
So? There just really isn't a need to revoke anything until you receive spam on that address. Maybe we're just not on the same page about how this works. Here's a more detailed overview of what I have in mind:
That's ~15gb per billion contacts. There's an estimated ~2 billion gmail users, so we're talking 30gb just to have one guid per user, and you're suggesting multiple guids per user (unbounded). So, let's assume each user has at least two services, we're now at a 60gb table, and that doesn't even include a mapping between users and guids, which will probably double the table size even more.
At scale, you're probably looking at a multiple-terabyte table, right from the start, and spending compute-days, or even compute-weeks, just running migrations; just to get some dubious returns and a lot of additional end-user complexity.
> So, let's assume each user has at least two services, we're now at a 60gb table, and that doesn't even include a mapping between users and guids, which will probably double the table size even more.
That's literally nothing. As I said, each user gets 10x more spam than that daily.
> and spending compute-days, or even compute-weeks, just running migrations
Migrations for what?
> just to get some dubious returns and a lot of additional end-user complexity.
There is no additional user complexity.
Supposing your math is correct, each user has a relatively fixed but larger than normal storage overhead for their address book and a inbox that that grows slowly because there's no spam, rather than a a small but fixed storage overhead for their address book and an inbox that grows 10x-100x faster due to mountains of spam.
I just really don't think you're comparing the storage requirements correctly.
> ...the idea here is that every entity gets their own guid designating you, so the same guid is not known by more than one entity
Ok, now you're sending a list of guids that _can_ be emailed to, per negotiation? Otherwise, how are they sending to that specific guid? A guid is not a hash of an object but an identifier object (a 16-byte array, if I recall correctly) - it has to map to the recipient _somehow_.
In other words, in each SMTP exchange, that information would have to be stored in some form of look-up table, _somewhere_, on both the sending and receiving servers.
How do you enforce the senders destroying that table, so that many versions of it don't expose your half of the signature? Do you generate a new key per session? If so, where are you storing that key, in memory? How would you prevent the heap from exposing those keys in a process crash (say, where a dump is automatically generated - like in Windows)? How do you prevent a nefarious actor using A, B, or C from generating a flood of SMTP sessions and creating a tonne (yes, the metric kind) of these look-up tables in memory? What happens when back-pressure is hit? Do you force everything else to paging but keep the tables in memory?
I think you're overthinking it. For simplicity, instead of [human-readable]@mydomain.com, let's use [guid]@mydomain.com, a dynamic set of unguessable aliases for your account. Your guids that have been handed out are completely under your control and stored on your server.
There are no cryptographic keys to manage here, just cryptographically secure identifiers that are stored on a server.
If you and I had been introduced, you would have a guid@naasking-domain.com designating me in your address book, and I would have a guid@felsokning-domain.com for your address in my address book.
So revoking the guid you have for me is an operation that happens on my server and simply invalidates the only address that you have. This part is simple and why spam is easily stopped in its tracks.
The introduction protocol is the tricky part, because C and B would have different guids for A, so if B CC's A when messaging C, then there should be a way for C to resolve their guid for A. This is done via a petname system.
If C does not already have a mapping for A (and so doesn't know A), then it can request an introduction from B. C sends B an "introduce-me as C[guid-intro]" message with a new guid for C, then B then sends to A "here's who I call C [guid-intro]". Guid-intro is a use-once guid for introduction purposes.
A then sends to C[guid-intro], "hi, I'm A[new-guid]". C replies, "hi, I'm C[new-guid]". C then revokes guid-intro since it was used, and we're done. A, B and C each have their own guid addresses for each other. You can keep the audit trail of where you got a guid introduction in a database, but that's not strictly necessary for this to work.
This introduction protocol happens transparently to the user just by exchanging specific message types the server recognizes. It's a protocol that can be built atop SMTP just to manage the database of addresses that the SMTP server accepts.
> If you and I had been introduced, you would have a guid@naasking-domain.com designating me in your address book, and I would have a guid@felsokning-domain.com for your address in my address book.
The description, here, is no different than S/MIME encryption exchange - in that the guid exchange has to be done before it could be used.
You still have the issue of [A]Guid and [C]Guid correlating between themselves _and_ it being "unique" per SMTP session (after all, you said before that each guid has to be unique per session). This is where my earlier reference to generated guids being exchanged during the SMTP session comes into play. However, leaving that aside...
A single-use guid is no different than an SMTP address, if we're going based on the single guid inferred from that line -- and that guid has to be stored elsewhere in your system for it to be resolved to a recipient. So, you need something like a guid history array on the object for the forest to be able to resolve that guid (on recipient resolve) to a mail object inside your forest.
You have no mechanism (from your description) for B sending to [A]Guid or [C]Guid junk mail (assuming they've been able to discover the guids) using those guids. You say you would invalidate [A]Guid or [C]Guid -- but this doesn't resolve the issue of [A] and [C] now having to re-exchange Guids, for something that B has done.
So, now, all valid email between [A]Guid and [C]Guid is invalidated (per your description) and they're calling into your helpdesk, trying to understand why valid email isn't being delivered.
Do you tell them to re-exchange guids? How do they re-exchange guids when the mail system is dependent (directly) on those guids already being established on both sides? How do they "re-introduce" themselves, in other words, in that scenario?
> The description, here, is no different than S/MIME encryption exchange - in that the guid exchange has to be done before it could be used.
There are formal connections between some encryption protocols and what I'm describing here (effectively a system based on capability security, ie. this is modelling spam as an access control problem for an unbounded set of actors). Basically encryption let's you do away with extra storage requirements for the guids, but the cost is additional complexity around key management and revocation, and more compute cost. I haven't thought about it enough to see if there's a formal correspondence with S/MIME, but my proposal is very simple so I don't think you need to try to understand it through that lens.
> You still have the issue of [A]Guid and [C]Guid correlating between themselves _and_ it being "unique" per SMTP session
No, these guids are not per-session, they are persisted in a user's address book.
> and that guid has to be stored elsewhere in your system for it to be resolved to a recipient
Yes, each user's address book contains the guid address for a contact just like right now it contains an email address. Just take the existing address book and make the emails cryptographically unguessable guids. If you and I have the exact same set of contacts, none of our guid addresses will match. That's literally it.
> you need something like a guid history array on the object for the forest to be able to
No such history is needed. I really think you're overcomplicating this.
> You have no mechanism (from your description) for B sending to [A]Guid or [C]Guid junk mail (assuming they've been able to discover the guids) using those guids.
I don't understand what you're trying to describe here.
> You say you would invalidate [A]Guid or [C]Guid -- but this doesn't resolve the issue of [A] and [C] now having to re-exchange Guids, for something that B has done.
If A and C have been introduced per the protocol I described, then anything B does has no impact on the relationship between A and C. If B sends them junk mail, the user (A or C) could decide to revoke B's access to them, or may opt to not revoke if they think it was an accident.
You could opt to track who introduced you and make revocation decisions based on that extra info too, but it's not strictly necessary.
> How do they "re-introduce" themselves, in other words, in that scenario?
In the case that a guid address has to be revoked but you want to keep the connection, (perhaps the guid address leaked somehow), then the mail agent would have renew their connection by re-running the introduction protocol before revoking the previous guid, or they would have to request another introduction through someone they both know.
This is as simple as having a "mark as spam" button, and when the user clicks it, it asks if they want to block the user entirely or if this was accidental (or something). If the former, the system revokes immediately, if the latter the system re-runs the introduction protocol using the existing guids to get new ones, then revokes the old ones.
> If email didn't need fixing, spam wouldn't exist.
Let's start with something easy - [1] define spam. [2] Can spam be identified with a purely mechanical (no humans involved) process?
Do you have a definition of "spam" that is substantially different from "mail that I don't want."
It's also interesting that you assume that spammers can't generate new identities. (Yes, you seem to think that introductions solves everything, but it doesn't)
I ask that because "I don't want" requires mind-reading by the sender.
I don't think you've actually read the details of my proposal because the fact that spammers can generate new identities is irrelevant.
Nevertheless, to answer your question, spam is generally understood to be unsolicited email. The fact that computers can't read minds is exactly why they shouldn't try and should instead simply remove the core mechanism that enables spam to begin with: the easy ability to reach you because of guessable and harvestable global identifiers, and the difficulty of changing a compromised address means collecting and reselling addresses has value.
Both of these properties are violated in this system. Minting new email guids is a trivial core operation that literally happ all of the time, and addresses cannot be guessed/brute-forced, therefore addresses have almost no value to spammers or brokers.
You're right - I thought that you'd made one fatal error (sender registries) when you'd actually made a different one (introducers).
> spam is generally understood to be unsolicited email
Not so fast. If spam is universally disliked and should be eradicated, it can't include all unsolicited email.
That's because people LIKE some unsolicited email. Unless you can distinguish unsolicited email that someone will like from unsolicited email that they won't like ...
FWIW, you come across like the "advertising should be banned" people. (That's another group that confuses the existence of a problem with the existence of a solution that doesn't have any downsides. They fixate on their solution and try to define-away its downsides.)
Advertising is a lot like spam. It is product information. If you don't care about the information, it is unwanted, but if you do.... The thing is, there's always someone who cares.
FWIW, every time I've physically met someone who claims to be anti-advertising, said someone has happily displayed several pieces of advertising for products that said someone liked. When I point that out, "that's different" or "I don't mean that kind of advertising."
> That's because people LIKE some unsolicited email. Unless you can distinguish unsolicited email that someone will like from unsolicited email that they won't like ...
Then they can opt into a service that sends them products they might like. Defaulting to opt-in, which is the current situation, is always terrible. Spam consists of a huge fraction of mail sent over the Internet, and vast majority don't want it, and it's a huge security problem (phishing, viruses etc.).
If Gmail implements this kind of protocol, then they can opt you into their advertising list as part of the sign up process.
Spam exists because email can be sent from any domain on the internet by default without requiring any validation.
The moment that enforced DMARC with p=reject is mandatory a lot of problems will go away because you will be required to "turn on" email for your domain with SPF and DKIM. In the mean time, every domain that has ever been registered is subject to being used for spam.
I just want to thank you for your contribution to this thread. I've long thought email should go in a direction similar to what you're describing, and I appreciate the specificity you've provided.
I wish I could say I'm surprised by the animosity (and relative lack of substance) in some of the comments you've received, but I guess that's a problem with social media and/or humanity that's unlikely to have a technical solution.
Each attendee gets their own guid introduction as usual, just by scanning a QR code or something, just before or after the talk. The same basic introduction protocol works here, the QR code just names a guid address that has constraints on it (time-limited maybe, or that limits introductions by number of attendees).
Corner cases like this have solutions, and even if they're a bit more awkward, who cares? 99.9% of people who suffer from spam don't encounter these corner cases. Should a solution solve the biggest part of the problem, or prioritize making the corner cases easy?
Attendee? What year is it in your world? (Also, time-limited is stupid for this case.)
This isn't an edge case - people pass out addresses expecting to be contacted by randoms all the time.
And, most contacts are second-order or further, so introductions aren't even possible because there's no common link. (I pass on "you should contact {other person}" to groups that I don't control all the time.)
I get that you're proud of your introductions hammer, but you don't get to ignore the existence of screws.
Perhaps you're unaware that most public talks take place at conferences, which yes, still have attendees.
> (Also, time-limited is stupid for this case.)
Time-limited is perfectly fine policy for some cases. Maybe you have a different case in mind, but that wasn't specified in your scenario.
> This isn't an edge case - people pass out addresses expecting to be contacted by randoms all the time.
And? If you want to open yourself to a flood of possible spam, then create an address just for that and publish it. Nobody's stopping you.
> And, most contacts are second-order or further, so introductions aren't even possible because there's no common link
What does "second order" even mean if not "someone I know knows them"?
There's nothing stopping the use of public addresses, the point of the proposal is that most people don't need it, and the default public nature of email is what creates the security and spam nightmare that it is.
Which address are they buying? Every contact you know has a different guid address for you, and as soon as one of those is used for spam, you can revoke it. What value does such an address have to a broker or spammer? Addresses have value now because they are global, easily guessable and harvestable, and difficult for the user to change. The system I'm describing violates all of those properties, thus devaluing the whole spam enterprise.
That seems region specific. I don't get paper spam in Australia. I did get some for a week, until I put a "no junk mail" sticker on my box, which is respected here. It's less of an issue of paper mail and more of applicable regulation.
Protocols aren’t going to change that. Email has to be open or it won’t work. But being open means there is abuse. And abuse means there is reputation. And reputation… means you will be blocked sometimes.
Question is whether a new or updated protocol could force users such as "email providers" to change their behaviour.
Here is something to downvote, a series of questions:
What if email were "pickup only" _from the sender_. Not from some intermediary recipient, e.g., an "email provider". What if the the recipient had to identify acceptable senders before they could "send" mail to the recipient. Arguably this already happens every time an email recpient gives out their email address to some email sender. What if the sender did not "send" mail but instead uploaded it to host run by the sender and accessible by the recipient. Then the recipient retrieves the mail from the sender.
In the past, one large email provider had an RSS feed for a user's inbox. What if the RSS feed is not provided by some third party "email provider" but by _senders_. What if the feed indicates whether there is new mail waiting to be retrieved by the recipient. Arguably, something like this already happens, albeit using third party intermediaries, for example as millions of people use non-public webpages on third party websites to communicate with each other, instead of using email. Recipients check these pages for comments or messages from "senders".
A simpler idea that requires no changes to any email protocol, which I have tested successfully on home network, is for sender and recipient to be on a peer-to-peer overlay and run their own SMTP servers, like the original internet. The sender SMTP server communicates directly with the receiver's SMTP server, not a third party SMTP server run by an "email provider". Obviously, sender and receiver should not invite anyone onto this network who they do not know and from which they do not want to receive email.
The fundamental problem with email is that personal, non-commercial email is mixed with commercial email, mail that is selling something. That's beneficial to marketers, but not email users. Any change to email that threatens to exclude the unsolicited, commercial email will be opposed fervently.
> What if email were "pickup only" _from the sender_.
Congrats, you've invented DJB's Internet Mail 2000[1]. Definitely a good proposal for moving the burden of spam back to the spammers but I don't think anyone took the time to seriously consider it.
Pickup email makes one problem in spam much worse. It demonstrates that the address being spammed is valid and active. That's one of the reasons most email clients/hosts don't load remote resources by default.
Unless there was a google-scale grab-n-cache going on for those messages, I think there'd be a problem.
Here is a fun thought/question: Could it be that (using rss) only one of the two parties needs to remember/have login credentials for the other to be able to obtain them?
I doubt there will be a technology that can reliably exclude unsolicited or commercial email. How will the system know, what's unsolicited or unwanted? It can make a guess and that's what the big ones do. But it won't get better than this. I don't think there will ever be an alternative where this could be opposed.
As for unsolicited, this is already taken on by the GDPR and if you're a company that wants to sell their stuff in the EU, you pretty much have no choice than to adhere to these laws.
Software developers trying to manipulate computer users for financial gain make lots of assumptions about what people want without ever asking them. I am not a software developer.
As a replacement for current email only, you're probably right in that nobody would care enough to do the significant investments necessary in a reasonable timeframe, similarly to IPv6 (and the pain there is arguably even greater than for email).
As an alternative to something with the semantics of what companies currently use SMS for (i.e. having ostensibly higher reliability and security), I think you'd see a lot of interest.
The next phase of email should be for Federal and state governments to host it. We need to move it off of private infrastructure for essential services like payments and recordkeeping. There should be better penalties for misuse of email services and scams now that it handles so many important things, including authentication to many sites everyone uses. I wrote a whole rant on this a while back on my blog, despite objections, email can well replace the outdated physical mail delivery systems currently in place around the world, vital communication in the age of corporate surveillance and scams needs to be regulated if not run, regulated, and secured by more accountable government resources.
We have already seen how our personal information can be harvested and weaponized. Leaving important email services to strategically opportunistic companies like Google will not be wise into the future.
The Gmail engineering team is perhaps 500 strong based on various estimates that try to exclude team members who work on Google Workspace more broadly. At Google’s median pay of $300K, the cost is very approximately $150M/yr to engineer the stuff that makes Gmail work. That’s before accounting for infrastructure specifically required for engineering efforts, such as training models.
Let’s speculate that migrating to a whole new email standard would eat up 10% of the team for a couple of years, giving time to build and adapt a software stack that can run at Google scale on the new standard. That’s a $30M spend.
While this figure is peanuts for Google, consider that during the span of time that engineers would be transitioning to “email 2.0,” the full Gmail team would continue to work on just maintaining “email 1.0” and adapting all the new standards that continue to make the existing system improve.
Why would anyone at Google want this disruption unless email 1.0 was so broken that it was hopeless?
From the article, the new software stack is just a slight modification of the existing stack. I just don't see how it would take a few years and 10% of the workforce to add a few new steps to the existing pipeline.
Once implemented in some open source mail agents, everyone can just upgrade on their usual schedule, so it's not like every single person needs to spend millions of dollars to transition.
I got to present at M3AAWG several years back and it was a cool experience...but that is not a conference you get to just show up to. The only reason I was there is because I was invited and memberships are pricey.
Email is amazing and underappreciated. The federated social network that everyone keeps trying to invent has been there all along. If more people controlled their own email address, it would be nearly perfect.
It seems a lot like trying to fight against Javascript on the web. They are eternally linked at this point, and the only way to replace it is to envelop with some sort of language polyfill for bckwards compatibility - which is just yet another layer of abstaction...
Here’s the thing: despite the internet’s email system being complex and confusing and riddled with problems, it is universally adopted and interoperable. No other open communication tool can boast of email’s massive interoperability.
Any new system will face the impossible burden of winning hearts and minds while the old system continues to chug along with billions of annual R&D spending and dozens of conferences full of smart people working on solving problems.
Even if “MX2” can peacefully coexist in the DNS, why would anyone spend the millions of dollars in engineering effort to move while their teams are busy building the latest layer that’s been invented to patch over the current system?
By all means if you want to propose a new email system, show up at IETF or M3AAWG and make a bold proposal. Someone will buy you a beer while they explain why you are much better off getting into the mud pit with the rest of us and working on the next pragmatic fix to keep things rolling along.