(In reply to Alessandro Vesely from comment #0) > User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 > > Steps to reproduce: > > Open a message that contains non-ASCII header fields from a Courier-IMAP mailstore. > > > Actual results: > > Get a warning like: > Message 2211 appears to be a Unicode message and your E-mail reader did not enable Unicode support. Please use an E-mail reader that supports IMAP with UTF-8. Alessandro, where do you see this warning? This must be in your Courier log, right?. I have only tested with various non-ASCII mailbox names and not with internal non-ASCII headers. Can you provide an example email that has non-ASCII headers that I can test? (I'm not sure what these look like.) Anyhow, after working on this for probably much too long I have wondered as to the usefulness of all this. Testing with gmail and courier, it appears that even with UTF8=ACCEPT turned off you can still create and have mailbox names with any unicode character. The only difference is that they are encoded in mUTF7 instead of UTF8. So I don't see a lot of improvement here. Another thing is that the RFC https://tools.ietf.org/html/rfc6855#section-3 it states that "All IMAP servers that support "UTF8=ACCEPT" SHOULD accept UTF-8 in mailbox names...". I take this to mean that some servers may still accept and report mailbox name as mUTF7 even with UTF8=ACCEPT in effect. But it appears that gmail and courier (the only two I have found that really support UTF8=ACCEPT do report via LIST the mailbox names as UTF8 and accept UTF8 when mailbox is created, renamed and selected when in UTF8=ACCEPT mode. I do know, at least with gmail, that if you create a mailbox with a mUTF7 string when in UTF8=ACCEPT mode you will see in webmail the literal mUTF7 string and not the intended unicode string. See comment 40 above. So it seems that the lack of UTF8=ACCEPT support is a non-problem for gmail. Problems have only been reported for courier and often the "solution" is to switch to dovecot. So I'm asking if this complex and high-risk change is really need due to issues with one server type Courier? (In reply to Jorg K (CEST = GMT+2) from comment #2) > Seems like a larger job. Very true!
Bug 1571672 Comment 49 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Alessandro Vesely from comment #0) > User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 > > Steps to reproduce: > > Open a message that contains non-ASCII header fields from a Courier-IMAP mailstore. > > > Actual results: > > Get a warning like: > Message 2211 appears to be a Unicode message and your E-mail reader did not enable Unicode support. Please use an E-mail reader that supports IMAP with UTF-8. Alessandro, where do you see this warning? This must be in your Courier log, right?. I have only tested with various non-ASCII mailbox names and not with internal non-ASCII headers. Can you provide an example email that has non-ASCII headers that I can test? (I'm not sure what these look like.) Anyhow, after working on this for probably much too long I have wondered as to the usefulness of all this. Testing with gmail and courier, it appears that even with UTF8=ACCEPT turned off you can still create and have mailbox names with any unicode character. The only difference is that they are encoded in mUTF7 instead of UTF8. So I don't see a lot of improvement here. Another thing is that the RFC https://tools.ietf.org/html/rfc6855#section-3 it states that "All IMAP servers that support "UTF8=ACCEPT" SHOULD accept UTF-8 in mailbox names...". I take this to mean that some servers may still accept and report mailbox name as mUTF7 even with UTF8=ACCEPT in effect. But it appears that gmail and courier (the only two I have found that really support UTF8=ACCEPT) do report via LIST the mailbox names as UTF8 and accept UTF8 when mailbox is created, renamed and selected when in UTF8=ACCEPT mode. I do know, at least with gmail, that if you create a mailbox with a mUTF7 string when in UTF8=ACCEPT mode you will see in webmail the literal mUTF7 string and not the intended unicode string. See comment 40 above. So it seems that the lack of UTF8=ACCEPT support is a non-problem for gmail. Problems have only been reported for courier and often the "solution" is to switch to dovecot. So I'm asking if this complex and high-risk change is really needed due to issues with one server type Courier? (In reply to Jorg K (CEST = GMT+2) from comment #2) > Seems like a larger job. Very true!