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 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 and friends