5 ms·

I clicked on this with a lot of hope — alas, this only seems to address the "mailbox access" part of E-mail. I think that part actually works fairly well today

by jwr 8y ago

I clicked on this with a lot of hope — alas, this only seems to address the "mailbox access" part of E-mail. I think that part actually works fairly well today (not optimally, but well enough in practice). The part that really needs fixing is SMTP.

Aissen 8y ago
It actually addresses email submission, even if it doesn't cover server-to-server SMTP.
jolmg 8y ago
> I think that part actually works fairly well today (not optimally, but well enough in practice). I haven't done much with IMAP, but I did setup a watcher for my mailboxes that uses the IDLE extension. I consider it a flaw that I need to create a separate connection, each needing their own session, for each folder I want to watch simultaneously. Servers understandably limit the amount of simultaneous connections you can have, so that limits the amount of folders you can watch simultaneously. I don't know if JMAP fixes that, and I don't know if I'd prefer JMAP over IMAP as a protocol, but there are things that could be better with IMAP. > The part that really needs fixing is SMTP. What's wrong with SMTP?
- hsk823 8y ago
  Being unauthenticated as a default certainly doesn't jive with modern security practices.
  - jolmg 8y ago
    SMTP is the protocol that's used to route email between servers. How is Fastmail supposed to authenticate with Gmail or Yahoo with Hotmail? Better yet, how is a new mail server in the internet supposed to authenticate with all existing mail servers? Really, authentication for all uses of SMTP doesn't make sense.
    - closeparen 8y ago
      If only there were infrastructure and standards for asserting ownership over domain names.
      - crest 8y ago
        Do you really want to put the power to block mails into DNSSEC the PKI operators?
jcranmer 8y ago
IMAP is a really broken protocol; I'd characterize it as a database synchronization protocol that wasn't designed to be one. You need to rely on certain extensions to have a hope of being bug-free [1], and even those can be problematic (UIDVALIDITY changed, gotta clear your entire inbox!). [1] The IMAP protocol used to rely heavily on message sequence numbers, where each message in the folder was numbered sequentially from 1-N, and deleting messages caused all subsequent messages to have their number decremented by one. But you can have multiple connections active on the same mailbox, and you can't always immediately notify the other connections of when things get deleted, so every connection can have a slightly different mapping. So everyone uses UIDs now, which are guaranteed to be unique, until the server feels like deleting them all and restarting from scratch (i.e., updating UIDVALIDITY), so every message has a different UID now.
- sdegutis 8y ago
  Where UID is used now sounds like a good use case for UUIDs (or GUIDs?) that don't ever change.
  - jcranmer 8y ago
    I don't specifically know the history of IMAP, particularly IMAP UID, but the semantics of UID to me implies that it was originally specified to permit its implementation as the file offsets into the mbox files that backed the store, and I believe some IMAP servers implemented it that way. Some IMAP server implementations have a custom attribute they use to indicate a globally-unique message ID.
- raimue 8y ago
  The UIDVALIDITY is actually a great design. IMAP servers will usually store the UID mapping in some kind of index that is used even across restarts. Therefore in normal operation this is not a problem. When did you encounter problems with this in every day use? If the UIDs were not allowed to change, you would run into practical problems on edge cases. What if you switched your IMAP server implementation? What if the index files on server side got corrupt and you had to rebuild them? What if you had a fatal disk failure and had to restore an older backup? Mismatching UIDs would be even worse than a way to indicate to the client that the previously retrieved UIDs and associated messages are no longer valid. UIDVALIDITY is basically just a way for cache invalidation.
hsk823 8y ago
If your inbox is say, 50 gigs. 100 gigs, larger, emails from the early 90s until today, IMAP as it's applied today is definitely broken for those sized mailboxes. The problem with email for the last few decades is that it has not scaled as our storage use as scaled expotentially up, message size limits have been low, and deliverability issues have gotten worse, not better.
evilotto 8y ago
The other part that is really lacking is security, in particular 2fa. The proposed standard says that obtaining credentials is out of scope, which means it will remain in the realm of vendor-specific implementations.
- tracker1 8y ago
  I'd guess that you'd get a token that gets added as an `Authorization: bearer <token>` header in practice for most implementations. The specifics of the auth and token itself may vary though. Edit: Though having a dedicated /auth/login path that takes a JSON post with {username,passphrase,2facode,...} could be readily defined where any of the above parameters are optional. The response being a token that's used as the previously mentioned authorization header.

