Hm. Probably the fix to bug 323106 is somehow responsible, but that shouldn't affect passwords, only account names.

Ah, right. camel/providers/imap/camel-imap-store.c, ~ll 1372.. (imap_auth_loop):

		if (authtype)
			authenticated = try_auth (store, authtype->authproto, ex);
		else {
			response = camel_imap_command (store, NULL, ex,
						       "LOGIN %S %S",
						       service->url->user,
						       service->url->passwd);
			if (response) {
				camel_imap_response_free (store, response);
				authenticated = TRUE;
			}
		}

RFC 2060/3501 says password is plaintext, so change 

                         "LOGIN %S %S" 

to 

                         "LOGIN %S %s"

Makes no difference to non-ASCII paswords; they're broken anyway.

Yah, patching that string fixes it.

Hm - first time I've patched a live binary by hand. I guess changing strings doesn't really count, though.

this is the wrong fix as passwords are not confined to atom tokens, hence the %S in the first place. the patch that fixed the mailbox UTF-7 bug is broken in that it should not encode things which are not mailboxes (but it obviously is)

Right, yeah. The commit has:

	* camel-imap-command.c (imap_command_strdup_vprintf): Do the
        conversion from UTF-8 to IMAP-UTF-7 only just before sending a
	request. Do it also for %S formats, as that is what the CREATE
	command uses. But %S is used also for other commands (like LOGIN
	and LIST), so maybe we really would need a new format that would
	be used *only* for mailbox (folder) names, assuming it's only
	mailbox names that use the IMAP-UTF-7 encoding. Or is that what %F
	is intended for? But why then does CREATE use %S?

The docstring for camel_imap_command_start has:

 * @fmt can include the following %-escapes ONLY:
 *	%s, %d, %%: as with printf
 *	%S: an IMAP "string" (quoted string or literal)
 *	%F: an IMAP folder name

The reason CREATE (and RENAME, and LIST) use %S is that %F prepends the imap store's namespace, which can't be done (?) if the argument isn't an existing folder. So we need 3 %-escapes: IMAP-string, IMAP-folder-name, and IMAP-folder-name-that-already-has-the-namespace-prepended. Uses of %S in CREATE, RENAME, LIST would then be switched to use this third escape.

Created attachment 57118 [details] [review]
evo-imap-mailbox-utf7.patch

Maybe this will work. I think it's right to convert the second argument of LIST/LSUB to UTF-7, as it can contain non-ASCII mailbox naming characters -- and * and ? are unaffected by the conversion to UTF-7.

this looks like the kind of fix I was thinking of a few minutes ago when I responded to Partha's email poke on bug #323106

I think you missed a few cases of %S usage tho. There's 2 LIST commands in imap_connect_online() and your patch only fixes 1 of them, for example. Might be other places missed too.

Created attachment 57163 [details] [review]
evo-imap-mailbox-utf7.patch

Oh, yeah. I misunderstood how LIST worked.

There aren't any more, though: 

$ grep %S ./*.c
./camel-imap-command.c: *       %S: an IMAP "string" (quoted string or literal)
./camel-imap-command.c: * %S strings will be passed as literals if the server supports LITERAL+
./camel-imap-command.c: * and quoted strings otherwise. (%S does not support strings that
./camel-imap-command.c: * be converted to UTF-7 and processed like %S.
./camel-imap-store.c:                                                  "LOGIN %S %S",

And camel-imap-command.c isn't used anywhere else.

this patch looks right to me, altho I'd probably change %G to something more meaningful like %N (for Namespace) or %P (for Path)... I think I'm leaning toward %P since there are a few places where it's not used as a namespace (or "parent path")

Also observed downstream here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177513

This works for me. And the code is review too. Committed on head. Closing this bug.