I spent the better part of 5 years playing with IMAP. This is a huge step in the right direction but there’s a lot with email this is missing:
- Nobody reads or interacts with emails anymore, they use threads. Threading is one of the most impossibly hard challenges to solve and requires a thread-first view of the inbox.
- IMAP represents now a small minority of servers. ProtonMail may be embracing it but for actually interacting with mailservers, don’t expect good interoperability or fast interactions when working with the two big dogs (Exchange and GSuite)
- Similarly most mailservers don’t act in good faith, their rate limits for non-internal clients are ridiculously low for modern email, and the failure rate is surprisingly high for commands
- There is no real spec for IMAP (the article quotes 3501, but 4549 and 6531 are also “standards”), it’s a suggestion at best and every mailserver goes its own way. For example deleting a message does different things in Exchange and GSuite. GSuite has “labels” which are represented as IMAP folders but don’t always act like them.
- It’s unclear what the mailserver will accept. Valid MIME isn’t always going to get through
- Most email that’s important is business email nowadays. These are 80% Exchange. Exchange/365 tenants for the most part block IMAP (found this out the hard way) and Microsoft really wants to push Graph (just like they tried to push EWS). This manifests in weird ways like big angry red warnings on the dashboard if you try to enable IMAP, and automatically disabling it on new tenants, so most IT admins will refuse to turn it on even if you explain it’s just as secure.
- Remaining 20% are mostly GSuite. Google, as usual, is trying its hardest to create an email client monopoly for its users, and so there’s a $75000 annual fee for “security audits” by “vetted firms” regardless of how many real compliance certifications you have. They say this is for privacy and security but it’s just a gatekeeping fee and this is obvious due to the large number of email data abusers out there (looking at Unroll). There are even companies (Nylas) that run their whole business by speeding up the certification process and providing an API that works better than Google’s poorly documented own SDK. If you get through all of this your users are shown a consent screen where everything is unchecked by default, which sounds cool but basically means many of your users are going to login without knowing how to give consent to your email client.
Overall, the space is characterized by Google trying its hardest to kill any startups in the space and prevent innovation that could threaten their consumer monopoly, and Microsoft trying to keep people in their ecosystem by just changing their external API frequently to force competitors to rewrite their codebases constantly.
> Nobody reads or interacts with emails anymore, they use threads.
Not remotely true. Perhaps you're thinking about Gmail webmail users?
> and requires a thread-first view of the inbox.
Seeing how Sent messages, which aren't in the inbox, are typically part of threads - even that would not be enough...
> IMAP represents now a small minority of servers
Not sure what you're counting. If you're counting email users on the servers - Google and Outlook365 both support IMAP. If you're counting kinds of server _software_, then maybe, I have no idea.
> their rate limits for non-internal clients are ridiculously low for modern email
You mean, bandwidth rates, or rates of commands/second etc.?
Also, if by "modern email" you mean "email where people send large files" - that IMHO is a problem, and people just shouldn't do that. Same for other social media BTW. The amount of smartphone space wasted by dumb video clips your friends shared with you by WhatsApp or whatever is stupefying :-(
Anyway, people who try to use email to send and receive large files are kind of abusing the service. IMHO.
> - Most email that’s important is business email nowadays.
I don't think so. Or rather - maybe in the country you live in, and even then I doubt it.
> Valid MIME isn’t always going to get through
... and it doesn't help that so few clients can properly present, let alone generate, MIME messages other than with the most simple of structure. :-(
> Exchange/365 tenants for the most part block IMAP
AFAICT, most people who use MS services can use their publicly-available IMAP servers.
> the space is characterized by Google trying its hardest to kill etc.
(sigh) not surprising unfortunately. Monopolistic corporations gonna monopolize-coroprately I suppose.
>> Nobody reads or interacts with emails anymore, they use threads.
> Not remotely true. Perhaps you're thinking about Gmail webmail users?
Speaking for myself - I have threaded / conversation view in outlook on desktop and Android - and Gmail on Android.
>> and requires a thread-first view of the inbox.
> Seeing how Sent messages, which aren't in the inbox, are typically part of threads - even that would not be enough...
Both Gmail and Outlook show the whole thread / conversation regardless if only one mail (eg: latest reply) is "in" the inbox (and rest is "archived" for example).
This is via propiatary communication with the servers (Gmail / o365).
This is the work flow to replicate one way or another.
The very first thing I do anytime I set up a new email client is switch off threaded view so I can see the individual messages. I find it more hassle than it's worth. I prefer to keep specific messages in my inbox related to what I need to do (as my inbox is essentially my to do list) and just archive all other messages especially the meaningless replies which only add noise to the conversation. I shudder when I see other people's inboxes with threads of 100+ messages where they have to scroll and scroll to find the specific message they need. While I already have that specific message stored in my inbox for quick reference.
Threads don't prevent you from tagging individual messages despite your example of people not doing that and resorting to scrolling, so your solution of killing thread is strictly worse
- Nobody reads or interacts with emails anymore, they use threads. Threading is one of the most impossibly hard challenges to solve and requires a thread-first view of the inbox.
- IMAP represents now a small minority of servers. ProtonMail may be embracing it but for actually interacting with mailservers, don’t expect good interoperability or fast interactions when working with the two big dogs (Exchange and GSuite)
- Similarly most mailservers don’t act in good faith, their rate limits for non-internal clients are ridiculously low for modern email, and the failure rate is surprisingly high for commands
- There is no real spec for IMAP (the article quotes 3501, but 4549 and 6531 are also “standards”), it’s a suggestion at best and every mailserver goes its own way. For example deleting a message does different things in Exchange and GSuite. GSuite has “labels” which are represented as IMAP folders but don’t always act like them.
- It’s unclear what the mailserver will accept. Valid MIME isn’t always going to get through
- Most email that’s important is business email nowadays. These are 80% Exchange. Exchange/365 tenants for the most part block IMAP (found this out the hard way) and Microsoft really wants to push Graph (just like they tried to push EWS). This manifests in weird ways like big angry red warnings on the dashboard if you try to enable IMAP, and automatically disabling it on new tenants, so most IT admins will refuse to turn it on even if you explain it’s just as secure.
- Remaining 20% are mostly GSuite. Google, as usual, is trying its hardest to create an email client monopoly for its users, and so there’s a $75000 annual fee for “security audits” by “vetted firms” regardless of how many real compliance certifications you have. They say this is for privacy and security but it’s just a gatekeeping fee and this is obvious due to the large number of email data abusers out there (looking at Unroll). There are even companies (Nylas) that run their whole business by speeding up the certification process and providing an API that works better than Google’s poorly documented own SDK. If you get through all of this your users are shown a consent screen where everything is unchecked by default, which sounds cool but basically means many of your users are going to login without knowing how to give consent to your email client.
Overall, the space is characterized by Google trying its hardest to kill any startups in the space and prevent innovation that could threaten their consumer monopoly, and Microsoft trying to keep people in their ecosystem by just changing their external API frequently to force competitors to rewrite their codebases constantly.