Bugzilla

There are a whole load of places in the IMAP code which deal with folder names and have special cases for handling MUTF-7 or UTF-8.
The patches in Bug 1687727 and Bug 1688782 act as a bit of a roadmap to such handling.
And Bug 771487 might be relevant too (issue with filter rules and MUTF-8) - I suspect there are a bunch of lurking edge-cases waiting there.

I _think_ an approach might be to make sure we always use UTF-8 IMAP folder names, and the only time MUTF-7 is used is way way down in the protocol level when talking to servers without UTF8=ACCEPT.

A small though experiment: imagine using an old (MUTF-7 only) IMAP server, and crafting some filter rules. If that IMAP server is upgraded to support UTF8=ACCEPT, will those filter rule destinations still be valid?

This is probably a part of a larger effort to make sure we've got well defined, canonical representations for paths (and folder URIs)... but got to start somewhere.
Other things to consider: path separators, percent encoding.

A good start would be to make sure we've got test coverage for all kinds of IMAP folder naming cases: nested folders with accented characters, non-latin languages, test servers with and without UTF8 support... without good unit tests, this kind of work is just regressions waiting to happen :-)

There are a whole load of places in the IMAP code which deal with folder names and have special cases for handling MUTF-7 or UTF-8.
The patches in Bug 1687727 and Bug 1688782 act as a bit of a roadmap to such handling.
And Bug 771487 might be relevant too (issue with filter rules and MUTF-8) - I suspect there are a bunch of lurking edge-cases waiting there.

I _think_ an approach might be to make sure we always use UTF-8 IMAP folder names, and the only time MUTF-7 is used is way way down in the protocol level when talking to servers without UTF8=ACCEPT. i.e. converting to/from MUTF-7 right down where IMAP commands are sent/received.

A small though experiment: imagine using an old (MUTF-7 only) IMAP server, and crafting some filter rules. If that IMAP server is upgraded to support UTF8=ACCEPT, will those filter rule destinations still be valid?

This is probably a part of a larger effort to make sure we've got well defined, canonical representations for paths (and folder URIs)... but got to start somewhere.
Other things to consider: path separators, percent encoding.

A good start would be to make sure we've got test coverage for all kinds of IMAP folder naming cases: nested folders with accented characters, non-latin languages, test servers with and without UTF8 support... without good unit tests, this kind of work is just regressions waiting to happen :-)

There are a whole load of places in the IMAP code which deal with folder names and have special cases for handling MUTF-7 or UTF-8.
The patches in Bug 1687727 and Bug 1688782 act as a bit of a roadmap to such handling.
And Bug 771487 might be relevant too (issue with filter rules and MUTF-7) - I suspect there are a bunch of lurking edge-cases waiting there.

I _think_ an approach might be to make sure we always use UTF-8 IMAP folder names, and the only time MUTF-7 is used is way way down in the protocol level when talking to servers without UTF8=ACCEPT. i.e. converting to/from MUTF-7 right down where IMAP commands are sent/received.

A small though experiment: imagine using an old (MUTF-7 only) IMAP server, and crafting some filter rules. If that IMAP server is upgraded to support UTF8=ACCEPT, will those filter rule destinations still be valid?

This is probably a part of a larger effort to make sure we've got well defined, canonical representations for paths (and folder URIs)... but got to start somewhere.
Other things to consider: path separators, percent encoding.

A good start would be to make sure we've got test coverage for all kinds of IMAP folder naming cases: nested folders with accented characters, non-latin languages, test servers with and without UTF8 support... without good unit tests, this kind of work is just regressions waiting to happen :-)