by jwr 8y ago

Aissen 8y ago

It actually addresses email submission, even if it doesn't cover server-to-server SMTP.

jolmg 8y ago

> I think that part actually works fairly well today (not optimally, but well enough in practice). I haven't done much with IMAP, but I did setup a watcher for my mailboxes that uses the IDLE extension. I consider it a flaw that I need to create a separate connection, each needing their own session, for each folder I want to watch simultaneously. Servers understandably limit the amount of simultaneous connections you can have, so that limits the amount of folders you can watch simultaneously. I don't know if JMAP fixes that, and I don't know if I'd prefer JMAP over IMAP as a protocol, but there are things that could be better with IMAP. > The part that really needs fixing is SMTP. What's wrong with SMTP?

hsk823 8y ago
Being unauthenticated as a default certainly doesn't jive with modern security practices.
- jolmg 8y ago
  SMTP is the protocol that's used to route email between servers. How is Fastmail supposed to authenticate with Gmail or Yahoo with Hotmail? Better yet, how is a new mail server in the internet supposed to authenticate with all existing mail servers? Really, authentication for all uses of SMTP doesn't make sense.
  - closeparen 8y ago
    If only there were infrastructure and standards for asserting ownership over domain names.
    - crest 8y ago
      Do you really want to put the power to block mails into DNSSEC the PKI operators?

jcranmer 8y ago

IMAP is a really broken protocol; I'd characterize it as a database synchronization protocol that wasn't designed to be one. You need to rely on certain extensions to have a hope of being bug-free [1], and even those can be problematic (UIDVALIDITY changed, gotta clear your entire inbox!). [1] The IMAP protocol used to rely heavily on message sequence numbers, where each message in the folder was numbered sequentially from 1-N, and deleting messages caused all subsequent messages to have their number decremented by one. But you can have multiple connections active on the same mailbox, and you can't always immediately notify the other connections of when things get deleted, so every connection can have a slightly different mapping. So everyone uses UIDs now, which are guaranteed to be unique, until the server feels like deleting them all and restarting from scratch (i.e., updating UIDVALIDITY), so every message has a different UID now.

sdegutis 8y ago
Where UID is used now sounds like a good use case for UUIDs (or GUIDs?) that don't ever change.
- jcranmer 8y ago
  I don't specifically know the history of IMAP, particularly IMAP UID, but the semantics of UID to me implies that it was originally specified to permit its implementation as the file offsets into the mbox files that backed the store, and I believe some IMAP servers implemented it that way. Some IMAP server implementations have a custom attribute they use to indicate a globally-unique message ID.
raimue 8y ago
The UIDVALIDITY is actually a great design. IMAP servers will usually store the UID mapping in some kind of index that is used even across restarts. Therefore in normal operation this is not a problem. When did you encounter problems with this in every day use? If the UIDs were not allowed to change, you would run into practical problems on edge cases. What if you switched your IMAP server implementation? What if the index files on server side got corrupt and you had to rebuild them? What if you had a fatal disk failure and had to restore an older backup? Mismatching UIDs would be even worse than a way to indicate to the client that the previously retrieved UIDs and associated messages are no longer valid. UIDVALIDITY is basically just a way for cache invalidation.

hsk823 8y ago

If your inbox is say, 50 gigs. 100 gigs, larger, emails from the early 90s until today, IMAP as it's applied today is definitely broken for those sized mailboxes. The problem with email for the last few decades is that it has not scaled as our storage use as scaled expotentially up, message size limits have been low, and deliverability issues have gotten worse, not better.

evilotto 8y ago

The other part that is really lacking is security, in particular 2fa. The proposed standard says that obtaining credentials is out of scope, which means it will remain in the realm of vendor-specific implementations.

tracker1 8y ago
I'd guess that you'd get a token that gets added as an `Authorization: bearer <token>` header in practice for most implementations. The specifics of the auth and token itself may vary though. Edit: Though having a dedicated /auth/login path that takes a JSON post with {username,passphrase,2facode,...} could be readily defined where any of the above parameters are optional. The response being a token that's used as the previously mentioned authorization header.