4 ms·

It looks great, but there's zero chance I'm going to replace my current SMTP with a new protocol no one (yet) uses. If there's a bug in all of this it's in layi

by gm 6y ago

It looks great, but there's zero chance I'm going to replace my current SMTP with a new protocol no one (yet) uses. If there's a bug in all of this it's in laying out very clearly how to ease into this. Especially in a world of hosted email providers where everyone is using Exchange, Google Email, and even cPanel to host email for organizations, and none of them have a big incentive to support this. EDIT: On thinking about it, I'd think this would have more chances if they phrased it as an augmentation of email's capabilities rather than an email killer.

user3939382 6y ago
The way to accomplish the change is to propose upgraded versions of SMTP, IMAP, et al that are backwards compatible with existing protocol versions. This way the infrastructure can update incrementally. If both clients in an email exchange and all the servers they're using in between support the new versions you get the features. iMessage manages this pretty well.
- throwawaysea 6y ago
  This is already the case for encrypted transport of email and is how email has been evolving all this time.
- livre 6y ago
  Another alternative is to support cross communication between email and this new protocol until it has enough users that supporting email stops being a priority. Then start offering new installations with email compatibility off by default until the majority of the users are on the new protocol, then keep email support only on lts releases and finally remove email completely. This way you avoid having to carry the baggage of email forever and having to support an old protocol full of backwards compatibility hacks. This is all in theory, in practice I doubt this will ever get close to replacing email.
  - chrisandchris 6y ago
    That works pretty well for IPv6, doesn‘t it (actually, it does not)? The problem with that approach is that as long as 0.01% still uses the old protocol, you can‘t get rid of it. And then you have a bag with the old and new protocol and maybe after 20 years you realize it‘s going to take another X years until you have at least some relevant adoption, as demonstrated with IPv6. If one is ever going to „replace“ email it happens on top of the existing protocols and not as a replacement.
    - livre 6y ago
      You make a great point. A very popular protocol or standard is never fully replaced. Either it continues existing next to the new thing (IPv4/IPv6) or gets an update while still having to deal with backwards compat (HTML, CSS). Whatever the case is we'll still be dealing with email in 20-30 years from now.
- ianai 6y ago
  Na. We’re talking about adding a protocol to a list of a handful which people use regularly. What you just said sounds like something I would have heard in the 90s about using email for legitimate purposes. Why do we need email when we have fax? (Granted fax still exists, but it’s no email killer.) This sort of thing could be deployed by people in addition to the other services. For a while and perhaps a long while it’ll be fringe. But if there’s enough utility to it then it may just catch on.
  - EricMausler 6y ago
    If support for both is going to be part of the plan, I do not suggest planning to drop support for email. Commit to supporting both or dont
- mortenjorck 6y ago
  There are two key requirements for anything that would actually supplant email: 1. Call the protocol "Email 2" 2. Build something that actually justifies the name I'm only half joking; the messaging around the protocol is almost as important as the protocol itself. iMessage is a good example of how to expose something like "Email 2" to the end user: as a seamless upgrade, indicated by a subtle UI element, when a client happens to negotiate the upgraded protocol with the server. Enabling incremental upgrades to infrastructure is critical, but strict backward-compatibility isn't necessarily so. As long as the architecture of the new protocol makes falling back to IMAP/SMTP straightforward when an upgraded client or server isn't available, Email 2 doesn't have to be able to talk directly to legacy. There's certainly a chicken-and-egg problem in driving enough server adoption to get client vendors to add support while driving enough client adoption to get server operators on board, but there's probably a sweet spot between making a clean enough break with legacy tech that it's more straightforward to implement, while making it conceptually similar enough that it can still plug into the same patterns.
- 0df8dkdf 6y ago
  I would recommend checking out wildduck https://wildduck.email https://wildduck.email, It is backward compatible, smtp, imap, pop3 and support unicode email as well, and it is REST API callable. So you can receive and send email.
