Closed Bug 696652 Opened 9 years ago Closed 9 years ago

With multiple identities, TB wrongly picks random non-default alternate identity for From: based on matching domain only (instead of full email address)

Categories

(Thunderbird :: Message Compose Window, defect)

7 Branch
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 397975

People

(Reporter: thomas8, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: privacy)

A serious silent bug which severely compromises the privacy of my email identities...

STR

1) Pop3 account with my default address, user@gmx.de (using gmx defaults for everything incl. smtp)
2) From Manage Identities (Tools > Account Settings > user@gmx.de > Manage Identities...), add a new identity: private-identity@mydomain.com (using different smtp server (freenet), dont know if that matters)
3) Receive mail for public-alias@mydomain.com (like bugmail@mydomain.com), which gets redirected by mydomain server to user@gmx.de, and does *not* have a corresponding identity set up
4) From TB's user@gmx.de account, reply to mail received in 3)

Actual Result
a) When replying to msg received for public-alias@mydomain.com, TB wrongly and randomly preselects private-identity@mydomain.com (plus external freenet smtp) as the From: identity for message composition.
This wrong identity preselection
b) is based on a domain match only, while completely ignoring the non-matching username part of the email identity. 
c) happens silently, without any explicit notification of the user (who would have to check From: manually for every composition to avoid this bug)
d) is a severe breach of privacy, as my mail replies involving public-alias@mydomain.com get sent using private-identity@mydomain.com, which was never involved in that conversation, made worse by c)
e) cannot be permanently rectified in any way, and picks a completely random identity from the user's pov (I think, we just pick the first domain match from a list of identities, even if there are other identities further down the list with a much better match, like a-public-alias@mydomain.com, which would be a 95% string match in the username!). Only way to rectify is to set up public-identity@mydomain.com as an alternate identity, which I don't have nor want nor need, because I'm using user@gmx.de for replies to public-identity@mydomain.com

Expected result:
- on a real account user@gmx.de
- when receiving messages for alias address public-alias@mydomain.com (without an explicite identity set up)
- do not use private-identity@mydomain.com for replies (iow, do not randomly preselect from: identities only based on domain match without matching username, this bug)
- use identity public-alias@mydomain.com if it exists (iow, preselect identities only based on full address match of domain AND username - currently working)
- in all other cases, use user@gmx.de default account identity if there is no full match for an alternate identity (this bug)

This bug is major as it can silently and severely corrupt the privacy of both private and business users, e.g.:

S1) private scenario: I have mydoctor@mydomain.com, mylawyer@mydomain.com, abusinesspartner@mydomain.com, all redirected by my domain server to user@gmx.de, to filter incoming messages apart and have better spam protection if those addresses are passed on. Replying to abusinesspartner@mydomain.com might easily disclose one of my private identities like mydoctor@mydomain.com, if that happens to be the first domain match and I don't have an explicit identity for abusinesspartner@mydomain.com set up (yet).

S2) business scenario: the secretary has secretary@businessdomain.com and receives on that account copies of info@businessdomain.com, sales@businessdomain.com, etc. She also has alternate identities manager@businessdomain.com set up where she sends special messages on behalf of the manager, or internal@businessdomain.com for sending internal messages. She does not need alternate identities for sales@businessdomain.com or info@businessdomain.com as she will reply using her own real receiving account, secretary@businessdomain.com (and her neighbour uses another-secretary@businessdomain.com). When she replies, from her real receiving default account, secretary@businessdomain.com, to messages received on that account for alias identities like info@businessdomain.com, TB will randomly preselect manager@businessdomain.com or internal@businessdomain.com for the From: sender based on the domain match, but ignoring the non-matching username. Confidential email addresses will silently be disclosed in those replies, potentially even unnoticed.

Gee! Bugs like this are worrying...

