More people should be aware of their history. This text made the rounds in the late 1990s as spam was starting to become a problem. Everybody and their dog had their own “ultimate solution” to the spam problem, which they all thought was obviously the correct one, but all of them were more or less equally unworkable: <https://craphound.com/spamsolutions.txt>
zahlman 1 days ago [-]
To be clear, "this text" refers to the link at the end, not to TFA, correct?
teddyh 18 hours ago [-]
Yes. Sorry for being unclear.
8organicbits 1 days ago [-]
I think the network effects make email hard to replace, virtually everyone online has an email address. If this could include a migration path, with backwards compatibility with SMTP, I think it would have a better shot of getting adoption.
Modern email already depends on HTTP, with protocols like MTA-STS (https://www.rfc-editor.org/info/rfc8461/) using HTTPS/TLS to improve transit encryption, or Web Key Directory (https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...) which uses HTTP for public key distribution. Personally I think these incremental improvements of SMTP are more promising than replacements, but we deserve better email however we can build it.
abdullahkhalids 1 days ago [-]
There is an easy way to mostly replace email over a decade, with the NewEmail protocol
NewEmailServers are able to send and receive messages using either the Email or the NewEmail protocol.
Before sending a message, the NewEmailServer checks a directory (similar to DNS) to see if any of the recipients are on another NewEmailServer. If so, the message is sent to those recipients via NewEmail. Others get it by Email.
Completely backward compatible. Once google/microsoft shift to NewEmail, the rest will follow quickly except some legacy servers. All that is needed is a standards body.
montagg 1 days ago [-]
Basically what iOS messages does with SMS. I would note that this hasn't resulted in everyone using iOS messages as a communication protocol, but it does make users aware when it's not in use, with some inherent social pressure.
When dealing with any kind of network effect and existing user behavior, though, especially one as ingrained as email, I would highly recommend being judicious about using the word "just," given that these are mutually-reinforcing effects. Imagining a solution is a world away from implementing one.
Still, I think you're on the right track: create a new protocol on top of an old one, use the same input methods and user behaviors, call attention to when someone is not using it (e.g., green bubbles), and make it extremely easy for existing services to migrate to use it (i.e., the standard/standards body, notably NOT what Apple has done). One part that's missing here is some pressure to make this happen: positive pressure (economic, product sense, persuasion) or negative (economic, social, regulatory).
inigyou 11 hours ago [-]
I think Gmail did this! Gmail can send and receive messages to either Email or Gmail. Google and Microsoft talk to each other with something proprietary too.
We shouldn't be discussing the best ways to Embrace, Extend, Extinguish, because EEE and its consequences have been a disaster for internet openness, and we don't want to be increasing its spread.
myaccountonhn 1 days ago [-]
The sad thing is that the only successful attempts at tackling its popularity are proprietary, closed ecosystems.
eqvinox 11 hours ago [-]
The FOSS MTAs generally don't implement any of the HTTP features… because they require HTTP.
stronglikedan 1 days ago [-]
> we deserve better email however we can build it
Let's start with grouping messages into conversations reliably. Whatever black magic they are currently using is almost there, but has it's flaws.
inigyou 11 hours ago [-]
Message-ID and In-Reply-To? How would you do it better?
citizenpaul 1 days ago [-]
Yeah, this subject comes up every couple months. The problem is not getting it working. Its that email is a captured system at this point and the real work is various reputation management processes that the big providers control or you can't send email to/from them. They also have no real interest in letting you be your own email provider so its just pushing a rock up a hill grind, for what? To save <$100 a year piggybacking on another provider as a custom domain? or just use a free provider?
calvinmorrison 1 days ago [-]
Having worked at a provider, that is not the psychology at all. The #1 priority is to keep the mail flowing. #2 incremental improvements to security, spam, reputation is a distant second. The other thing is, providers already know and have people who work on email standards, work in the ecosystem, etc. So once you're inside, with people who know whats going on, know the tools, know how things work intuitively without having to read a manual, theres less desire to change.
citizenpaul 1 days ago [-]
I have no personal experience. I've just read a lot of peoples experience around trying to do their own email hosting. It seems the majority give up after a couple years of nonstop blacklisting problems. It could simply be only people with issues post about it.
The stories have discouraged my from spending my time on it though.
stackskipton 1 days ago [-]
As former Email Principal at major provider, sure, they run into blacklisting problems.
However, most of time, it's not that providers are blacklisting because "Ha ha ha, screw the little guy" but more "Yea, they are hosting on IP blocks with terrible reputation and spammers are absolute liars. I refuse to trust whatever they say, period."
If you have your own /24 or greater, you can become email provider. It's also just such a low margin business, it's not worth small businesses disrupting it.
calvinmorrison 22 hours ago [-]
and even as a provider, some are more aggressive than others. free.fr comes to mind
worthless-trash 1 days ago [-]
I have found that if you harsh blacklist from most countries you'll never communicate from you'll save a lot of spam.
I blacklisted pretty much all of africa and arabic nations and china on the IP level, ( ensure you get the bgp routed datacenters in those nations too) and not only did i get less spam, but less automated bot attacks on my webserver.
The reason people talk about the blacklist is because its just so damn effective.
amelius 1 days ago [-]
> First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room.
I like this.
Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?
TheOtherHobbes 1 days ago [-]
The unknown request will be buried in spam - a problem we have already, but worse.
And I do not want an infinite thread conversation. I want to be able to split off - and perhaps archive and export - different conversations by topic.
I recently had to some legal things, which included forwarding copies of a certain conversation to a lawyer. This turns out to be unreasonably difficult because email clients quote previous conversations. You want a clean thread of comment and reply about a specific topic. You don't get that.
You do get it on chat services, but there's no option there to create sub-conversations.
If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC. Protocols are far downstream of that.
jancsika 1 days ago [-]
> The unknown request will be buried in spam - a problem we have already, but worse.
I feel like every one of these suggested changes to email comes with a functionally equivalent parody magic trick.
For this one, a magician has two stacks of cards: a tall stack of "spam" cards, and a small stack of "inbox" cards.
The magician moves the stacks apart to make a spot for a new "request" stack.
To start the stack, they pick up five "request" cards from the inbox stack with one hand while subtly pushing the entire stack of "spam" cards with the other hand to spot they made for the "request" stack.
They then pass the five cards they were holding behind their back, revealing them with the opposite hand and finally shuffling them into the now tall stack of "request" cards.
Ta da!
> If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC.
A magician sweeps 17 sloppy stacks of cards off the table. They then show how the first 15 cards they pick up can more easily be arranged in only three stacks. Voila! Everybody claps.
While the audience members put money in the hat, the pedants stick around and watch the magician pick up the rest of the cards and end up with 18 sloppy stacks by the time the audience for the next show arrives.
Edit: clarification
Edit 2: I forgot this part: "Protocols are far downstream of that." So imagine 8 tiny tables below the main one which somehow end up with more than 52 cards in each of their 17 sloppy stacks.
BeetleB 1 days ago [-]
> The unknown request will be buried in spam - a problem we have already, but worse.
Keep in mind that many people around the world already use this solution.
In my case, I give senders a mechanism to go into my inbox without my explicit approval. The server sends them an email with a URL. They follow the instructions, and their email gets whitelisted.
Greylisting is not perfect, not even close, but it allows servers to reject huge amounts of garbage mail while allowing new mail from unexpected parties without user intervention.
dizhn 1 days ago [-]
It is similar but not the same thing. It does not have anything to do with the email being legit (non spam) or not. It only catches emails that do not do what they supposed to do when they are deferred for a little bit. They are supposed to try again later. (A super nice feature of email which protects you from losing all incoming emails when your server is down for a short time). The reasoning here is hopefully a spam script or software will not implement the standard properly or will skip apparently broken destinations.
What parent wants is also possible and I remember people doing it as far back as the early 2000s. You would basically manually whitelist an email or have them bypass the list (once or always) with something like a key word or token sort of like a captcha which can be shared off band.
thesuitonym 1 days ago [-]
It's definitely possible, a few companies do it, and let me tell you: People hate it.
BeetleB 1 days ago [-]
I've been doing it for almost a decade. Only one person has complained. I'm surprised by the hoops people are willing to go through to contact me.
I'm glad it works for you, but the overwhelming majority of people are not you, and they hate it.
BeetleB 24 hours ago [-]
Citation needed.
ponyous 1 days ago [-]
Spark email client supports this. It’s great
PaulRobinson 1 days ago [-]
"We" tried this in the late 1990s. I remember writing an exim config to do this a couple of ways back in my ISP times:
1. "The recipient will not get this message until you authenticate yourself as a legitimate sender at this URL [...]" - resulted in people never getting mail from no-reply addresses they cared about (banks, e-com, etc.)
2. "This sender has sent you an email, with this subject and this first paragraph. Click here to whitelist, here to blacklist" - created a lot of churn on first setup that users didn't like as a UX
Baking it into the protocol - even now in SMTP and IMAP land - is doable, but would be resisted by email providers who, for example, make their money selling data to marketing agencies. Like, you know, Google, Microsoft, Yahoo...
I've seen other approaches proposed - even at IETF level - over the years, including digital postage stamps (sender pays to send email, your server gets paid, and may reject non-stamped/paying email), but it's the usual network effect: until it becomes widely supported it won't "stick". The stuff that has been adopted has basically been stuff that Google likes, period.
inigyou 10 hours ago [-]
Baking any of these into the protocol will invalidate it. If there was a standard way to specify a URL to open to whitelist an address, spammers would just whitelist their addresses.
baudehlo 1 days ago [-]
It also misses one of the biggest fundamental problems with SMTP: Lack of per-recipient replies. Though you could potentially mandate a single recipient per request. We wrote a plugin to emulate that in Haraka, where you just 400 (temp fail) each subsequent recipient. The downside is some sources just plain don't retry.
inigyou 10 hours ago [-]
LMTP is a small modification of SMTP with a per-recipient response code - but I'm not sure what it's intended for. It isn't used on the internet. It's sometimes used as IPC within a mail server.
baudehlo 4 hours ago [-]
LMTP is for delivering to an IMAP (or JMAP) mailbox, generally. We also have a plugin for that. But it has certain flaws for exposing it to the internet (I just forget what they are right now).
stackghost 1 days ago [-]
Pretty sure 37signals' email/calendar offering ("Hey") works this way.
fny 1 days ago [-]
Is there any reason they shouldn't be the same?
dzonga 1 days ago [-]
other email clients/services like Hey etc do this.
at one point Gmail had a service for this - if I remember well - but google being google - I guess it was just a promotion project for someone.
xd1936 1 days ago [-]
This is the way hey.com operates. It's nice.
rbanffy 24 hours ago [-]
The fact nobody reinvented e-mail on top of a different set of standards is a good indication that the current stack is not as broken as some people would like to think.
It reminds me of a previous life, at a previous time, when everybody reinvented the content management system based on slightly different approaches, because they thought existing CMSs were too big. It starts with serving pages, then you want multiple templates, then you want accessibility, then you want to authenticate with LDAP, then you want to use the LDAP groups as your groups, and then you need to tie groups to roles, because groups mean one thing to the org, and roles mean another just to the CMS, then you realize a relational database isn't that good a match, then you realize it would be convenient to attach some logic, and a document database is no longer a great idea, then you need multiple datastores for content, then you need new workflows on top, then...
The devil is in the corner cases. They have been solved in different ways, by different parties, for decades, not always documented ("because it was just a simple thing, that once, and we fixed it"). Unless you've been there, you are doomed to make the same mistakes, and nobody was everywhere to avoid all mistakes.
Why not dedicate an effort to migrate all the COBOL code currently running almost every banking transaction? That should be easy ;-)
dredmorbius 16 hours ago [-]
I've been using email since the 1980s.
I've ... seen a lot of poorly-considered proposals to fix it.
The fact that email has one hell of a lot of lock-in does not mean that it's not-broken. Just that it happens to be in one hell of a local optimum from which reaching any preferable state has a lot of hill-climbing to do.
Much in the way that evolution is not teleological, and cannot identify some desired state it wishes to evolve toward, but must proceed, by stepwise incremental increases in fitness to another state, so it is with protocols and standards.
That's not to say that SMTP + fiddly bits doesn't solve some problems, occasionally elegantly. But the leap from there to "it's not as broken" is ... rather large.
I've read TFA and am going through comments to this thread. There are some ideas I like, some I question. I'd suggest that this proposal seems better though through than many others I've seen.
HumblyTossed 24 hours ago [-]
>> The fact nobody reinvented e-mail on top of a different set of standards is a good indication that the current stack is not as broken as some people would like to think.
email is one of those technologies that "just works" but so many people seem to think it needs to be "fixed". it's generally very reliable and so people should just accept that and be grateful. It could be worse - it could be enshittified like so much other technology.
HDBaseT 22 hours ago [-]
> it's generally very reliable and so people should just accept that and be grateful
It's only really "very reliable" if you use Google or Microsoft for email, since they are the arbitrator of modern email.
inigyou 10 hours ago [-]
Self-hosted receiving is also very reliable. Only when you send from your server you might have blacklisting problems. But so many applications today are receive-only - every website signup.
rbanffy 13 hours ago [-]
I admit it’s sometimes painful to self-host your SMTP service, but that’s because it was very painless to send massive amounts of spam and very painful to throttle and filter messages, but we have much better tooling now.
isaachinman 21 hours ago [-]
Working in this exact space with marcoapp.io
We all deserve better, even self-hosted IMAP servers
jerf 1 days ago [-]
I would advise reconsidering keeping the current format exactly. Something that would allow conventional email addresses to kept in a list that disambiguates them unambiguously would probably be a good idea.
You don't want to embed the entire email in JSON. Too many parsers past, present, and future tend to want to decode the entire JSON document into memory before doing anything else, and so you'd be forcing entire email documents to be held in memory at scale, which causes you major problems. I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though.
That improves the ability of more language environments to be able to handle the email as a stream or in chunks with "normal" libraries and practices. MIME parsers in languages that tend to favor pulling everything into RAM as a string are still more likely to have been forced to face this issue already.
zahlman 1 days ago [-]
> You don't want to embed the entire email in JSON. Too many parsers past, present, and future tend to want to decode the entire JSON document into memory before doing anything else, and so you'd be forcing entire email documents to be held in memory at scale
Why? Even if your system loads emails into memory a whole email at a time, that doesn't imply that it will load large numbers of emails simultaneously. The kind of processing that can be done by stream-processing large numbers of emails in parallel seems rather limited to me.
> I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though.
If we're specifically talking about being able to short-circuit after headers, then why not a JSON header followed by JSON representation of the body?
inigyou 10 hours ago [-]
Email already has the problem of complete buffering. That's why various services limit you to 10MB or 25MB.
wuschel 1 days ago [-]
> Optional postage for strangers: the server can answer a first contact with a 402. Configurable per mailbox; the cost of cold spamming stops being zero.
Interesting take re putting a cost on spam. Perhaps another take would be functionally implementing introductions.
> First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room.
Unfortunately, this will only move the problem, and only reduce it in the case when all outside communication is ignored.
philipwhiuk 1 days ago [-]
Yeah the 'Requests' folder just becomes the new Inbox folder.
Email clients already highlight/filter people in your contacts
Multicomp 1 days ago [-]
We could add a friend-of-friend for 1 degree of separation (Alice gets an email from Bob, she doesn't know Bob, so it would go into her Requests folder. But Charlie knows Bob and has said 'yes this guy is legit' and Alice has configured her email to trust Charlie's email recommendations up to 2 degrees of separation, so it goes into the inbox with an explanation that it was allowed by Charlie's trust of Bob).
And poof, we've poorly remembered Web of Trust from 20 years ago!
Overall I do love the idea of HTMP and if we could get it to easily fall back to standard old bad email, I think it could start as a niche and then upgrade towards HTMP over time as more clients adopted support for it.
ccamrobertson 1 days ago [-]
I think a lot of these concepts are fun/interesting, but I like that email today functions more like a mailbox than WhatsApp or Telegram. Whilst digital (or paper) spam is obnoxious I dislike the idea of binning every sender into a "unread" box until I approve them. I miss unreads all the time across apps like X and Telegram.
As a first step I would focus on something like broad S/MIME support. Unfortunately I suspect that the biggest email providers are disincentivized from doing this as it would disrupt their business models.
thesuitonym 1 days ago [-]
> Let's design the successor to email on top of HTTP
You can stop there, I've heard enough. Not everything is hypertext.
beej71 1 days ago [-]
And HTTP transports many, many more things than hypertext. It seems like a sensible choice for this use case in terms of capabilities.
inigyou 10 hours ago [-]
Why, what advantage does adding the extra layer bring? You can just open a socket and send JSON to it, you know, you don't need this layer. But if the layer brings advantages then you should, but you have to explain the advantages.
jjice 1 days ago [-]
From the first paragraph:
>The goal is not to replace the current mail system, heaven forbid!, but to learn, have fun and discover current technologies to swap out every element: sending, receiving, gateway, keys, and so on.
It's all for fun.
andros 1 days ago [-]
Usually, informed people only read the headline.
BeetleB 1 days ago [-]
I don't want to replicate email. I want to fix it.
Sending email should not be free. It should be really, really cheap to send an email to one person (like a fraction of a fraction of a cent), but get exponentially more expensive the more you send.
People shouldn't be able to send emails to you without your prior approval (which you can revoke at an instant).
The recipient should be able to charge a tack-on fee for having email sent to him. I should be able to charge annoying people a lot to send to me, and charge my friends almost nothing. People who send annoying stuff to me should pay more to get my attention.
All of a sudden, forwarding that stupid article without thinking about the content (or even reading the article they're sending) will be second guessed. Save the money (and time), by sending only worthwhile stuff that you penned.
beaugunderson 1 days ago [-]
> People shouldn't be able to send emails to you without your prior approval (which you can revoke at an instant).
this sounds terrible... i've gotten so many useful random emails from strangers over the years.
BeetleB 1 days ago [-]
Depends how it's designed. I've been doing something similar for almost a decade. If I get an email from a non-whitelisted person, they get an auto reply asking them to go through a simple hoop. Once they do that, the email lands in my inbox.
Yes, many people go through that hoop!
I can still see their emails if they don't. They site in a Quarantine folder. I used to look at it frequently to catch the occasional straggler, but I rarely do that now. I've set up an LLM to go through all my quarantined emails in the last N days, and send me an email on which of the quarantined emails probably should be viewed.
I'm OK missing out on a (very rare) good email if it means I don't have to deal with crap mass mails. And let me tell you: Life is great when you don't deal with mass mails.
beaugunderson 1 days ago [-]
ah, quarantine makes sense
i handle the overload a different way... i age everything out of my inbox one day at a time, each gets a label showing the remaining days; they start at 7 and count down. that way i only ever have 7 days of email to look at. it also makes it clear who the big offenders are... if 10% of the emails are some new marketing thing it's easy to see and unsubscribe. i do hate that there's still so much manual work involved though, i would love if marketers had to pay.
BeetleB 1 days ago [-]
> if 10% of the emails are some new marketing thing it's easy to see and unsubscribe
I built my system because I tired of finding ways to unsubscribe.
Now I can subscribe without abandon and never worry about any of those emails coming into my inbox.
cweagans 1 days ago [-]
Do you have a writeup somewhere about how this system works?
i like it in theory but there’s something in me that doesn’t want emails just discarded like that… i want to be off the list. a personal failing, i’m sure. :)
BeetleB 24 hours ago [-]
The thing you have to ask yourself is: Which do I prefer?
1. Someone puts me on a list and I have to do the work to get off.
2. They work to get me on their list, and I do virtually no work to get off the list.
I went with 2.
dfabulich 22 hours ago [-]
> It should be really, really cheap to send an email to one person (like a fraction of a fraction of a cent), but get exponentially more expensive the more you send.
The problem is the cost of creating fake identities. As long as creating fake identities has a fixed cost (increasing linearly with the number of identities you create), there's no way to charge the "same person" exponentially more for sending more email. They'll just create new identities to send new emails.
Some people realize this and then start imagining how to forbid fake identities (forbidding truly anonymous email), but that requires a centralized identification authority, which many participants in the system are actively trying to avoid.
If you want a centralized authority for sending messages without spam, then you should just use a popular centralized messaging app. Each messaging app is controlled by a centralized authority, for better and for worse; the general consensus is that spam is a much smaller problem on centralized messaging apps than on email. But centralizing authority is a very high price to fight spam.
Today, each email client just reads the emails and tries to categorize spam, assigning each email a spam "score" and quarantining mail over a certain threshold. We track email identities only by top-level domain names, which do have a cost. Emails can be signed with DKIM/SPF, and we can penalize emails that don't sign themselves. We don't have "central authorities," but there are very popular email services, following a power law, and they're close enough. If Gmail thinks your domain reputation is too low, you're gonna have to buy a new domain name if you want to email anybody on Gmail.
Without one official centralized authority, I think that's about as good as it's ever gonna get.
BeetleB 22 hours ago [-]
> The problem is the cost of creating fake identities. As long as creating fake identities has a fixed cost (increasing linearly with the number of identities you create), there's no way to charge the "same person" exponentially more for sending more email. They'll just create new identities to send new emails.
That's partially handled by my other proposals: People need to pre-approve the senders (otherwise email gets held in a quarantine folder), and people can tack on a fee. Let's make the tack-on fee default to 5 cents.
> If you want a centralized authority for sending messages without spam, then you should just use a popular centralized messaging app. Each messaging app is controlled by a centralized authority, for better and for worse; the general consensus is that spam is a much smaller problem on centralized messaging apps than on email. But centralizing authority is a very high price to fight spam.
The lack of openness is the problem. I'd be happy with WhatsApp if it allowed me to set default policies such as "From person X, don't send me any forwarded messages" and so much more I can't do with WhatsApp that I could do with email.
Ultimately, the solution has to be built into the protocol, and it has to be designed to minimize bad actors not honoring the protocol. May involve cryptography, blockchain, etc (which is why it likely never will be implemented).
> If Gmail thinks your domain reputation is too low, you're gonna have to buy a new domain name if you want to email anybody on Gmail.
Right idea, but wrong implementation. Google shouldn't decide it. You as the individual should have control over the filtering.
> Without one official centralized authority, I think that's about as good as it's ever gonna get.
Very likely true. I can still fantasize.
choilive 22 hours ago [-]
Sending email is already cheap, not free. Just so happens the cost is subsidized/hidden for most regular people and its so cheap that they give it away for free. For those of us that run transactional email, the cost is ~ $0.0001 per email for AWS SES, already at the fraction of a fraction of a cent you suggest.
BeetleB 22 hours ago [-]
Yes, but I want the rate to be variable depending on volume. I want it to be $0.0001 for a simple personal email. But if you send 10,000 emails today, I want it to cost you $100 (or more).
Many schemes to do this. Things like:
The first 10 emails is $0.0001 each.
The next 10 will be $0.001 each.
And so on. You can always fiddle with the thresholds and costs.
inigyou 10 hours ago [-]
I'm 10000 people sending 1 message each, to get the cheap cost for every message.
BeetleB 6 hours ago [-]
You're forgetting the 5 cent charge per recipient who hasn't put you in their approved list.
miki123211 24 hours ago [-]
This is impractical because micropayments are impractical.
I have a better idea; split the problem into two. First, require all messages to include an `Automated: 0|1` header; eventually downranking / banning providers that don't include it, like we now do with DKIM, SPF, DMARC and such.
For messages with `Automated: 1`, require informed consent, mediated and verified through the recipient's provider.
It's impractical to require pre-approvals on every message, because many people genuinely want human-to-human contact from semi-strangers. On the other hand, requiring consent without verification is ineffective, because it is too easy to pretend consent. This design splits the spam problem into two much more tractable su-problems, detecting lying senders that mark automated messages as non-automated (easy with modern AI + basic statistical analysis), and verifying consent for honest automated senders (just requires a protocol).
BeetleB 24 hours ago [-]
> This is impractical because micropayments are impractical.
Well, one can dream :-)
Micropayments may be impractical, but email as it is currently used is also impractical for personal use cases. Outside of the tech world, how many people do you know how primarily communicate via email?
Most have switched to texting, or to closed systems (WhatsApp, etc). Some of these closed systems make it easy for you to block others, and also can tightly
control spam.
> First, require all messages to include an `Automated: 0|1` header; eventually downranking / banning providers that don't include it
How do you handle bad actors who set it to 0?
> It's impractical to require pre-approvals on every message, because many people genuinely want human-to-human contact from semi-strangers.
You pre-approve the person, not the message. Once approved, no further approvals are needed.
And human-to-human contact, for me, means more or less 1:1 (or at most 5:1). If a semistranger wants to talk to me, by all means, I'll approve him. What's the concern?
> On the other hand, requiring consent without verification is ineffective, because it is too easy to pretend consent.
Right now I do it by whitelisting the email address. Obviously, it's fragile. In practice, it's never a problem. The only failures are when I get spam with a From address that is mine. No company ever impersonates a friend's email address to get to me.
(Not saying your solution is unworkable, but would need more details).
dfabulich 22 hours ago [-]
Today, Gmail and other major providers do this by tracking sender reputation at the domain level. If users mark your emails as spam, that hurts your domain's reputation. If a domain's reputation gets low enough, Gmail won't deliver mail from that domain.
It's better than nothing (much better than nothing, IMO), but but spam will continue to be an issue as long as we want/expect to receive incoming mail from strangers, and as long as we plan not to have a centralized authority for email identities.
inigyou 10 hours ago [-]
It has the fuzzy false positive problem too: suppose a million Gmail users sign up for your newsletter with email confirmation and all. Two months later you send a newsletter. A thousand of those will be annoyed by it despite explicitly subscribing and will report it as spam. Boom, you're now banned from Gmail.
raggi 22 hours ago [-]
Honestly we should just do this. Maddy and Stalwart have cheap enough concurrency and good enough scalability they could easily delay SMTP accepts server side for a time delay based on a combination of a local and global heuristic. We could easily start to produce an auditable global heuristic as well and start prototyping the solution today. Over time the community will have to decide how to work with the Cabal, or more specifically the Cabal will have to learn to start to re-engage with the community.
Just start.
aboardRat4 1 days ago [-]
Self-ejecting panels on three sides of the website are a horrible user experience.
Other than that...
The most important thing is not the protocol, it's the gui.
At the moment email's gui is horrible on all platforms without exception.
If/when a decent gui appears, protocols will follow.
Also, JMAP did reading can probably be just WebDAV?
andros 1 days ago [-]
GUIs cannot be built either before or during the specification of a protocol. In fact, this is the part that should have the least weight. There are important steps, such as system auditing or making design decisions (like certificate rotation), that are not addressed. However, the goal is not to replace SMTP/IMAP, but rather to show how modern tools, when properly assembled, can replace older protocols with serious design flaws.
JMAP is flexible, mature, and easy to connect with current technologies. It's a better option.
inigyou 10 hours ago [-]
You have two systems.
One has awesome certificate rotation and crap UI.
One has crap certificate rotation and awesome UI.
Which one will take over the world, and which one will only ever have 10 users?
andros 10 hours ago [-]
It's a false dichotomy; neither can survive in the long run. It's like asking yourself: would you prefer a car with a good engine but a bad steering wheel, or a car with good handling but a bad engine?
inigyou 9 hours ago [-]
More people drive Toyotas than Ferraris.
marssaxman 1 days ago [-]
> At the moment email's gui is horrible on all platforms without exception.
This is obviously a matter of opinion. Of course there are endless different email GUIs, on all the platforms; if you don't like one, there are many alternatives.
I cannot imagine that a "decent GUI" by modern web-development standards could be anything I'd prefer to what already exists. Email works and generally doesn't let designer ego get in the way.
aboardRat4 5 hours ago [-]
Which email gui supports managesieve?
isaachinman 21 hours ago [-]
Can you provide more feedback? What do you hate so much about current GUIs? (Working in this exact space)
aboardRat4 5 hours ago [-]
None of them have good (or any) support for managesieve.
Without managesieve (or some other autotagging mechanism), email is just a big pile of junk.
Even Gmail doesn't support editing filters on the mobile app. It's ludicrous in 2026. And their filters are strictly weaker than Sieve.
None of them have a feature to "quickly generate a filter rule from a message".
None of them have a way to generate a forum-like interface from a mailing list more or less automatically.
None of them (except deltachat, I think), support displaying messages linearly, one below another, rather than one at a time.
One at a time is also important. When I'm writing to my boss, I am writing a message as if it is a document. But when I'm writing to my girlfriend, I often want it to a be a one-line response.
Overquotting is badly managed. Gmail hides the previous message under a button, which is super slow, but most of the time overquotting is not even needed. There should be a button to "not quote" and "strip quotes automatically".
dewey 1 days ago [-]
> At the moment email's gui is horrible on all platforms without exception.
How can you say that when it's one of the benefits of email that it's an open protocol and there's thousands of different apps built on top of it. Terminal UIs, web interfaces, chat interfaces etc. - that should be one of the cases where there's a GUI for anyone.
inigyou 10 hours ago [-]
And they all suck
andros 1 days ago [-]
Why do you find the panel experience so bad?
aboardRat4 5 hours ago [-]
They flicker in front of my eyes, distract me from reading, and are easy to misclick.
Generally, there is zero reasons to add moving elements to a page.
flexagoon 1 days ago [-]
It's very annoying on mobile, covering half of the page all the time
andros 1 days ago [-]
When you scroll down, they should all disappear. Do you have JavaScript disabled? What browser and device are you using?
zahlman 1 days ago [-]
FWIW, I'm on desktop but I do have JS disabled (more precisely, I use NoScript).
This results in the top and left-side bars staying decorative and unobtrusive, but the concurrent visitor counter thingy is floating well above the bottom-right of the page. But then, as I shrink in the page width, the left-side bar and the concurrent visitor counter swap sides, and also a bunch of the content from the top is added to a new bar at the bottom. Eventually, the horizontal space between the side components becomes irrelevant such that they function as an additional bottom bar. At which point, maybe 40% of the vertical space is used for navigation and other shiny toys. This is really annoying, and the overall experience is inconsistent across widths.
(Also, at all widths, the top-bar has a transparent background, so main page text interferes with top-bar text as it scrolls.)
All of this is done in CSS, so presumably it can be fixed that way too.
andros 22 hours ago [-]
If you want to eliminate any friction, I recommend enabling JavaScript.
Otherwise, you can read it in terminal mode with: curl -H "Accept: text/markdown" [URL]
dredmorbius 15 hours ago [-]
The panels keep pushing back into the screen on Mobile.
I quickly resorted to Reader View (Firefox/Android).
Remove those, or stuff them below the article.
andros 15 hours ago [-]
The mobile interaction is similar; it's not a bug, it's by design. If you were able to read the article without any problems, I'm satisfied. Thanks for the feedback.
dredmorbius 10 hours ago [-]
That was on mobile.
If that's intent, the result is highly aggravating.
andros 10 hours ago [-]
I think you're focusing too much on your best practices paradigm and not enough on my design vision.
hju22_-3 4 hours ago [-]
Or perhaps you shouldn't get defensive of critique on your "design vision" such that you just write them off entirely like it has no value? You might like driving in the opposite lane, but rules say otherwise, and best practice can be likened to it because it's been decided on or landed that way due to multiple people being involved in the process of deciding those rules. Just as with best practices. There are best practices in design too, you know.
Anyhow. Depending on the viewport your panels do get in the way, it's 1/3 of the screen on mine for example. If you're going to hide the panels, hide them properly. That you show them at the top and bottom automatically, fine, though they could be smaller on mobile. However, you could at least consider the UX of using it on smaller viewports. If I want to scroll up a little bit while reading, they pop into view, making me have to scroll down to hide them again. Meaning I have to scroll higher up than intended, so I have enough space to scroll down. Another common user pattern is to slowly continually scroll too, and a tiny jitter upwards causes them to reappear, but requires comparatively massive downwards scrolling to hide again. Your site is not the only one to do this, but it's just bad design. Vision or no, and it's no justification, just an excuse. And then, what about left handed people? It's easier to accidentally click into the message box field, which opens up the keyboard and you'll have to close it. Pair this with it taking up the majority of thumb space for scrolling, given its size, and, well. Is it unreasonable for people to tell you it's aggravating? No. And this is without considering, and doing the minimum for, people who may suffer with controlling devices for whatever reason. Not by "bending over backwards" as some would have it, but at least taking such into consideration.
It's fine to have a vision of your intended or wanted design, but it's also important to be willing to reflect on how your vision may not necessarily be good design, depending on how one judges it, rather than just deflecting critique.
dredmorbius 6 hours ago [-]
Or perhaps the opposite is true.
The content is solid. The presentation very much Gets In The Way.
flexagoon 22 hours ago [-]
Yes, but when I stop scrolling and scroll up even a little bit (by accident, or because I want to scroll up and read something I missed) they appear again. I think the only good UX possible is to have a button to show/hide them instead.
andros 22 hours ago [-]
I'm sorry, but I disagree. The lowest interaction cost is scrolling; it's a natural, continuous, and almost involuntary gesture. Having to click or tap a button requires the user to stop, evaluate whether the title interests them, and decide to make the effort to tap. The interactions you're describing are intentional and measured. I'm sorry but if the content is truly all you care about, I recommend the previous option or activating your browser's reading mode.
flexagoon 15 hours ago [-]
> almost involuntary gesture
Exactly, which is why attaching large UI shifts to that involuntary gesture makes the experience feel very unpredictable
> activating your browser's reading mode
Reading mode is a hack that's only needed because sites aren't already readable. You shouldn't have to activate it to be able to read the content.
In addition, it doesn't always work well if the website didn't test it. On your website, for example, it removes all images from the text.
> Having to click or tap a button requires the user to stop, evaluate whether the title interests them
Purposefully doing things in a way that doesn't let the user decide if they want it is called a dark pattern. Its not far from those checkboxes that try to trick you into accepting marketing newsletters. "We can't give users an option to think if they want our emails! If they don't, why don't they just use their email's spam filtering?"
You may not see it like that yourself, but huge links to your CV, talks and courses are exactly that - an ad that covers half the screen.
You have multiple people telling you the experience is bad, and you asked for why, but when people give you the explanation you argue back. That's fine of course, it's your own site and you can do whatever you like with it without trying to suit anyone. But that doesn't make the reader experience less bad.
AKSF_Ackermann 1 days ago [-]
Content-addressed email breaks mailing lists, as those need to be able to add headers for subscribe/unsubscribe/list id, etc. There is a reason DKIM allows you to pick which headers to sign.
kamma4434 1 days ago [-]
Do we need mailing lists at all?
ninalanyon 1 days ago [-]
I Linus Torvalds needs them. And that's a good enough reason for their existence as far as I'm concerned.
RajT88 1 days ago [-]
A better protocol for email seems like it should be lower on the list compared to a better protocol for phone calls.
And I see a few ideas that might be worth picking up from this proposal.
Voice and text comms ... have much in common.
dinkelberg 1 days ago [-]
Copies the mistake from PGP with the unencrypted metadata.
1saadcodes 22 hours ago [-]
I like the approach of building on existing standards instead of starting from scratch. That said, solving communication between users is a very different problem from replacing a system that has to work with literally everyone
syhol 1 days ago [-]
I'm very excited by this idea. I feel like email/chat is ripe for reinvention.
I don't agree with "Domain control as a fallback", as the author said "a domain is not owned, it is rented" and I want to normalise the idea that if you lose your private key, you need to start again. I hate that we keep giving so much authority to domains, it's such a big weakness. The author even left the key rotation chain out of the initial implementation.
I still think root/signer keys or sigchains are decent options.
zdw 1 days ago [-]
I'd take this the opposite direction - HTTP should get more like SMTP.
Take this thought experiment - how does nearly every other standard protocol (DNS, SMTP, etc.) except for HTTP survive at scale without server-side load balancing?
Thankfully we're heading in this direction due to happy eyeballs and related client-side retry mechanisms.
HTTP? It would be a more interesting thought experiment with CoAP. And, is it really “modern” if it still uses a model (essentially) requiring stateful compute like JMAP?
jfb 1 days ago [-]
I like that the author at least head fakes towards postage, which is how spam gets solved, for real. It's far too late for SMTP, but I don't mind folks thinking hard about it.
inigyou 10 hours ago [-]
I thought there were good reasons it was repeatedly rejected in the past
inigyou 11 hours ago [-]
ActivityPub is literally SMTP over HTTP.
philipwhiuk 1 days ago [-]
Old version:
* DNS lookup for MX record
New version
* DNS lookup for A record
* HTTP request for .wellknown/htmp/known_hosts
Not sure why this is being considered as an improvement?
> each mailbox of a domain on a different provider
Why is this useful/necessary or even 'good'?
rzerowan 1 days ago [-]
Id think its for enduser flexibility and convenience. Its more involved to alter DNS records vs just adding a text line to a webpage and hitting that default endpoint as standard.
Same way LetsEncrypt allows the easiest setup with the .wellknown endpoint , where a user may not have DNS access beyond the initial A record setup.
inigyou 10 hours ago [-]
Why is one more involved than the other? DNS is just a text file too. And you might not even have a web server. Why should mail servers be required to also be web servers? And what if the web server for that domain is already a completely separate system, and now you force it to be linked to the email system?
8organicbits 1 days ago [-]
Email currently uses an HTTP request to https://mta-sts.<domain>/.well-known/mta-sts.txt, per RFC 8461. Depending on HTTPS/TLS instead of DNSSEC is one major reason you see this approach gaining popularity.
winstonwinston 21 hours ago [-]
To be fair, it’s used by only those who choose to use horrendous “mta-sts” instead of DNS-based Authentication of Named Entities (DANE).
I might add that if you want to enforce SMTP TLS, you can do just that without mta-sts or DANE.
8organicbits 6 hours ago [-]
Typically you don't want to require authenticated encryption for all outgoing email as many mail servers use certificates that are self-signed or otherwise appear invalid. It isn't as simple as it seems and isn't generally recommended.
What concerns do you have with MTA-STS?
tptacek 8 hours ago [-]
So, basically everybody? DANE has virtually no uptake. I think it might literally just be Microsoft at this point?
8organicbits 5 hours ago [-]
When I checked in 2024 (https://alexsci.com/blog/is-email-confidential-in-transit-ye...), Cloudflare had more domains using DANE than Microsoft. But you're right, DANE is not widely adopted. Lack of support by Google is most notable due to the large number of domains using their service.
stackskipton 1 days ago [-]
It's not a good idea, I'd call it terrible in fact. We have MX Records, might as well use those. If not, use SRV records. Requiring mail server to involved in root of the domain is terrible idea.
1 days ago [-]
astrodust 1 days ago [-]
The irony here that HTTP headers are descended directly from RFC822 email headers.
TeeMassive 1 days ago [-]
Asymmetric signature generation has been a solved problem for more than a quarter of a century. So are distributed hash tables. I can't believe email hasn't been replaced. My take on it is to follow the money. Microsoft, Google and Yahoo have a vested interest in being the only big identity providers along probably with some 3 letters agencies.
bellowsgulch 1 days ago [-]
This is measurably worse in every way if only by saying you've thrown out everyone's existing mail stacks.
No, no one wants to do that.
gostsamo 1 days ago [-]
Unfortunately, stopped reading at one moment, because though the idea might be interesting, the packaging was unbearable. The obnoxious real time visitors counter seriously screws with my screen reader. I don't care how many people are reading this every 3 seconds updated not only with numbers, but with randomly chosen emois in my speech stream.
If you have a website, please, don't subject your visitors to something like that.
andros 1 days ago [-]
I'm sorry to hear about your bad experience. I've hidden the counter for screen readers. Please try again when you're ready.
mrnotcrazy 1 days ago [-]
I liked the counters on the old 90s/2000s web but it was best at the bottom of the page cause it was easy to ignore. I can't ever see me wanting a moving box telling me other people are reading the same article as me but if I did it would blend in better.
Email is more than a technology its a community. There have been plenty of technical attempts at replacing it but they have failed to un-seat email because they focus only on the technology aspect which as you have found is largely a solved problem although... getting the details right might be hard. You need buy in from the community which is not just users but also businesses and organizations that use email which is everyone from CEOs to church leaders. It's not enough to fix email you have to get buy in from the community to make a meaningful change and I don't see anything here that would do that. This isn't really a criticism, just an insight I offer. I work in this field and we're trying to get out of it cause managing email sucks. I would love something new to take its place but the community has heard so many promises that never came to fruition, when that happens you either need a better promise(harder than it seems) or you need credibility which may be very difficult in the current climate. Not an unsolvable problem, those don't exist but sometimes the lever you need to solve the problem is further than you can reach alone and this is one of those times.
forty 1 days ago [-]
Anecdotally, I don't use a screen reader and also couldn't care less on the visitors on the site. I doubt anyone but you is interested in this, and probably this number is slightly lower just because of that popup
jeffbee 1 days ago [-]
The combination of "I have an idea for changing one of the fundamental experiences of modern life" and "my website is obnoxious and hostile" didn't really work for me.
andros 1 days ago [-]
The entire website is accessible; I dedicated ample time to it. This was a minor oversight, but I wouldn't call it hostility.
hju22_-3 4 hours ago [-]
To the letter of the word? Perhaps. To the spirit? Hmm.
Strange then that you reject critique elsewhere. Accessibility is not just a checkbox, it's to consider and test the actual use of it.
gostsamo 1 days ago [-]
Mistakes happen.
gostsamo 1 days ago [-]
Thanks for the change.
endre 1 days ago [-]
still better than CoI
mrsssnake 1 days ago [-]
Here is another, not so new, idea:
Username is your public key, password is your private key. So we get end to end encryption and account ownership out of the box. Something similar to how .onion addresses work.
Needing easy to remember addresses? Build aliases on top of that. Needing server-side automation? Handle trusted server your private key.
Also, almost everyone carry a 24/7 powered and Internet connected device in their pockets. The Internet - network that allows globally sending any data between devices. Maybe with full redesign third-party email servers should be made optional.
I believe we should focus less on how to redesign whole service and build more universal layers instead.
First, vsending any data to any machine. Second, optionally remotely accessing our data. Third, mail-like format of data.
jcgl 12 hours ago [-]
Tightly coupling identity to cryptosystems should be entirely dismissed for anything that is supposed to have broad adoption.
First off, these systems always require indefinitely-lived secrets. To rotate keys (or the whole cryptosystem—think future possible quantum computers) is to change identity. Therefore, to change keys is to break the previous identity. Anything that requires users to think about long-term secrets is user hostile and leads to a fragile system.
Second, the economics of pubkey-as-address are untenable. Can you imagine publishing .onion addresses on billboards and business cards, let alone sharing them verbally? Absolutely not.
Unless there’s something I’m missing (please do say), these problems are intractable when you’re dealing with cryptosystem-based identity.
In the end, identity and naming and fundamentally human concerns. If you try to kludge around this with purely technical solutions, all you’ll end up with is a system that doesn’t adequately reflect what identity means to people. Good systems support this (DNS, email); bad systems fight this (cryptocurrency, nostr).
inigyou 10 hours ago [-]
We need more and more varied DNS zones so there's competition between them. And not gTLDs which are just extensions of .us, but zones with genuinely independent administration.
jcgl 8 hours ago [-]
Agreed. DNS is, afaik, the very best naming system we've got. But there's plenty left to do to make it better for human beings. Legally encoded rights to DNS names paired with easy-to-use GUIs for non-technical users would be near the top of my list.
And greater zone diversity like you say too. Kinda related to that, something like increased pinning of non-root DNSSEC keys so that the root isn't so all-powerful.
8 hours ago [-]
jcgl 7 hours ago [-]
Edit: s/economics/ergonomics/
Mohiuddin7 1 days ago [-]
[dead]
Rendered at 21:21:48 GMT+0000 (Coordinated Universal Time) with Vercel.
Modern email already depends on HTTP, with protocols like MTA-STS (https://www.rfc-editor.org/info/rfc8461/) using HTTPS/TLS to improve transit encryption, or Web Key Directory (https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...) which uses HTTP for public key distribution. Personally I think these incremental improvements of SMTP are more promising than replacements, but we deserve better email however we can build it.
NewEmailServers are able to send and receive messages using either the Email or the NewEmail protocol.
Before sending a message, the NewEmailServer checks a directory (similar to DNS) to see if any of the recipients are on another NewEmailServer. If so, the message is sent to those recipients via NewEmail. Others get it by Email.
Completely backward compatible. Once google/microsoft shift to NewEmail, the rest will follow quickly except some legacy servers. All that is needed is a standards body.
When dealing with any kind of network effect and existing user behavior, though, especially one as ingrained as email, I would highly recommend being judicious about using the word "just," given that these are mutually-reinforcing effects. Imagining a solution is a world away from implementing one.
Still, I think you're on the right track: create a new protocol on top of an old one, use the same input methods and user behaviors, call attention to when someone is not using it (e.g., green bubbles), and make it extremely easy for existing services to migrate to use it (i.e., the standard/standards body, notably NOT what Apple has done). One part that's missing here is some pressure to make this happen: positive pressure (economic, product sense, persuasion) or negative (economic, social, regulatory).
We shouldn't be discussing the best ways to Embrace, Extend, Extinguish, because EEE and its consequences have been a disaster for internet openness, and we don't want to be increasing its spread.
Let's start with grouping messages into conversations reliably. Whatever black magic they are currently using is almost there, but has it's flaws.
The stories have discouraged my from spending my time on it though.
However, most of time, it's not that providers are blacklisting because "Ha ha ha, screw the little guy" but more "Yea, they are hosting on IP blocks with terrible reputation and spammers are absolute liars. I refuse to trust whatever they say, period."
If you have your own /24 or greater, you can become email provider. It's also just such a low margin business, it's not worth small businesses disrupting it.
I blacklisted pretty much all of africa and arabic nations and china on the IP level, ( ensure you get the bgp routed datacenters in those nations too) and not only did i get less spam, but less automated bot attacks on my webserver.
The reason people talk about the blacklist is because its just so damn effective.
I like this.
Question: can this e-mail specification/implementation also replace direct-messaging protocols (like WhatsApp)?
And I do not want an infinite thread conversation. I want to be able to split off - and perhaps archive and export - different conversations by topic.
I recently had to some legal things, which included forwarding copies of a certain conversation to a lawyer. This turns out to be unreasonably difficult because email clients quote previous conversations. You want a clean thread of comment and reply about a specific topic. You don't get that.
You do get it on chat services, but there's no option there to create sub-conversations.
If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC. Protocols are far downstream of that.
I feel like every one of these suggested changes to email comes with a functionally equivalent parody magic trick.
For this one, a magician has two stacks of cards: a tall stack of "spam" cards, and a small stack of "inbox" cards.
The magician moves the stacks apart to make a spot for a new "request" stack.
To start the stack, they pick up five "request" cards from the inbox stack with one hand while subtly pushing the entire stack of "spam" cards with the other hand to spot they made for the "request" stack.
They then pass the five cards they were holding behind their back, revealing them with the opposite hand and finally shuffling them into the now tall stack of "request" cards.
Ta da!
> If I was redesigning email I would think long and hard about different use cases and workflows and start with an RFC.
A magician sweeps 17 sloppy stacks of cards off the table. They then show how the first 15 cards they pick up can more easily be arranged in only three stacks. Voila! Everybody claps.
While the audience members put money in the hat, the pedants stick around and watch the magician pick up the rest of the cards and end up with 18 sloppy stacks by the time the audience for the next show arrives.
Edit: clarification
Edit 2: I forgot this part: "Protocols are far downstream of that." So imagine 8 tiny tables below the main one which somehow end up with more than 52 cards in each of their 17 sloppy stacks.
Keep in mind that many people around the world already use this solution.
In my case, I give senders a mechanism to go into my inbox without my explicit approval. The server sends them an email with a URL. They follow the instructions, and their email gets whitelisted.
https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl...
It's called threads - even Matrix has these
Surely only if you configure them that way. At least I can turn that off in my email client, Thunderbird.
Nina xx
Deltachat
https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl...
(Not answering your question, but referring to the approach).
They've since changed the design so it uses its own protocol and servers instead of email.
Honestly, I'd want this as a default. I wonder if a mailserver can be configure like this. Doesn't sound too hard, does it?
Greylisting is not perfect, not even close, but it allows servers to reject huge amounts of garbage mail while allowing new mail from unexpected parties without user intervention.
What parent wants is also possible and I remember people doing it as far back as the early 2000s. You would basically manually whitelist an email or have them bypass the list (once or always) with something like a key word or token sort of like a captcha which can be shared off band.
https://blog.nawaz.org/posts/2018/Sep/solving-my-email-probl...
1. "The recipient will not get this message until you authenticate yourself as a legitimate sender at this URL [...]" - resulted in people never getting mail from no-reply addresses they cared about (banks, e-com, etc.)
2. "This sender has sent you an email, with this subject and this first paragraph. Click here to whitelist, here to blacklist" - created a lot of churn on first setup that users didn't like as a UX
Baking it into the protocol - even now in SMTP and IMAP land - is doable, but would be resisted by email providers who, for example, make their money selling data to marketing agencies. Like, you know, Google, Microsoft, Yahoo...
I've seen other approaches proposed - even at IETF level - over the years, including digital postage stamps (sender pays to send email, your server gets paid, and may reject non-stamped/paying email), but it's the usual network effect: until it becomes widely supported it won't "stick". The stuff that has been adopted has basically been stuff that Google likes, period.
at one point Gmail had a service for this - if I remember well - but google being google - I guess it was just a promotion project for someone.
It reminds me of a previous life, at a previous time, when everybody reinvented the content management system based on slightly different approaches, because they thought existing CMSs were too big. It starts with serving pages, then you want multiple templates, then you want accessibility, then you want to authenticate with LDAP, then you want to use the LDAP groups as your groups, and then you need to tie groups to roles, because groups mean one thing to the org, and roles mean another just to the CMS, then you realize a relational database isn't that good a match, then you realize it would be convenient to attach some logic, and a document database is no longer a great idea, then you need multiple datastores for content, then you need new workflows on top, then...
The devil is in the corner cases. They have been solved in different ways, by different parties, for decades, not always documented ("because it was just a simple thing, that once, and we fixed it"). Unless you've been there, you are doomed to make the same mistakes, and nobody was everywhere to avoid all mistakes.
Why not dedicate an effort to migrate all the COBOL code currently running almost every banking transaction? That should be easy ;-)
I've ... seen a lot of poorly-considered proposals to fix it.
The fact that email has one hell of a lot of lock-in does not mean that it's not-broken. Just that it happens to be in one hell of a local optimum from which reaching any preferable state has a lot of hill-climbing to do.
Much in the way that evolution is not teleological, and cannot identify some desired state it wishes to evolve toward, but must proceed, by stepwise incremental increases in fitness to another state, so it is with protocols and standards.
That's not to say that SMTP + fiddly bits doesn't solve some problems, occasionally elegantly. But the leap from there to "it's not as broken" is ... rather large.
I've read TFA and am going through comments to this thread. There are some ideas I like, some I question. I'd suggest that this proposal seems better though through than many others I've seen.
email is one of those technologies that "just works" but so many people seem to think it needs to be "fixed". it's generally very reliable and so people should just accept that and be grateful. It could be worse - it could be enshittified like so much other technology.
It's only really "very reliable" if you use Google or Microsoft for email, since they are the arbitrator of modern email.
We all deserve better, even self-hosted IMAP servers
You don't want to embed the entire email in JSON. Too many parsers past, present, and future tend to want to decode the entire JSON document into memory before doing anything else, and so you'd be forcing entire email documents to be held in memory at scale, which causes you major problems. I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though.
That improves the ability of more language environments to be able to handle the email as a stream or in chunks with "normal" libraries and practices. MIME parsers in languages that tend to favor pulling everything into RAM as a string are still more likely to have been forced to face this issue already.
Why? Even if your system loads emails into memory a whole email at a time, that doesn't imply that it will load large numbers of emails simultaneously. The kind of processing that can be done by stream-processing large numbers of emails in parallel seems rather limited to me.
> I'd recommend something more like either a JSON header that defines what parts are in the email, followed by a normal MIME document, which is perfectly normal in HTTP with other things that use the format as well, or having the top level continue to be a MIME document and specify that the first part must be a JSON document containing the headers. JSON replacing the headers is generally something that would be a good idea, though.
If we're specifically talking about being able to short-circuit after headers, then why not a JSON header followed by JSON representation of the body?
Interesting take re putting a cost on spam. Perhaps another take would be functionally implementing introductions.
> First-contact consent: an unknown sender doesn't get into the mailbox; they land in a "requests" box with their first message visible (like Signal's message requests). You accept, and the thread opens forever. A stranger can knock on your door, which is the essential property of mail, but they can't fill up your living room.
Unfortunately, this will only move the problem, and only reduce it in the case when all outside communication is ignored.
Email clients already highlight/filter people in your contacts
And poof, we've poorly remembered Web of Trust from 20 years ago!
Overall I do love the idea of HTMP and if we could get it to easily fall back to standard old bad email, I think it could start as a niche and then upgrade towards HTMP over time as more clients adopted support for it.
As a first step I would focus on something like broad S/MIME support. Unfortunately I suspect that the biggest email providers are disincentivized from doing this as it would disrupt their business models.
You can stop there, I've heard enough. Not everything is hypertext.
>The goal is not to replace the current mail system, heaven forbid!, but to learn, have fun and discover current technologies to swap out every element: sending, receiving, gateway, keys, and so on.
It's all for fun.
Sending email should not be free. It should be really, really cheap to send an email to one person (like a fraction of a fraction of a cent), but get exponentially more expensive the more you send.
People shouldn't be able to send emails to you without your prior approval (which you can revoke at an instant).
The recipient should be able to charge a tack-on fee for having email sent to him. I should be able to charge annoying people a lot to send to me, and charge my friends almost nothing. People who send annoying stuff to me should pay more to get my attention.
All of a sudden, forwarding that stupid article without thinking about the content (or even reading the article they're sending) will be second guessed. Save the money (and time), by sending only worthwhile stuff that you penned.
this sounds terrible... i've gotten so many useful random emails from strangers over the years.
Yes, many people go through that hoop!
I can still see their emails if they don't. They site in a Quarantine folder. I used to look at it frequently to catch the occasional straggler, but I rarely do that now. I've set up an LLM to go through all my quarantined emails in the last N days, and send me an email on which of the quarantined emails probably should be viewed.
I'm OK missing out on a (very rare) good email if it means I don't have to deal with crap mass mails. And let me tell you: Life is great when you don't deal with mass mails.
i handle the overload a different way... i age everything out of my inbox one day at a time, each gets a label showing the remaining days; they start at 7 and count down. that way i only ever have 7 days of email to look at. it also makes it clear who the big offenders are... if 10% of the emails are some new marketing thing it's easy to see and unsubscribe. i do hate that there's still so much manual work involved though, i would love if marketers had to pay.
I built my system because I tired of finding ways to unsubscribe.
Now I can subscribe without abandon and never worry about any of those emails coming into my inbox.
1. Someone puts me on a list and I have to do the work to get off.
2. They work to get me on their list, and I do virtually no work to get off the list.
I went with 2.
The problem is the cost of creating fake identities. As long as creating fake identities has a fixed cost (increasing linearly with the number of identities you create), there's no way to charge the "same person" exponentially more for sending more email. They'll just create new identities to send new emails.
Some people realize this and then start imagining how to forbid fake identities (forbidding truly anonymous email), but that requires a centralized identification authority, which many participants in the system are actively trying to avoid.
If you want a centralized authority for sending messages without spam, then you should just use a popular centralized messaging app. Each messaging app is controlled by a centralized authority, for better and for worse; the general consensus is that spam is a much smaller problem on centralized messaging apps than on email. But centralizing authority is a very high price to fight spam.
Today, each email client just reads the emails and tries to categorize spam, assigning each email a spam "score" and quarantining mail over a certain threshold. We track email identities only by top-level domain names, which do have a cost. Emails can be signed with DKIM/SPF, and we can penalize emails that don't sign themselves. We don't have "central authorities," but there are very popular email services, following a power law, and they're close enough. If Gmail thinks your domain reputation is too low, you're gonna have to buy a new domain name if you want to email anybody on Gmail.
Without one official centralized authority, I think that's about as good as it's ever gonna get.
That's partially handled by my other proposals: People need to pre-approve the senders (otherwise email gets held in a quarantine folder), and people can tack on a fee. Let's make the tack-on fee default to 5 cents.
> If you want a centralized authority for sending messages without spam, then you should just use a popular centralized messaging app. Each messaging app is controlled by a centralized authority, for better and for worse; the general consensus is that spam is a much smaller problem on centralized messaging apps than on email. But centralizing authority is a very high price to fight spam.
The lack of openness is the problem. I'd be happy with WhatsApp if it allowed me to set default policies such as "From person X, don't send me any forwarded messages" and so much more I can't do with WhatsApp that I could do with email.
Ultimately, the solution has to be built into the protocol, and it has to be designed to minimize bad actors not honoring the protocol. May involve cryptography, blockchain, etc (which is why it likely never will be implemented).
> If Gmail thinks your domain reputation is too low, you're gonna have to buy a new domain name if you want to email anybody on Gmail.
Right idea, but wrong implementation. Google shouldn't decide it. You as the individual should have control over the filtering.
> Without one official centralized authority, I think that's about as good as it's ever gonna get.
Very likely true. I can still fantasize.
Many schemes to do this. Things like:
The first 10 emails is $0.0001 each.
The next 10 will be $0.001 each.
And so on. You can always fiddle with the thresholds and costs.
I have a better idea; split the problem into two. First, require all messages to include an `Automated: 0|1` header; eventually downranking / banning providers that don't include it, like we now do with DKIM, SPF, DMARC and such.
For messages with `Automated: 1`, require informed consent, mediated and verified through the recipient's provider.
It's impractical to require pre-approvals on every message, because many people genuinely want human-to-human contact from semi-strangers. On the other hand, requiring consent without verification is ineffective, because it is too easy to pretend consent. This design splits the spam problem into two much more tractable su-problems, detecting lying senders that mark automated messages as non-automated (easy with modern AI + basic statistical analysis), and verifying consent for honest automated senders (just requires a protocol).
Well, one can dream :-)
Micropayments may be impractical, but email as it is currently used is also impractical for personal use cases. Outside of the tech world, how many people do you know how primarily communicate via email?
Most have switched to texting, or to closed systems (WhatsApp, etc). Some of these closed systems make it easy for you to block others, and also can tightly control spam.
> First, require all messages to include an `Automated: 0|1` header; eventually downranking / banning providers that don't include it
How do you handle bad actors who set it to 0?
> It's impractical to require pre-approvals on every message, because many people genuinely want human-to-human contact from semi-strangers.
You pre-approve the person, not the message. Once approved, no further approvals are needed.
And human-to-human contact, for me, means more or less 1:1 (or at most 5:1). If a semistranger wants to talk to me, by all means, I'll approve him. What's the concern?
> On the other hand, requiring consent without verification is ineffective, because it is too easy to pretend consent.
Right now I do it by whitelisting the email address. Obviously, it's fragile. In practice, it's never a problem. The only failures are when I get spam with a From address that is mine. No company ever impersonates a friend's email address to get to me.
(Not saying your solution is unworkable, but would need more details).
It's better than nothing (much better than nothing, IMO), but but spam will continue to be an issue as long as we want/expect to receive incoming mail from strangers, and as long as we plan not to have a centralized authority for email identities.
Just start.
Other than that...
The most important thing is not the protocol, it's the gui.
At the moment email's gui is horrible on all platforms without exception.
If/when a decent gui appears, protocols will follow.
Also, JMAP did reading can probably be just WebDAV?
One has awesome certificate rotation and crap UI.
One has crap certificate rotation and awesome UI.
Which one will take over the world, and which one will only ever have 10 users?
This is obviously a matter of opinion. Of course there are endless different email GUIs, on all the platforms; if you don't like one, there are many alternatives.
I cannot imagine that a "decent GUI" by modern web-development standards could be anything I'd prefer to what already exists. Email works and generally doesn't let designer ego get in the way.
Without managesieve (or some other autotagging mechanism), email is just a big pile of junk.
Even Gmail doesn't support editing filters on the mobile app. It's ludicrous in 2026. And their filters are strictly weaker than Sieve.
None of them have a feature to "quickly generate a filter rule from a message".
None of them have a way to generate a forum-like interface from a mailing list more or less automatically.
None of them (except deltachat, I think), support displaying messages linearly, one below another, rather than one at a time.
One at a time is also important. When I'm writing to my boss, I am writing a message as if it is a document. But when I'm writing to my girlfriend, I often want it to a be a one-line response.
Overquotting is badly managed. Gmail hides the previous message under a button, which is super slow, but most of the time overquotting is not even needed. There should be a button to "not quote" and "strip quotes automatically".
How can you say that when it's one of the benefits of email that it's an open protocol and there's thousands of different apps built on top of it. Terminal UIs, web interfaces, chat interfaces etc. - that should be one of the cases where there's a GUI for anyone.
Generally, there is zero reasons to add moving elements to a page.
This results in the top and left-side bars staying decorative and unobtrusive, but the concurrent visitor counter thingy is floating well above the bottom-right of the page. But then, as I shrink in the page width, the left-side bar and the concurrent visitor counter swap sides, and also a bunch of the content from the top is added to a new bar at the bottom. Eventually, the horizontal space between the side components becomes irrelevant such that they function as an additional bottom bar. At which point, maybe 40% of the vertical space is used for navigation and other shiny toys. This is really annoying, and the overall experience is inconsistent across widths.
(Also, at all widths, the top-bar has a transparent background, so main page text interferes with top-bar text as it scrolls.)
All of this is done in CSS, so presumably it can be fixed that way too.
I quickly resorted to Reader View (Firefox/Android).
Remove those, or stuff them below the article.
If that's intent, the result is highly aggravating.
Anyhow. Depending on the viewport your panels do get in the way, it's 1/3 of the screen on mine for example. If you're going to hide the panels, hide them properly. That you show them at the top and bottom automatically, fine, though they could be smaller on mobile. However, you could at least consider the UX of using it on smaller viewports. If I want to scroll up a little bit while reading, they pop into view, making me have to scroll down to hide them again. Meaning I have to scroll higher up than intended, so I have enough space to scroll down. Another common user pattern is to slowly continually scroll too, and a tiny jitter upwards causes them to reappear, but requires comparatively massive downwards scrolling to hide again. Your site is not the only one to do this, but it's just bad design. Vision or no, and it's no justification, just an excuse. And then, what about left handed people? It's easier to accidentally click into the message box field, which opens up the keyboard and you'll have to close it. Pair this with it taking up the majority of thumb space for scrolling, given its size, and, well. Is it unreasonable for people to tell you it's aggravating? No. And this is without considering, and doing the minimum for, people who may suffer with controlling devices for whatever reason. Not by "bending over backwards" as some would have it, but at least taking such into consideration.
It's fine to have a vision of your intended or wanted design, but it's also important to be willing to reflect on how your vision may not necessarily be good design, depending on how one judges it, rather than just deflecting critique.
The content is solid. The presentation very much Gets In The Way.
Exactly, which is why attaching large UI shifts to that involuntary gesture makes the experience feel very unpredictable
> activating your browser's reading mode
Reading mode is a hack that's only needed because sites aren't already readable. You shouldn't have to activate it to be able to read the content.
In addition, it doesn't always work well if the website didn't test it. On your website, for example, it removes all images from the text.
> Having to click or tap a button requires the user to stop, evaluate whether the title interests them
Purposefully doing things in a way that doesn't let the user decide if they want it is called a dark pattern. Its not far from those checkboxes that try to trick you into accepting marketing newsletters. "We can't give users an option to think if they want our emails! If they don't, why don't they just use their email's spam filtering?"
You may not see it like that yourself, but huge links to your CV, talks and courses are exactly that - an ad that covers half the screen.
You have multiple people telling you the experience is bad, and you asked for why, but when people give you the explanation you argue back. That's fine of course, it's your own site and you can do whatever you like with it without trying to suit anyone. But that doesn't make the reader experience less bad.
And don't just say we'll build that on HTTP too!
And I see a few ideas that might be worth picking up from this proposal.
Voice and text comms ... have much in common.
I don't agree with "Domain control as a fallback", as the author said "a domain is not owned, it is rented" and I want to normalise the idea that if you lose your private key, you need to start again. I hate that we keep giving so much authority to domains, it's such a big weakness. The author even left the key rotation chain out of the initial implementation.
I still think root/signer keys or sigchains are decent options.
Take this thought experiment - how does nearly every other standard protocol (DNS, SMTP, etc.) except for HTTP survive at scale without server-side load balancing?
Thankfully we're heading in this direction due to happy eyeballs and related client-side retry mechanisms.
* DNS lookup for MX record
New version
* DNS lookup for A record
* HTTP request for .wellknown/htmp/known_hosts
Not sure why this is being considered as an improvement?
> each mailbox of a domain on a different provider
Why is this useful/necessary or even 'good'?
I might add that if you want to enforce SMTP TLS, you can do just that without mta-sts or DANE.
What concerns do you have with MTA-STS?
No, no one wants to do that.
If you have a website, please, don't subject your visitors to something like that.
Email is more than a technology its a community. There have been plenty of technical attempts at replacing it but they have failed to un-seat email because they focus only on the technology aspect which as you have found is largely a solved problem although... getting the details right might be hard. You need buy in from the community which is not just users but also businesses and organizations that use email which is everyone from CEOs to church leaders. It's not enough to fix email you have to get buy in from the community to make a meaningful change and I don't see anything here that would do that. This isn't really a criticism, just an insight I offer. I work in this field and we're trying to get out of it cause managing email sucks. I would love something new to take its place but the community has heard so many promises that never came to fruition, when that happens you either need a better promise(harder than it seems) or you need credibility which may be very difficult in the current climate. Not an unsolvable problem, those don't exist but sometimes the lever you need to solve the problem is further than you can reach alone and this is one of those times.
Strange then that you reject critique elsewhere. Accessibility is not just a checkbox, it's to consider and test the actual use of it.
Username is your public key, password is your private key. So we get end to end encryption and account ownership out of the box. Something similar to how .onion addresses work. Needing easy to remember addresses? Build aliases on top of that. Needing server-side automation? Handle trusted server your private key.
Also, almost everyone carry a 24/7 powered and Internet connected device in their pockets. The Internet - network that allows globally sending any data between devices. Maybe with full redesign third-party email servers should be made optional.
I believe we should focus less on how to redesign whole service and build more universal layers instead. First, vsending any data to any machine. Second, optionally remotely accessing our data. Third, mail-like format of data.
First off, these systems always require indefinitely-lived secrets. To rotate keys (or the whole cryptosystem—think future possible quantum computers) is to change identity. Therefore, to change keys is to break the previous identity. Anything that requires users to think about long-term secrets is user hostile and leads to a fragile system.
Second, the economics of pubkey-as-address are untenable. Can you imagine publishing .onion addresses on billboards and business cards, let alone sharing them verbally? Absolutely not.
Unless there’s something I’m missing (please do say), these problems are intractable when you’re dealing with cryptosystem-based identity.
In the end, identity and naming and fundamentally human concerns. If you try to kludge around this with purely technical solutions, all you’ll end up with is a system that doesn’t adequately reflect what identity means to people. Good systems support this (DNS, email); bad systems fight this (cryptocurrency, nostr).
And greater zone diversity like you say too. Kinda related to that, something like increased pinning of non-root DNSSEC keys so that the root isn't so all-powerful.