Bug 268048 - Credentials disclosure and sending failure: Kmail connects to wrong SMTP server
Summary: Credentials disclosure and sending failure: Kmail connects to wrong SMTP server
Status: RESOLVED DUPLICATE of bug 255076
Alias: None
Product: kmail
Classification: Applications
Component: sending (show other bugs)
Version: 1.13.6
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-09 12:48 UTC by Szczepan Hołyszewski
Modified: 2011-05-01 14:03 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Szczepan Hołyszewski 2011-03-09 12:48:40 UTC
Version:           1.13.6 (using KDE 4.6.0) 
OS:                Linux

(Reason for major severity: security hole, credentials disclosed to wrong party)

When sending a message using an identity that uses a SMTP account other than the default, kmail connects to the default SMTP server instead, but tries to authenticate with username and password defined in the non-default SMTP account selected for the identity. This has two effects:

- email is not sent because SMTP authentication fails
- identity's SMTP account credentials are disclosed to the default SMTP server



Reproducible: Always

Steps to Reproduce:
1. Set up two SMTP accounts on different servers, let's call them a and b.
2. Set a as the default SMTP account.
3. Set up two identities, let's call them A and B.
4. Assign account a as sending account for identity A; assign account b as sending account for identity B.
5. Try sending mail using identity B.

Actual Results:  
Authentication failure and password disclosure because KMail uses credentials from account b but sends them to account a's SMTP server.

Expected Results:  
Account b's server should be used.

OS: Linux (i686) release 2.6.37-ARCH
Compiler: gcc
Comment 1 Szczepan Hołyszewski 2011-03-09 13:03:50 UTC
OK, this appears to be more complicated. It seems it has nothing to do with which SMTP account is set as default. Rather than that, it seems that the last used SMTP account "sticks" in some scenarios, including one when a message is not sent (e.g. rejected by spam filter) and the user attempts to re-send it from another identity.

The problem is, I don't really have any more time to investigate. What I have described here must suffice.
Comment 2 Christophe Marin 2011-05-01 14:03:35 UTC

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