The only thing that was changed is the following. So the guy who broke it will have to fix it.

 QString KStringHandler::obscure( const QString &str )
 {
   QString result;
+  const QChar *unicode = str.unicode();
   for ( uint i = 0; i < str.length(); ++i )
-    result += ( str.unicode()[ i ].unicode() < 0x20 ) ? str.unicode()[ i ] :
-        QChar( 0x1001F - str.unicode()[ i ] );
+    result += ( unicode[ i ].unicode() < 0x20 ) ? unicode[ i ] :
+        QChar( 0x1001F - unicode[ i ].unicode() );
 
   return result;
 }

If that change broke it, more than people updating from 3.1 would have noticed. Really, I double checked the code and I very much doubt the problem is in there.

Note that the kmail 3.1 code is this:

  for (uint i = 0; i < aStr.length(); i++)
    result += (aStr[i].unicode() < 0x20) ? aStr[i] :
      QChar(0x1001F - aStr[i].unicode());
  return result;

I just saved the password with KMail 1.5.4, copied the kmailrc to my HEAD test user and sent a test message. Worked fine.

Malte, do you still have the old kmailrc (before the update)? If not, do you still have access to KMail 1.5.4 and can save the password with this version and with KMail HEAD? Are the saved passwords equal?

Actually, yeah, it seems like Gentoo has a pretty genial KDEHOME handling :) I still have the old kmailrc lying around, so I did the following:

$ grep ^pass= ~/.kde3.1/share/config/kmailrc > ~/tmp/km31
$ grep ^pass= ~/.kdecvs/share/config/kmailrc > ~/tmp/km32
$ cmp ~/tmp/km3? && echo Huh?
Huh?

At this point I really had doubts about myself. So I went, backuped my 3.2 config and replaced it with the 3.1 one. And KMail gave me again:
| Sending failed:
| Authentication failed.
| Most likely the password is wrong.
| The server responded: "5.7.0 {mp026} Incorrect username or password"
| The message will stay in the 'outbox' folder until you either fix the
| problem (e.g. a broken address) or remove the message from the 'outbox'
| folder.
| The following transport protocol was used:
| GMX (Mailinglisten)

So, I'm not completely insane :) I'm currently digging deeper into this. I even tried to tcpdump the connection but it has SSL enabled. Lemme see what I'll find out...

Now, this gets very weird. Following facts:
1. This problem is 80% reproducable if I started my kmail with the 3.1 rc.
2. It happens in about 10% the times I use an already converted rc.
3. If it has once happened, it never happens again in a session.
4. It does not happen if I modified the kmailrc before conversion and removed either TLS or CRAM-MD5
5. I'm confused.
6. I'm not sure but I don't think its a server problem as it happened the first time a week ago and is still reproducable. Also because it happens only the first time I send a mail.

The transport in question is (without password):
| [Transport 4]
| auth=true
| authtype=CRAM-MD5
| encryption=TLS
| host=mail.gmx.net
| localHostname=
| name=GMX (Mailinglisten)
| pass=xxx
| port=25
| precommand=
| specifyHostname=false
| storepass=true
| type=smtp
| user=msquadrat@gmx.net

Btw, what do you think about base64-encoding the password? All those special characters look pretty fragile when I edit the file with an editor...

Point 4. indicates that your problem is related to #56319. CRAM-MD5 with TLS seems to be broken.


*** This bug has been marked as a duplicate of 56319 ***