Bug#273281: About your bug: "kmail: Non-ASCII password breaks SMTP and IMAP authentication" on the Debian BTS
On Sat, Feb 17, 2007 at 11:55:28PM +0100, Ana Guerrero wrote:
> We (the Debian Qt/KDE team) are trying to update the bug status of some
> old bugs in the BTS.
Hear, hear! :-) Great to see someone finally take care.
> You filed the bug
> #273281 "kmail: Non-ASCII password breaks SMTP and IMAP authentication"
> some time ago, you can read the bug report at:
> We are sorry if nobody responded when you filed the bug, KDE has gotten more bugs
> in the past years than the maintainers could handle. We are trying to fix this now,
> but we need your help. So please respond to this mail and tell us if:
> - you are still experiencing this bug (adding in what version)
> - the bug was already fixed,
I'm no longer using KDE, nor kmail. But I can still reproduce it with
kmail 4:3.3.2-3, the version in Sarge. Unfortunately I still have no
newer Debian system at hand; as soon as I've upgraded my desktop to
Etch, I'm willing to test again.
> - or if you have extra information on how reproduce this bug.
Hmmm. Actually I don't know if there exist IMAP authentication
mechanisms that can handle non-ascii passwords.
Here's my setup: I'm running a private IMAP server with PAM login, that
is, the IMAP password is my real user password at the server. Both my
desktop account and the server account use an iso8859 locale (de_DE@euro
and en_GB, respectively). -- Does kmail honour the environment in that
To diagnose the problem a little, I've disabled SSL in kmail and snooped
the IMAP traffic while attempting a login. It seems that kmail sends
the password UTF8-encoded. (And, by the way, as a quoted string, thus
violating the IMAP spec which demands a literal for 8-bit character
data, see section 4.3 of RFC 3501.)
Mutt works fine; apparently it sends the password as latin1, matching my
For now I'm leaving the bug closed. I'll reopen it if I can reproduce
it with Etch and no one has objected.