KMail bug in HEAD/3.1.0 branch with TLS support

[Ingo Klöcker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 29 October 2002 05:34, George Staikos wrote:
>    There seems to be a bug in KMail right now, and I would personally
> consider it to be a "show stopper".  I say this because I dont' fully
> understand it, but it seems to lose track of the TLS setting.  This
> could potentially be very bad.  While it is actually to strong in my
> case, I wonder if in other cases it might be too weak.  Here is how
> it is reproduced for me:
>
> Launch kmail and use it only with identities that use TLS (for SMTP,
> POP3). Then try to send an email from an identity that doesn't use
> TLS.  In my case, this is because this server doesn't support TLS or
> SSL.  However KMail insists on using TLS, even though the
> configuration for the identity does not have TLS checked.  The result
> is a message box that says that TLS is not supported on the remote
> server.  If I shut down KMail, restart, then try resending before
> doing anything that uses TLS, it sends without any problems.

O.k., I checked what KMail does and didn't find an error (in KMail):

Codepath (everything in kmsender.cpp):
in KMSender::doSendMsg():
line 323 ff.: look for queued message (all messages are queued)
line 339 ff.: start sender process
line 352 ff.: check if the message has the X-KMail-Transport header set;
  if yes, use the transport specified by the header; else use default
  transport.
line 358 ff.: if the transport is different from the transport which was
  used for the last message (this is obviously the case when you send a
  message with your non-TLS identity after sending messages with TLS
  identities), then call
  KMSender::createSendProcFromString(...)
  line 543 ff.: get the information for the transport (either from the
    config file or directly from the pseudo-URL)
  line 572: mSendProc = new KMSendSMTP(...);
    in KMSendSMTP(...): mSender(sender), mInProcess(false), mSlave(0),..
  line 574: return 0;
line 370 ff.: connect some signals and optionally start precommand
line 389 ff.: mSendProc->start();
  for SMTP this simply emits started(true)
line 396: end of KMSender::doSendMsg()

signal started(true) -> KMSender::sendProcStarted(true)
lines 402-411 handle 'false'
line 412: call KMSender::doSendMsgAux()
  line 423: initialize mSendProc
  line 427: call mSendProc->send(currentMsg) (KMSendSMTP::send(...))
    line 934: get the transport information from mSender (which has been
      correctly initialized above)
    lines 937-975: build the query string for the kioslave (sender,
      recipients, subject, hostname)
    lines 977-981: set protocol (smtp or smtps for SSL), host and port
    lines 983-1007: if necessary set username and password for SMTP auth
    lines 1009-1015: (here TLS is handled, note that mSlave == 0)
  if (!mSlave || !mInProcess)
  {
    KIO::MetaData slaveConfig;
    slaveConfig.insert("tls", (ti->encryption == "TLS") ? "on" : "off");
    if (ti->auth) slaveConfig.insert("sasl", ti->authType);
    mSlave = KIO::Scheduler::getConnectedSlave(destination.url(), 
slaveConfig);
  }
...

AFAICS everything looks o.k.. So the bug is probably in the kioslave. 
Maybe an old kioslave is reused and the TLS flag isn't reset according 
to the information in slaveConfig. Could someone with knowledge about 
the SMTP kioslave please have a look at this? Aaron?

Regards,
Ingo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9wFw/GnR+RTDgudgRAonXAJsEj7JANrSyTeDym18MUyc08lcJEQCgkFUq
5IPoZh6p8lyYas7HeZ8kJg4=
=nvFY
-----END PGP SIGNATURE-----