If it works the way I'm thinking, probably a few hours of coding. I'm not really in any hurry to implement it though, since it requires SMTPUTF8 anyway and I'm not aware of any (open source) servers supporting it.
Oh, Dovecot's LMTP server should probably also support SMTPUTF8. I haven't really thought of that yet. Not sure how much work that is.
Anyway, as I mentioned, I very much don't look forward to implementing any downgrading. I think the downgrading belongs to SMTP server level, which luckily is outside Dovecot. So I think I'll implement the IMAP UTF8 support as a setting with 3 possible values:
a) No UTF8 support at all b) IMAP client required to support UTF8 extension, don't allow any clients not supporting it to do anything c) Just assume that the current non-UTF8 extension supporting IMAP clients can handle UTF8 headers in not-completely-broken way and just send them the UTF8 headers. In my few tests this appeared to work well enough.
On 7.1.2013, at 14.50, Abdulrahman I. ALGhadir aghadir@citc.gov.sa wrote:
How long do u think it will take?
-----Original Message----- From: Timo Sirainen [mailto:tss@iki.fi] Sent: 7/Jan/2013 3:46 PM To: Abdulrahman I. ALGhadir Cc: dovecot@dovecot.org Subject: Re: [Dovecot] Question about supporting EAI in Devecot
On 7.1.2013, at 14.36, Abdulrahman I. ALGhadir aghadir@citc.gov.sa wrote:
I would like to ask the staff of Devecot if they are planning (working) or supporting EAI (http://tools.ietf.org/wg/eai/) in the future versions?
My current plan is to implement it without support for downgrading. That would be almost trivial to implement I think.
Disclaimer: This message and its attachment, if any, are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender immediately and delete this message and its attachment, if any, from your system. You should not copy this message or disclose its contents to any other person or use it for any purpose. Statements and opinions expressed in this e-mail are those of the sender, and do not necessarily reflect those of the Communications and Information Technology Commission (CITC). CITC accepts no liability for damage caused by this email.