3 ms·

How can this reach critical mass when people are already using email for a similar purpose?

mdpttt 6y ago
This was the first thing that came to my mind as well, but on the other hand this seems to solve some real issues. Is there some space for solving this issue by evolving/improving SMTP?
- jbverschoor 6y ago
  IETF / RFCs 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.
  - gm 6y ago
    True, when I read the description, it looked to me like a bundle of smtp, email rules config utility, spam filter, and email client, all in one package you cannot reconfigure.
- dsr_ 6y ago
  You can solve a bunch of SMTP problems by organizing people. 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.
  - TedDoesntTalk 6y ago
    i wouldn't have my organization join this cooperative. Why? Because accounts get compromised and spam gets sent. It just does, even with 2FA and NFC dongles and public/private keys. 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.
    - ruslan 6y ago
      This is called responsibility. Lack of respobsibility brought us to the point where noone cares about security seriously. Yes, we talk much about it, but in reality we don't give a damn about it because possible damage is usually inappreciable.
  - ruslan 6y ago
    Fidonet operated exactly the way you describe. I recall in 90th I used to run quite a large Fidonet node. I was responsible for my points' (users) behaviour - when someone violated rules by misbehaving in an echo conference it effected me as a boss node in first place, I had to execute the ban and brainwash negligent user. What's more, I had to introduce new and old users to fidonet policy and its updates regularily to make sure they understand the rules. This all worked pretty well and was widely accepted. Fidonet was incredibly popular in 90th. 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.
IlliOnato 6y ago
If I understand them correctly, they have in mind the following: 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.
- networkimprov 6y ago
  Excellent roadmap! \o/ More here: https://news.ycombinator.com/item?id=25804869#25807379 https://news.ycombinator.com/item?id=25804869#25807379 (I'm the author.)
- dingaling 6y ago
  But all that complexity of migration, when similar results can be achieved today using SMTP trust-lists and separate accounts. 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.
networkimprov 6y ago
Email is in deep trouble, due to the cybercrime crisis, in which SMTP plays a leading role, enabling phishing. The only effective solution is to #banSMTP - i.e. block it on public networks.

This was the first thing that came to my mind as well, but on the other hand this seems to solve some real issues. Is there some space for solving this issue by evolving/improving SMTP?

jbverschoor 6y ago
IETF / RFCs 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.
- gm 6y ago
  True, when I read the description, it looked to me like a bundle of smtp, email rules config utility, spam filter, and email client, all in one package you cannot reconfigure.
dsr_ 6y ago
You can solve a bunch of SMTP problems by organizing people. 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.
- TedDoesntTalk 6y ago
  i wouldn't have my organization join this cooperative. Why? Because accounts get compromised and spam gets sent. It just does, even with 2FA and NFC dongles and public/private keys. 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.
  - ruslan 6y ago
    This is called responsibility. Lack of respobsibility brought us to the point where noone cares about security seriously. Yes, we talk much about it, but in reality we don't give a damn about it because possible damage is usually inappreciable.
- ruslan 6y ago
  Fidonet operated exactly the way you describe. I recall in 90th I used to run quite a large Fidonet node. I was responsible for my points' (users) behaviour - when someone violated rules by misbehaving in an echo conference it effected me as a boss node in first place, I had to execute the ban and brainwash negligent user. What's more, I had to introduce new and old users to fidonet policy and its updates regularily to make sure they understand the rules. This all worked pretty well and was widely accepted. Fidonet was incredibly popular in 90th. 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.

IlliOnato 6y ago

If I understand them correctly, they have in mind the following: 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.

networkimprov 6y ago
Excellent roadmap! \o/ More here: https://news.ycombinator.com/item?id=25804869#25807379 https://news.ycombinator.com/item?id=25804869#25807379 (I'm the author.)
dingaling 6y ago
But all that complexity of migration, when similar results can be achieved today using SMTP trust-lists and separate accounts. 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.

networkimprov 6y ago

Email is in deep trouble, due to the cybercrime crisis, in which SMTP plays a leading role, enabling phishing. The only effective solution is to #banSMTP - i.e. block it on public networks.