This may or may not be a duplicate of bug 397975, but, given the ongoing argument trying to clarify the insufficient description of that bug since it's inception 2007, if anything, I propose duplicating bug 397975 against this one here, because this bug has better STR and clearer description including expected behaviour and use cases.
See Also: → 397975
We'll need headers to investigate. Can you anonymise them ?
I've made two real mails available for analysis to Ludo, but I don't think the problem is in the headers, it's our identity picking matching strategy of matching domain name only which is wrong.
Different but possibly related: Bug 684259 (mixup of different domains).
(In reply to Thomas D. from comment #2)
> I've made two real mails available for analysis to Ludo, but I don't think
> the problem is in the headers, it's our identity picking matching strategy
> of matching domain name only which is wrong.

Nothing stroke me when I read these headers - nothing bad in them if not two delivered-to headers - that might confuse the algorithm.
At me even the domain doesn't match, see bug 704613.
Identities are defined in prefs.js like next;
 (account definition)
  mail.account.accountA.identities = idAa,idAb, ... ,idAz
  mail.account.accountA.server     = serverS
 (mail server definition)
  mail.server.serverS.realhostname/hostname = mail.server.name
  mail.server.serverS.realuserName/userName = login-useid-of-this-mail-account
 (identity definition)
  mail.identity.idAa.useremail = mail-addr-Aa@mail-domain-for-Aa
                   |
  mail.identity.idAz.useremail = mail-addr-Az@mail-domain-for-Az
 (identity's SMTP server choice)
  mail.identity.idAa.smtpServer = smtpP
 (SMTP definition)
  mail.smtpserver.smtpP.hostname = smtp.server.name
  mail.smtpserver.smtpP.username = login-useid-of-this-smtp-account
There are two kind of identity selection for preset From: of composed mail.
 (A) Reply-to-self. Roughly one like next;
     When mail of From: mailaddr-of-identity-X, To:/CC: mailaddr-of-identity-Y,
     preset From: upon reply is set to mailaddr-of-identity-X,
     instead of mailaddr-of-identity-Y which user usually expects.
     It may be third mailaddr-of-identity-Z.
     (this is done by request from users who use "automatic-CC to his mailaddr")
 (B) X-Account-Key: based selection (needed to support Global Inbox)
     Roughly next;
     (B1) New mail composition without account selection at folder pane
          (Just after restart of Tb, mailto: link click while Tb is not running)
          => Main identity of default account
            (Main identity : topmost identity at Manage Identities panel)
     (B2) New mail composition with an account selected at folder pane, 
          No X-Account-Key: in replied mail,
          X-Account-Key: in replied mail but accountX in the header doesn't exist
          => Main identity of the selected account
            (If "Local Folders", default account's main identity)
            (When reply, owner of mail folder in which the replied mail is held)
     (B3) X-Account-Key: exists in replied mail and accountX in the header exists
          => Main identity of accountX
     "Which account's identity is used" can be seen by Account column.
     (If "Local Folders" is shown, default account's main identity is used)
And, Reply-to-self is affected by next setting.
     mailnews.reply_to_self_check_all_ident = true/false (false looks defaulted)
     perhaps next;
       true  : any identity is considered as "self"
       false : identities of selected account only is considered as "self"
Further, X-Identity-Key: header may affects on identity selection by Tb.

Above makes problem determination complex when phenomenon of "wrong preset From: for user". And, identity selection may be based on order of identity.idN or order in accountA.identities, but it may be based on alphabetic order of mail address. If not based on "order in accountA.identities", selection of non-main-identity can occur.

Thomas D(bug opener), can you show us your all accountX.identities/identity.idY definitions in list format, instead of statements?
Can you show us message headers of mail which produces problem stated in your bug summary? (X-Account-Key:, X-Identity-Key:, From:, To:, CC:, BCC:, Reply-To: Resent-From:, Resent-To:, Delivered-To:, Sender: etc.)

If needed, replace personal and/or confidential data by consistent string, please. Actually used mail address is not required as far as consistency(including alphabetic order etc.) among identity definitions and data in mail is kept, and mail address which is not defined in identities is irrelevant to problem.
Thomas D.(bug opener), same problem as bug 397975?

I could observe phenomenon like bug 397975 comment #12 and bug 397975 comment #13, by duplication test of such case after reading bug 397975 comment #17.
"matching domain only" you call was intentional "guessing". See bug 397975 comment #17 and view source code, please.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 397975
No longer blocks: 228980
You need to log in before you can comment on or make changes to this bug.