samstave 6y ago
also, is SLS or E2EE an option? Why not a proxy through Signal as an option...?
deleted 6y ago
[deleted]
networkimprov 6y ago
Yes, I need to write an architecture/roadmap doc. Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379 https://news.ycombinator.com/item?id=25804869#25807379

by gm 6y ago

user3939382 6y ago

The way to accomplish the change is to propose upgraded versions of SMTP, IMAP, et al that are backwards compatible with existing protocol versions. This way the infrastructure can update incrementally. If both clients in an email exchange and all the servers they're using in between support the new versions you get the features. iMessage manages this pretty well.

throwawaysea 6y ago
This is already the case for encrypted transport of email and is how email has been evolving all this time.
livre 6y ago
Another alternative is to support cross communication between email and this new protocol until it has enough users that supporting email stops being a priority. Then start offering new installations with email compatibility off by default until the majority of the users are on the new protocol, then keep email support only on lts releases and finally remove email completely. This way you avoid having to carry the baggage of email forever and having to support an old protocol full of backwards compatibility hacks. This is all in theory, in practice I doubt this will ever get close to replacing email.
- chrisandchris 6y ago
  That works pretty well for IPv6, doesn‘t it (actually, it does not)? The problem with that approach is that as long as 0.01% still uses the old protocol, you can‘t get rid of it. And then you have a bag with the old and new protocol and maybe after 20 years you realize it‘s going to take another X years until you have at least some relevant adoption, as demonstrated with IPv6. If one is ever going to „replace“ email it happens on top of the existing protocols and not as a replacement.
  - livre 6y ago
    You make a great point. A very popular protocol or standard is never fully replaced. Either it continues existing next to the new thing (IPv4/IPv6) or gets an update while still having to deal with backwards compat (HTML, CSS). Whatever the case is we'll still be dealing with email in 20-30 years from now.
ianai 6y ago
Na. We’re talking about adding a protocol to a list of a handful which people use regularly. What you just said sounds like something I would have heard in the 90s about using email for legitimate purposes. Why do we need email when we have fax? (Granted fax still exists, but it’s no email killer.) This sort of thing could be deployed by people in addition to the other services. For a while and perhaps a long while it’ll be fringe. But if there’s enough utility to it then it may just catch on.
- EricMausler 6y ago
  If support for both is going to be part of the plan, I do not suggest planning to drop support for email. Commit to supporting both or dont
mortenjorck 6y ago
There are two key requirements for anything that would actually supplant email: 1. Call the protocol "Email 2" 2. Build something that actually justifies the name I'm only half joking; the messaging around the protocol is almost as important as the protocol itself. iMessage is a good example of how to expose something like "Email 2" to the end user: as a seamless upgrade, indicated by a subtle UI element, when a client happens to negotiate the upgraded protocol with the server. Enabling incremental upgrades to infrastructure is critical, but strict backward-compatibility isn't necessarily so. As long as the architecture of the new protocol makes falling back to IMAP/SMTP straightforward when an upgraded client or server isn't available, Email 2 doesn't have to be able to talk directly to legacy. There's certainly a chicken-and-egg problem in driving enough server adoption to get client vendors to add support while driving enough client adoption to get server operators on board, but there's probably a sweet spot between making a clean enough break with legacy tech that it's more straightforward to implement, while making it conceptually similar enough that it can still plug into the same patterns.
0df8dkdf 6y ago
I would recommend checking out wildduck https://wildduck.email https://wildduck.email, It is backward compatible, smtp, imap, pop3 and support unicode email as well, and it is REST API callable. So you can receive and send email.

samstave 6y ago

also, is SLS or E2EE an option? Why not a proxy through Signal as an option...?

deleted 6y ago

[deleted]

networkimprov 6y ago

Yes, I need to write an architecture/roadmap doc. Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379 https://news.ycombinator.com/item?id=25804869#25807379