> The email protocol is simple and flexible. Ha, okay. I'm going to include actual emails in "the email protocol", because if you just count the network protocols you're not doing anything useful. Emails are anything but simple. They were born in the early days of the Internet, and no doubt time and the impossibility of predicting the future is responsible for how things turned out — but they are anything but simple.…
> Email messages are ASCII only. You can put non-ASCII characters into a header however. It looks like this: To me that is a good example of how email is flexible, and also simple. It's flexible because it could support non-ascii text strings, without changing a thing. It's simple because the protocol doesn't care what the subject says. It only cares that it's an ASCII string. That sounds like good engineering to me,…
I spent about 18 months on an email client project (was already 3 years in when I joined the team). I can tell you email is insane... so much more broken than you would expect (on all sides).
There is a reason many clients do "gmail" instead of "email". "Email" is a nasty barely functional ball of duct tape greased with WD-40 in the places it needs to go fast -- the fact that it works at all is breathtaking and only explained by the fact that it is one of the "killer features" of the internet.
The number of broken clients and servers is shocking and breathtaking. So you have to accept and expect bad data from everywhere. From the server directly, violating the imap spec, and in the body of the message violating all sanity. Yet, your users will see any failure as "this email client sucks" because the OTHER older email clients have already seen this idiocy and custom coded around it. Email clients end up being giant laundry lists of "if (act way 1)", "if created with (render 'right' way 2)"...
The reason new email clients are relatively slow to be created, and even fewer take off, is they are forced to deal with an insane clusterfuck of standards and corner cases to get to that 80% good enough mark -- or simply build out to one service at a time (we support gmail, hotmail and yahoo... etc).
There are 20+ RFCs you need to deal with the cover the spectrum of "basic" email with calendaring across a number of servers. That is just the "good" standard parts. On top of that you have the hundreds of server oddities that you need to handle else your email client will fail to get email off broken server X. Add to that the hundreds of rendering special cases you need to be aware of (ohh, this game from old outlook, so X means Y).
After you do all that, you have to deal with spam (both how servers tell you about it, how you show it, how you maintain it, etc) and an entire new set of oddities (very similar but simpler) for sending mail.
FastMail has an idea floating around that appears less terrible: http://jmap.io/ -- but I am blissfully out of that industry and simply don't care anymore.
EDIT: For the record, I agree with the article, email will be around for a long time, it is the "point of record" -- many of the "email killers" require your email address to sign up... so...