Modern email can be built from borrowed parts

Post by inigyou » Tue, Jul 28, 2026, 10:48 AM UTC

abdullahkhalids wrote: post #60

8organicbits wrote: post #6

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…

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. C…

Post by inigyou » Tue, Jul 28, 2026, 10:50 AM UTC

amelius wrote: post #2

> 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-mes…

Post by inigyou » Tue, Jul 28, 2026, 10:54 AM UTC

baudehlo wrote: post #53

PaulRobinson wrote: post #40

Earlier quoted context omitted.

"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…

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.

Post by inigyou » Tue, Jul 28, 2026, 10:56 AM UTC

jerf wrote: post #61

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…

Post by inigyou » Tue, Jul 28, 2026, 11:00 AM UTC

dfabulich wrote: post #97

miki123211 wrote: post #87

Earlier quoted context omitted.

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 impractica…

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…