299499 - REPLY compose defaults to original msg DELIVERED-TO field not the TO field

Status: RESOLVED DUPLICATE of bug 273526

(Thunderbird :: Message Compose Window, defect)

Description

[Bob Bowker]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Thunderbird 1.0.2 (20050317) and Thunderbird 1.0+ (20050702)

I have many e-mail addresses which all forward/alias into one main mailbox along
with messages to that main address - TB goes to that one mailbox, downloads
everything, and places all incoming messages in the Global Inbox.  
I have 3 accounts set up - bob1 (default, POP3 server 1, SMPT server 1) bob2
(POP3 server 2, SMPT server 1) and bob3 (POP3 server 1, SMPT server 2).
Highlight a new message in the Global Inbox with the header TO: bob2 and click
on REPLY ... the compose window opens with FROM bob1.
Is the DELIVERED-TO header field being checked before the TO field when the
compose code looks for a FROM address ...?
My expectation:  if the TO field of the original message corresponds to a valid
TB account address, use that as the FROM field when the REPLY compose window
opens.  If not, check for an account address ... if none, THEN use the default
address.

Reproducible: Always

Steps to Reproduce:
1. highlight an Inbox msg sent TO a non-default account address
2. click on REPLY
3. notice the FROM field - it's the default address
Actual Results:  
Message goes out FROM the default address, not the TO address in the original
message

Expected Results:  
Check the TO field of the original message against valid account addresses, and
if there's a match insert the TO header from the original message into the FROM
field in the reply message.

TB 1.0.2 (20050317) and 1.0+ (20050702) both exhibit the same problem ... no
extensions, out-of-the-box set-up.  And yes, I can change the reply FROM
manually, but I shouldn't have to - the more e-mail addresses I have coming in
through one or two POP3 mailboxes, the bigger a problem this becomes.

Comment 1

[zug_treno]

Related to bug 273526 or Core bug 228980?

Comment 2

[Bob Bowker]

(In reply to comment #1)
> Related to bug 273526 or Core bug 228980?
Bug 273526 remains UNCONFIRMED and appears to have been abandoned - and Bug
228980 relates to lists and mailgroups.  By the way, I can confirm 273526 ...
and Identities and Global Inbox do not address the issue.

Comment 3

[Mike Cowperthwaite]

Is the header in question   Delivered-To:   or    X-Delivered-To:  ?
And where is it coming from?  TB doesn't add such a header to mail, even when 
forwarding it to the Global Inbox.  (I just checked.)

You say the mail you click has    TO: bob2
but what is the full name on that field?  In order to match an identity name
(what you are calling the "account name" is actually the name for the default 
identity of that account), it has to match both real-name and mail-address.  You 
said you have a lot of aliases -- if you don't have an identity set up for the 
alias to whicht that message was sent, then it won't be able to pick that as the 
From: field for the reply.  That is what bug 273526 is about.


(In reply to comment #2)
> By the way, I can confirm 273526 ...

(In reply to comment #2)

> Bug 228980 relates to lists and mailgroups.  

Not really.  That bug was turned into a meta bug (incorrectly, in my view), and 
*one* of the dependent bugs is a mail-list issue.  The original report is 
basically the same issue as bug 273526.

> Bug 273526 remains UNCONFIRMED and appears to have been abandoned

It probably should be duped to 228890, except for the meta-issue.


> By the way, I can confirm 273526 ...

Well, it's a request-for-enhancement, not a bug report.  There's really nothing 
for you to confirm, other than that you'd like the feature too.

Comment 4

[Mike Cowperthwaite]

No response from reporter, duping.

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