I've made a new version of my essay on re-thinking email, and solving the spam problem. See or

I'd be happy to hear constructive feedback.

TL;DR: I don't think the current email system can be improved enough to be worthwhile, but a new system could use digital signatures and digital stamps (tokens) to only allow recipients accept mail from specific senders.

@liw Thank you for clean pdf metadata. Self-sorting files are blissful.

The context I am approaching this from is one that sees inboxes and message queues as the perceptual stream of a cyborg in its most raw and unsatisfactory format.

- PGP signature, aside from low usability, matches the digital identity described in 2.3. However, the effective non-repudiation produced by a persistent signature means that if your email to someone is revealed, you are in an uncomfortable position. This may be acceptable (or even necessary) in corporate contexts, but may not be suitable for personal communications. This can be mitigated by making the creation of numerous identities easy, but that would require specific thought and support.

- Client side naming sounds excellent to me, but this is where a mitm attack is usually considered as the downside unless the key has been verified out of band. I personally feel that broad implementation should just go ahead, and mitm because its mitigation is a human habit not a technological mechanism can be solved down the line when its prevalence warrants attention.

- I like the stamp system as described at the start of the section — not cost, but authorization / consent. Almost every problem with the current email system can be boiled down to inability to enforcibly express constraints of consent. This sounds like it comes from, or could tie in with, cwebber's ocap, which I think is an excellent direction to move in. Monetary stamps have an added meta-cost, in that they require providing the system with a valid information for being able to conduct financial transaction. That is a barrier a lot of people will be unwilling or unable to cross.

- Combined with sufficient user interface and interaction support, I think this could make huge inroads against the spam problem. I view the spam problem as a direct consequence of our 'distance 1 topology', ie. the first property you mentioned, that anyone can email anyone directly and without intermediate requests. Stamps could be used to achieve delivery at all, or to achieve delivery to a certified rather than default queue, or as a form of 'digital introduction' where you have to obtain an introduction from a friend of a friend to gain a stamp to send to someone directly. A lot of this becomes literal gatekeeping, but not necessarily in a bad way. I think it would be worth building an 'artificial stupidity' model of randomized actors attempting to message pass under these systems in order to game out the scenarios.

@liw Just came across your blog post. I've been working on the exact same problem since literally last Easter and it has become my passion. It's been good to see someone has reached similar conclusions.

I'd really appreciate it if you could check my project's website and offer feedback.

@liw not only this but we need to make email more sane and accesible for the average folk. POP3 must be deprecated and JMAP put to use instead. All these ports and settings should be streamlined and configured automaticaly.

@liw I don't know if this exceeds scope, but repudiability and nonrepudiability are both characteristics which may be worth consideration. Generally these are side effects of authentication. Nonreputability-by-entity is another variant.

Ephemerality and perfect forward secrecy might also be considered.


@liw I think you problem statement is pretty good. I'll suggest there may be a common underlying concept or two.

- Spam and scam mail both principally concern trust (or abuse of trust), as does privacy -- freedom from surveillance, metadata leakage. Possibly unauthorised forwarding, though that's all but certainly inevitable.

- Finite attention and what are effectively denial-of-service attacks, in mail volume, technical administration, & vigilance, are additional threats.


@liw A possible alternative, or implementation, of "stamp" dynamics might be SLA levels afforded remote peers. The geymilter model might be a suitable starting point: set a service frequency / response rate for peers based on trust. The initial level would be modest but not impassible. Reputation vouching (similar to you "stamps on behalf of" notion) should be possible.

Trusted peers get high service levels.

Untrusted peers would see a proportionately low service level.


@liw Connection attempts, packet acks, local recipients per connection, messages permitted per day (or week, or month, or ...) would be curtailed.

Previously unknown peers could be required to acquire a reputation token, at some cost (hash, time, cash), before being permitted to connect. Again, a bar, but a surmountable one.


@liw The problem with sender/author reputation is ... most senders simply cannot be arsed. Even large & presumably technically capable ones. Some combination of PKI components, elements, cross-signatures, & trust is _probably_ where the solution lies, but in over a quarter century we've made frustratingly little progress.

At some point an authority with teeth is going to have to step in, dictate a standard, convince others to accept it, and enforce it.

I don't see that any time soon.


@liw I'd also like to se requirements for recipients demanding, and senders being required to provide, a minimally-complex message format -- plain ASCII (or minimum sufficient appropriate characterset) or equivalent. No HTML, no links, no attachments.

*Maybe* a very-tightly-defined minimal lightweight markup (e.g., Markdown). The amount of generally unreadable email I receive is ... large.


@liw DNS and its role in addressing is another huge problem. Name resolution is inextricably bound to SMTP-baseddeliveery, and was created in large part to address it. As WITHSMTP it's outliving its usefulness.

Overall I tend to share your concerns w/ SMTP email.

Where I can't settle on a conclusion is. in whether the concept of open-standards textual messaaging is salvagable with a ground-up redesign, or is simply a lost cause.


@Lars Wirzenius @Doc Edward Morbius ⭕ We tried to implement such a scheme at Netscape in the mid/late 90s and invited Eric Allman (sendmail) and a Microsoft representative to join us in stopping spam forever. Together we represented the most influential and widely used SMTP servers on earth (at the time). Eric refused because he didn't want to piss off Chinese dissidents. Microsoft refused because they didn't invent it and this didn't fit their agenda of wiping Netscape from the face of the earth. So 24 years later we're still dealing with spam. Anyway yes, you can do it, but don't expect the rest of the world to go along. They won't.

Eventually this was released as an "internal" flag in Netscape's mail system. This work was based on SSL client certs and SMTP-AUTH. If you saw the indicator, it came from a sender that was end-to-end authenticated, even through cooperating SMTP relays. Several Fortune 500 companies demanded it. I haven't even looked to see if it is still supported (doubtful after this length of time), but if it is, it might be a good place to start.

@liw Maybe some of this goes back to my anti-spam system:

It got a little coverage back on the old (ultimately useless) IETF ASRG. But, yes, authorization is the key missing ingredient. I still use my system, and don't have a spam problem.

@Andy Valencia ✅ That's actually a really interesting approach. I also have a mail system where my email address adorned with a suffix will all be routed to the inbox for the unsuffixed address. In my case any suffix will be let through, but I can identify which org sold my email address, or which website they scraped it off of. But I can see how actually disallowing emails to your unsuffixed address, and the ability to drop addresses that has been abused makes all the difference. Thanks!
Sign in to participate in the conversation

Lars and friends