Bug 1239

KMail is way too complex to configure. :(

I never had that specific problem with KMail, since the 3.5.x days. If I recall correctly, users have to carefully match identities in the Receiving accounts. I believe the Receiving Identity always defaults to the default. Been a long time since I set up all of my accounts but I DO remember I needed to configure Identities and Accounts twice as they seem to interact.

(In reply to comment #1)
> KMail is way too complex to configure. :(
> 
> I never had that specific problem with KMail, since the 3.5.x days. If I recall
> correctly, users have to carefully match identities in the Receiving accounts.
> I believe the Receiving Identity always defaults to the default. Been a long
> time since I set up all of my accounts but I DO remember I needed to configure
> Identities and Accounts twice as they seem to interact.

By "Identities", do you mean Kmail -> Settings -> Identities, or are you referring to the "Account Name" field in the account settings?

If you're referring to the former, I'd think it would be enough to have the email address set to whichever you have setup as the normal default sending address, then have an email alias for all your secondary (non-default) adresses. This is the way I have my Kmail setup. Requiring to have a separate Identity for each sending address gets way too complex, especially with the GPG key selection issue I reported awhile back (I can't remember the bug number, it's the one where Kmail won't let me select a key, so I have to manually specify the key fingerprint in the Identities config file with Kmail closed).

If I remember correctly, the Identities and Accounts areas have to be configured twice, which is nuts.

First configure an Indentity. Then configure an Account. Why the two are treated uniquely I don't know.

In Accounts -> Receiving -> Modify, be sure to configure the correct Identity. Way down at the bottom.

Configure Accounts -> Sending.

Then return to Identities -> Modify -> Advanced. In Special Transport, select the correct Account SMTP.

Whoever designed this smoked some strong rope.

(In reply to comment #3)
> If I remember correctly, the Identities and Accounts areas have to be
> configured twice, which is nuts.
> 
> First configure an Indentity. Then configure an Account. Why the two are
> treated uniquely I don't know.
> 
> In Accounts -> Receiving -> Modify, be sure to configure the correct Identity.
> Way down at the bottom.
> 
> Configure Accounts -> Sending.
> 
> Then return to Identities -> Modify -> Advanced. In Special Transport, select
> the correct Account SMTP.
> 
> Whoever designed this smoked some strong rope.

Yeah. I would've never though of a simple SMTP account as being a "special" transport. Maybe if we made an "ESMTP" ("Enhanced" SMTP) or the likes, but certainly not Gmail's ;-)

This definitely should take priority over by other suggestion (see bug 1240), as having separate configs for sending and receiving is much more easily dealt with than having to explain to your boss why you sent your email from hotbabe@example.com instead of myname@example.com (luckily wasn't what I had done, but was still somewhat embarrassing).

Kris, do you still consider this a bug or a duplicate of bug report 1240?

(In reply to comment #5)
> Kris, do you still consider this a bug or a duplicate of bug report 1240?

1240 is an entirely separate thing -- it deals with rearranging the settings in a more sensible way, while this bug (1239) deals with ensuring that replies to emails get sent from the correct address.

Okay, let me rephrase. :)

The problem is "resolvable" after a user understands the quirky (awful design) relationship between Identities and Accounts. Some folks would consider that a user error or knowledge problem rather than a bug.

My perspective is I don't see how this can be fixed without redesigning the interface, which leads to bug report 1240, which is what I meant. Possibly some kind of "intelligence" could be added to the code to try to use the correct transport rather than just using the default.

I use KMail but I never liked the way the Identities and Accounts section don't work together. As I mentioned, users have to toggle back and forth to ensure everything gets configured correctly. A huge usability problem and the same interface exists in KMail2 in KDE 4.

I'm not trying to force anything --- I'm just going through the bug reports and trying to clean house a little. Feel welcome to keep this open as a bug. Please let me know. :)

(In reply to comment #7)
> Okay, let me rephrase. :)
> 
> The problem is "resolvable" after a user understands the quirky (awful design)
> relationship between Identities and Accounts. Some folks would consider that a
> user error or knowledge problem rather than a bug.
> 
> My perspective is I don't see how this can be fixed without redesigning the
> interface, which leads to bug report 1240, which is what I meant. Possibly some
> kind of "intelligence" could be added to the code to try to use the correct
> transport rather than just using the default.
<snip>

Actually, a redesign shouldn't be needed to resolve this this bug. When a user clicks reply, it compare the email addresses and account names of both sending and receiving accounts, e.g. if receiving account named "XYZ" with email address "someone@example.net" contains the email being replied to, check sending accounts for one named "XYZ" with email address "someone@example.net" and use that to send the reply, else display an error and use the default.

Yeah, that was my thinking when I wrote "some kind of "intelligence" could be added."

Your wording should be good enough to help whomever tackles this report. Thanks. :)

A possible fix has been committed to GIT in hash f1f9c9b.  As there is no reliable way to match Email addresses between incoming and outgoing accounts (not all providers use an Email address as the username!), I have instead opted to match account names.  Therefore, if you configure both the incoming and outgoing accounts within a specific identity to have the same name, KMail will now automatically select the outgoing transport to match the incoming transport name.

For example, if I have several accounts like this:
Incoming/IMAP:
Main Account/Inbox (main@nowhere.com)
Side Account In/Inbox (side@nowhere.com)
Some Account/Inbox (clandestine@elsewhere.com)
Outgoing:
Side Account (side@nowhere.com)
Main Account (main@nowhere.com)

and I reply to a message in the Main Account/Inbox folder, KMail will automatically select the Main Account outgoing transport.  If I instead reply to a message in the Some Account/Inbox folder, KMail will use the default outgoing transport.  Similarly, if I reply to a message in the Side Account In/Inbox folder, KMail will use the default outgoing transport as the incoming/outgoing account names do not precisely match.

Is this logic both:
a.) an improvement and
b.) sufficient to resolve this bug report?

Note that you can enable a toolbar showing the currently selected outgoing transport name in the KMail composer window--this might help to verify that your messages are in fact being sent from the desired account in any particular situation. ;-)

