5 ms·

I find very interesting how the author describes some of the shortcomings of IMAP. The article seems like a nice starting point for requirements to create a new

I find very interesting how the author describes some of the shortcomings of IMAP. The article seems like a nice starting point for requirements to create a new email protocol. Like the author, for years i've been bothered by email, but as someone who has been maintaining mail servers for 20+ years my biggest issue is the server side of things. SMTP, POP and IMAP have served their purpose way beyond their original scope. I think going to the drawing board and coming up with a replacement is long overdue.

dmm 11y ago
I think fastmail has proposed jmap as a replacement for imap: http://jmap.io/ http://jmap.io/
- vpeters25 11y ago
  From JMAP description on github: > It aims to be compatible with the IMAP data model, Unlike this project, I think user requirements should drive the protocol's design, not a need to be compatible with SMTP/IMAP.
  - rgbrgb 11y ago
    Compatibility with the rest of the network is a user requirement.
    - brongondwana 11y ago
      Yes, this. You need to remain compatible with the rest of the world. IMAP plus every extension in the world isn't even that awful, if everyone supported all of them. The problem is that they don't, so you have massive complexity of servers to support.
    - vpeters25 11y ago
      It should not be, that's the main premise of my idea: create a new email protocol that completely replaces both SMTP and IMAP based on actual use cases instead of being constrained by 40+ years of legacy protocols and extensions. Client and servers using this protocol would not be required to implement SMTP/POP/IMAP at all, bridge services could be built for that.
      - NeutronBoy 11y ago
        It sounds like a good decision, but you've just replaced protocol complexity for implementation complexity. At least a single group of designers and programmers can work through protocol complexity. Implementation complexity is going to impact everyone who tries to implement it - any many of them will just give up.
jimktrains2 11y ago
I started typing out the requirements[0] I'd want as a user. It's only a start and doesn't have any implementation, but any discussion would be appreciated! I wanted to focus initial on the things I hated as a receiver: spam filters (too many false-positives that don't correct when I report them as such), dropped messages (I cannot get messages from http://www.eternal-september.org/ http://www.eternal-september.org/ on gmail because of reasons only $DIETY could extract from google.), lack of encryption and authentication. [0]: https://github.com/jimktrains/email_ng https://github.com/jimktrains/email_ng (For IRC just use the same channel i registered for discussion on a new http (freenode @ #http_ng) (https://github.com/jimktrains/http_ng https://github.com/jimktrains/http_ng)
- simoncion 11y ago
  > ...lack of encryption and authentication. PGP (or the MSFT-specific equivalent) handles this. [0] I know that people love to pile hate on the UX of PGP, but Engimail has worked perfectly fine for me for ages. [0] Yes, I know that PGP doesn't -and can't- encrypt addressing information. We could address a big chunk of that by creating informal groups of sysadmins who configure their email servers to only speak over TLS-encrypted channels to other servers and clients.
  - jimktrains2 11y ago
    Yes, but I can't even get technical friends to use PGP:-\ I'm proposing it be tied more tightly into the protocol. Some of which is so that there is infrastructure to "vouch" for a sender address (for a period of time) so that they can send you things that would bypass spam checks. (Think password resets, or account notices from a bank).
tjohns 11y ago
I get a feeling that this is what the Nylas N1 folks are doing with their sync server. They created their own JSON protocol and documented it surprisingly thoroughly, given that their desktop mail client is the only implementer right now: https://nylas.com/docs/ https://nylas.com/docs/

dmm 11y ago

I think fastmail has proposed jmap as a replacement for imap: http://jmap.io/ http://jmap.io/

vpeters25 11y ago
From JMAP description on github: > It aims to be compatible with the IMAP data model, Unlike this project, I think user requirements should drive the protocol's design, not a need to be compatible with SMTP/IMAP.
- rgbrgb 11y ago
  Compatibility with the rest of the network is a user requirement.
  - brongondwana 11y ago
    Yes, this. You need to remain compatible with the rest of the world. IMAP plus every extension in the world isn't even that awful, if everyone supported all of them. The problem is that they don't, so you have massive complexity of servers to support.
  - vpeters25 11y ago
    It should not be, that's the main premise of my idea: create a new email protocol that completely replaces both SMTP and IMAP based on actual use cases instead of being constrained by 40+ years of legacy protocols and extensions. Client and servers using this protocol would not be required to implement SMTP/POP/IMAP at all, bridge services could be built for that.
    - NeutronBoy 11y ago
      It sounds like a good decision, but you've just replaced protocol complexity for implementation complexity. At least a single group of designers and programmers can work through protocol complexity. Implementation complexity is going to impact everyone who tries to implement it - any many of them will just give up.

jimktrains2 11y ago

I started typing out the requirements[0] I'd want as a user. It's only a start and doesn't have any implementation, but any discussion would be appreciated! I wanted to focus initial on the things I hated as a receiver: spam filters (too many false-positives that don't correct when I report them as such), dropped messages (I cannot get messages from http://www.eternal-september.org/ http://www.eternal-september.org/ on gmail because of reasons only $DIETY could extract from google.), lack of encryption and authentication. [0]: https://github.com/jimktrains/email_ng https://github.com/jimktrains/email_ng (For IRC just use the same channel i registered for discussion on a new http (freenode @ #http_ng) (https://github.com/jimktrains/http_ng https://github.com/jimktrains/http_ng)

simoncion 11y ago
> ...lack of encryption and authentication. PGP (or the MSFT-specific equivalent) handles this. [0] I know that people love to pile hate on the UX of PGP, but Engimail has worked perfectly fine for me for ages. [0] Yes, I know that PGP doesn't -and can't- encrypt addressing information. We could address a big chunk of that by creating informal groups of sysadmins who configure their email servers to only speak over TLS-encrypted channels to other servers and clients.
- jimktrains2 11y ago
  Yes, but I can't even get technical friends to use PGP:-\ I'm proposing it be tied more tightly into the protocol. Some of which is so that there is infrastructure to "vouch" for a sender address (for a period of time) so that they can send you things that would bypass spam checks. (Think password resets, or account notices from a bank).

tjohns 11y ago

I get a feeling that this is what the Nylas N1 folks are doing with their sync server. They created their own JSON protocol and documented it surprisingly thoroughly, given that their desktop mail client is the only implementer right now: https://nylas.com/docs/ https://nylas.com/docs/