How can this reach critical mass when people are already using email for a similar purpose?
I don’t understand why you need to completely (and naively) need to recreate something like SMTP.
This project tries to do too many things, even forms and charts. There’s no separation between layers.
Let's call it the Secure Mail Cooperative. In order to join the SMC, you need to:
- have an acceptable usage policy that means you will not allow any of your users to send spam (defined as...). Your first violation gets a warning. Your second violation gets you suspended from the SMC for a month. Third violation in a year disqualifies your organization from ever rejoining. Reset the count a year after a second violation.
- register the fingerprint of your SSL certs with the SMC, which will publish it in a DNS accept-list.
- add an SMC header to your SMC-bound email that indicates the address of your SMC postmaster, who is one or more people who can enforce the AUP on your side. The SMC postmaster address should never accept non-SMC email.
- agree that the SMC postmaster will be tested every so often and a lack of a response within 168 hours will be considered a violation, same as spam.
That's all off the top of my head, but it could reasonably work... for individuals and small to medium organizations. It requires too much attention for a Google or Microsoft to afford.
In your cooperative, if two or more of the thousands of accounts in my org are compromised, the entire org loses email?
Not gonna happen, even if you tweak the rules to be more lenient.
Realistically we will always have spam. It can be reduced but, just like snail mail and all other forms of push communication, you will always get spam. Get over it.
I think we may create a similar network basing on same old ESMTP, what we need is just to agree on rules and their enforcement. Also we need to secure inter-node communications.
Stage 1. Organizations would use it to create _internal_ messaging systems, for employees/members only. At that stage it does not replace e-mail, and both systems are used alongside it. If it is mandated to be used for internal communication, this solves the problem of getting "Open this immediately!!!" e-mail claiming to come from your boss, but being in fact from scammers. It also solves the problem of e-mail from your colleagues getting into spam folder.
Stage 2. If your clients, suppliers, etc. start to use mnm, you can add them to your mnm network, and stop using e-mail in communication with them. When you reach this stage, you can severely reduce using of e-mail for your organization, at this point perhaps the only people who need e-mail are marketing, support, and perhaps developers (but the latter only for maillists).
3. mnm gets a critical mass, where it makes sense for organizations and projects start to offer mnm as an option to contact them, and later to require them. At this point "general public" starts to use mnm.
4. When it reaches critical mass among general population, e-mail can start to be phases out.
Don't know how realistic is this, and some design decisions of the mnm team seem counter-productive, but to me it does not sound completely crazy.
More here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
In your roadmap example, steps 1 and 2 can be done right now by maintaining trusted network lists for SMTP, so that employees can't be spammed by unapproved senders. And it can enforce TLS between those trusted networks for privacy.
Meanwhile the customer-service people can have both guarded @internal.bigcorp.com and open @bigcorp.com accounts, the latter for public communication.
That's a pattern that's already in use and works on existing infrastructure. Any new protocol will have to offer overwhelming benefits.
The only effective solution is to #banSMTP - i.e. block it on public networks.