From kmail-devel  Thu Aug 31 00:31:11 2000
From: Don Sanders <sanders () kde ! org>
Date: Thu, 31 Aug 2000 00:31:11 +0000
To: kmail-devel
Subject: Re: Bug 7229 again...sorry
X-MARC-Message: https://marc.info/?l=kmail-devel&m=96768151921576

Please try the following patch to kmail/kmacctexppop.cpp

diff -u -b -r1.31 kmacctexppop.cpp
--- kmacctexppop.cpp    2000/08/24 15:03:37     1.31
+++ kmacctexppop.cpp    2000/08/31 00:25:55
@@ -422,13 +422,13 @@
   QStringList::Iterator curId = msgIdsAwaitingProcessing.begin();
   QStringList::Iterator curUid = msgUidsAwaitingProcessing.begin();
 
-  if (mUseSSL) {
-    prefix = "pop3s://" + mLogin + ":" + decryptStr(mPasswd) + "@" + mHost
-    + ":" + QString("%1").arg(mPort);
-  } else {
-    prefix = "pop3://" + mLogin + ":" + decryptStr(mPasswd) + "@" + mHost
-    + ":" + QString("%1").arg(mPort);
-  }
+  prefix = KURL::encode_string( mLogin ) + ":" +
+          KURL::encode_string(decryptStr(mPasswd)) + "@" + mHost  + ":" +
+          QString("%1").arg(mPort);
+  if (mUseSSL)
+      prefix = "pop3s://" + prefix;
+  else
+      prefix = "pop3://" + prefix;
 
   while (cur != msgsAwaitingProcessing.end()) {
     // note we can actually end up processing events in processNewMsg

BFN,
Don.

On Thu, 31 Aug 2000, Mark Roberts wrote:
> Hi,
>
> I don't know what I was thinking of when I tried to substitute %100 for @
> (it was very late at night), but I have just tried with %40 and it worked
> fine. If there is a method anywhere that converts such symbols into escape
> sequences, it would be great if we could pass the user name through it. It
> would make things less confusing for users. I am just finding my feet with
> KDE development at the moment, but if I come up with the answer I will
> post.
>
> Best regards,
> Mark Roberts.
>
> On Sat, 26 Aug 2000, George Staikos wrote:
> > Can we just do % encoding on the values we get, or is this not taken care
> > of in the IOSlaves ?  I'm sure we could fix it there too though.....  Any
> > suggestions?  Anyone started work on this yet?  It sounds pretty
> > crucial...
> >
> > On Thu, 24 Aug 2000, Mark Roberts wrote
> >
> > > Hi,
> > >
> > > I see that bug 7229 was discussed from 2nd to 5th of August. I have a
> > > similar problem.
> > >
> > > To be clear, bug 7229 was that because the account name of a POP3
> > > account has to comply with the standard for URLs, it was impossible to
> > > retrieve mail from GMX. The solution appears to be that the bug
> > > reporter changed the user name format and was able to get around it. It
> > > appears to be that no one thought it was a bug.
> > >
> > > I have an account at taurine@genie.co.uk which cannot be logged in to
> > > with a different user name by POP3. KMail 1.0.29.2 didn't have a
> > > problem with this, but the 1.1.90 does have this problem. I have looked
> > > at the source and found the reason for the problem, a few lines in
> > > kmacctexppop.cpp:
> > >
> > > if (mUseSSL) {
> > >     text = "spop3://" + mLogin + ":" + decryptStr(mPasswd) + "@" +
> > >             mHost + ":" + QString("%1").arg(mPort) + "/index";
> > >   } else {
> > >     text = "pop3://" + mLogin + ":" + decryptStr(mPasswd) + "@" +
> > >             mHost + ":" + QString("%1").arg(mPort) + "/index";
> > >   }
> > >   KURL url = text;
> > >   if ( url.isMalformed() ) {
> > >     QMessageBox::critical(0, i18n("Kioslave Error Message"),
> > > 			  i18n("Source URL is malformed") );
> > >     return;
> > >   }
> > >
> > > Is my email account truly to blame, or is the method used by KMail to
> > > retrieve email limited? Does the POP3 standard state that POP3 accounts
> > > shouldn't have @ characters? Is there any other way around it? I
> > > thought of the way spaces can be specified in URLs as the escape
> > > sequence %20, but %100 to replace @ didn't work for me - though my hex
> > > could be off?
> > >
> > > Surely this is quite a widespread problem? I would imagine my rogue
> > > account is being provided to my ISP as part of a virtual-ISP
> > > arrangement. There must be a lot of current KMail 1.0.x users that will
> > > be affected.
> > >
> > > Best regards,
> > > Mark Roberts.