Thanks for your suggestions Joachim! This is why I wrote that blog entry in the first place: To get some high-quality feedback.
I think IMAP could be replaced independently of SMTP. You could conceivable replace an IMAP server with a reMAP server and not affect the rest of the mail ecosystem. SMTP will likely not die for another hundred years.
1. I know about the OAuth problems. Do you think we'll see a more secure solution in the next few years?
2. Is there an easy way to validate UTF-8ness? Happy to hear suggestions.
3. I know about THREAD and SEARCH and IDLE but find them clunky. Under the assumption that we're replacing IMAP with something RESTful you might as well get those ones right.
Happy to take this offline as well - my email is on my HP
First off, thanks for taking this well. It was a bit of a rant, even if it was toned down from the first version. Sorry.
We agree SMTP will be around forever; but how do you plan on abolishing MIME then? Your system will have to handle it, no matter what. Do you want to push MIME handling to the server? IMAP already does that, there's nothing revolutionary about that.
Due to the special structure, it's usually possible to distinguish UTF-8 from other 8-bit text. The tricky part is what to do with unmarked non-UTF-8 8-bit text - it could be pretty much anything. Mutt, for instance, allows the user to configure this according to what the user expects to see. Quoting the manual,
For example, Japanese users might prefer this:
set assumed_charset="iso-2022-jp:euc-jp:shift_jis:utf-8"
There is a lot more information about such things on the Mutt site. Basically, Mutt tries to parse the headers/message according to a specific character set and falls back to the next one if that fails.
I probably wouldn't trust my e-mail to a protocol that was only a few years old. I don't anticipate any new security protocols with significant uptake either; "serious" stuff already uses SSL/TLS plus an authentication method (passwords/certificates/SASL), and the web crowd is unlikely to replace that (OAuth is about weakening security in a controlled way, not replacing SSL.)
And yeah, parts of IMAP are clunky. But that's not enough reason to rip-and-replace it.
It's easy to validate UTF-8. The danger is if other implementations crop up that are more permissive and your users are complaining that they can't get mail from those people. I think you could probably manage to avoid that, but I don't know if it would really be preferable. I want to claim that in asia and europe there are some widely used non-unicode encodings used.
Comments
Thanks for your suggestions Joachim! This is why I wrote that blog entry in the first place: To get some high-quality feedback.
I think IMAP could be replaced independently of SMTP. You could conceivable replace an IMAP server with a reMAP server and not affect the rest of the mail ecosystem. SMTP will likely not die for another hundred years.
1. I know about the OAuth problems. Do you think we'll see a more secure solution in the next few years?
2. Is there an easy way to validate UTF-8ness? Happy to hear suggestions.
3. I know about THREAD and SEARCH and IDLE but find them clunky. Under the assumption that we're replacing IMAP with something RESTful you might as well get those ones right.
Happy to take this offline as well - my email is on my HP
First off, thanks for taking this well. It was a bit of a rant, even if it was toned down from the first version. Sorry.
We agree SMTP will be around forever; but how do you plan on abolishing MIME then? Your system will have to handle it, no matter what. Do you want to push MIME handling to the server? IMAP already does that, there's nothing revolutionary about that.
Due to the special structure, it's usually possible to distinguish UTF-8 from other 8-bit text. The tricky part is what to do with unmarked non-UTF-8 8-bit text - it could be pretty much anything. Mutt, for instance, allows the user to configure this according to what the user expects to see. Quoting the manual,
There is a lot more information about such things on the Mutt site. Basically, Mutt tries to parse the headers/message according to a specific character set and falls back to the next one if that fails.I probably wouldn't trust my e-mail to a protocol that was only a few years old. I don't anticipate any new security protocols with significant uptake either; "serious" stuff already uses SSL/TLS plus an authentication method (passwords/certificates/SASL), and the web crowd is unlikely to replace that (OAuth is about weakening security in a controlled way, not replacing SSL.)
And yeah, parts of IMAP are clunky. But that's not enough reason to rip-and-replace it.
It's easy to validate UTF-8. The danger is if other implementations crop up that are more permissive and your users are complaining that they can't get mail from those people. I think you could probably manage to avoid that, but I don't know if it would really be preferable. I want to claim that in asia and europe there are some widely used non-unicode encodings used.