(In reply to comment #10)
> A possible fix has been committed to GIT in hash f1f9c9b.  As there is no
> reliable way to match Email addresses between incoming and outgoing accounts
> (not all providers use an Email address as the username!), I have instead opted
> to match account names.  Therefore, if you configure both the incoming and
> outgoing accounts within a specific identity to have the same name, KMail will
> now automatically select the outgoing transport to match the incoming transport
> name.
> 
> For example, if I have several accounts like this:
> Incoming/IMAP:
> Main Account/Inbox (main@nowhere.com)
> Side Account In/Inbox (side@nowhere.com)
> Some Account/Inbox (clandestine@elsewhere.com)
> Outgoing:
> Side Account (side@nowhere.com)
> Main Account (main@nowhere.com)
> 
> and I reply to a message in the Main Account/Inbox folder, KMail will
> automatically select the Main Account outgoing transport.  If I instead reply
> to a message in the Some Account/Inbox folder, KMail will use the default
> outgoing transport.  Similarly, if I reply to a message in the Side Account
> In/Inbox folder, KMail will use the default outgoing transport as the
> incoming/outgoing account names do not precisely match.
> 
> Is this logic both:
> a.) an improvement and
> b.) sufficient to resolve this bug report?
> 
> Note that you can enable a toolbar showing the currently selected outgoing
> transport name in the KMail composer window--this might help to verify that
> your messages are in fact being sent from the desired account in any particular
> situation. ;-)

I think that'll be a good solution, provided users are aware of this -- some sort of dialog should be shown, e.g. if sending from an account with no matching SMTP account, ask if the user would like to configure one or use the default, perhaps with a "do not show again" check box in case the user wants to keep using the default.

I'll test from Debian when it hits the nightlies (providing I don't have a head-on collision with bug #1380).

Another suggestion is to allow to configure, per-account, which SMTP account should be used, e.g. if the user wants to use the same non-default SMTP setup across several IMAP/POP accounts (such as when using a different reply-to address).

Kris, is this report still valid?

This bug is technically fixed, so I am marking it as such. However it seems to have a side effect of using the wrong email address with the correct SMTP server. I have filed that under bug #1635 .

Thank you!