Reply-all sets From address to that of an original recipient, instead of my identity — "reply from this identity when delivery headers match" is set
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
People
(Reporter: calum.mackay, Unassigned)
References
Details
(Keywords: ux-discovery, ux-error-prevention, ux-mode-error)
MacOS 10.14.6 — TB Daily 20200707
example of problem: I am viewing an email from a colleague (with an email address in the same domain as mine) sent to a mailing list I'm on, but not addressed to me specifically.
On Reply-all, the Compose window has the original recipient, i.e. the content of the original To header, as the From address, instead of one of my identities.
The To/CC fields are mostly correct, except that the original recipient is missing; that recipient appears only in the From field.
If the email is sent, recipients see that incorrect From field: it's not just a local Compose window artefact, it gets into the sent email, hence the raised severity.
Nothing in Error Console.
This is linked to the per-account setting: "reply from this identity when delivery headers match" is set, to "*@mydomain".
Enabling this setting reliably reproduces the problem; disabling it cures the problem.
|
||
Comment 1•4 years ago
|
||
Thanks. Is this a regression? If so, is first date of problem the date of this daily?
|
Reporter | |
Comment 2•4 years ago
|
||
sorry! I had a note about that in the text I was preparing before logging this, but I seem to have failed to copy it in.
For me, the problem started appearing more or less when I enabled that setting, which I'd not used before. But I didn't immediately remember doing that, so assumed it was a Daily regression, as I update most days. So I was then surprised when, trying to find the regression window, I went back a month and it was still happening. Then I remembered enabling that setting, and found disabling it stopped the From fakery.
So it's not a recent regression, at least. I wasn't sure how far back it was safe to go, without risking my Profile.
If it's needed, I can do that, either with a new profile, or just back mine up carefully first, so let me know.
|
||
Comment 3•4 years ago
•
|
||
(In reply to Calum Mackay from comment #0)
MacOS 10.14.6 — TB Daily 20200707
example of problem: I am viewing an email from a colleague (with an email address in the same domain as mine) sent to a mailing list I'm on, but not addressed to me specifically.
Was the original message to-addressed to someone in your domain? (Maybe more than one to-address?)
If yes, then I'd think that this is expected behaviour, and I can't think of an easy way of curing that:
This is linked to the per-account setting: "reply from this identity when delivery headers match" is set, to "*@mydomain".
Enabling this setting reliably reproduces the problem; disabling it cures the problem.
Let's say original email had this:
To: colleague@yourdomain.com
List-ID: Company List <list@yourdomain.com>
So due to the above catch-all setting (*@yourdomain), Thunderbird will correctly notice that the message was sent to your domain, and (per summary of Bug 1518025), "reply from this identity with the e-mail address received [colleague@yourdomain.com], not the identity's e-mail address". This behaviour is not self-explaining from the current UI at all, and has no documentation that I am aware of. So I can only guess that it will only happen when * is used as matching pattern. Bug 1518025 had many iterations, so the behaviour ultimately implemented may not be easy to figure out even from reading the bug where it was implemented.
I guess you could set "Reply from this identity when delivery headers match: list@yourdomain.com" and hopefully that would reply using your identity provided where this setting is set.
If my guess from the mess of bug 1518025 is right, this bug is probably a ux-discovery, ux-error-prevention issue, caused by the lack of documentation on the new feature introduced in bug 1518025 (in-product and otherwise), otherwise arguably invalid. I recommend to keep this bug open and implement more in-product documentation (or an in-product link to external documentation) to explain how that feature works.
|
|
Reporter | |
Comment 4•4 years ago
|
||
thanks very much Thomas.
Oh! that's mad :)
I had taken this setting to mean: when replying to an email addressed to something that matches the field, then use /this/ identity to reply. i.e. the default identity for this account, as the identity sending the reply, since this setting is part of the per-account Default Identity settings.
I had hoped this would be useful to catch me when I accidentally reply to a work email from my personal account. e.g. when I reply to a work-domain. Although I can't work out how this happens, it occasionally does.
Agreed re "discovery", and thanks for the explanation!
|
|
Reporter | |
Comment 5•4 years ago
|
||
At a minimum, the "this identity" wording is mighty confusing, given its inclusion in the Default Identity section, since the latter turns out not to be the "this identity" referred to after all, contrary to my assumption.
Perhaps, as a start, a change to:
"Reply as original recipient (To:) when…"
===
also, what is "delivery headers" supposed to mean? Which headers? It seems to be the recipient/To, so perhaps it should say that?
thanks again, your comment clears it up for me.
|
||
Comment 6•4 years ago
|
||
(In reply to Calum Mackay from comment #4)
I had taken this setting to mean: when replying to an email addressed to something that matches the field, then use /this/ identity to reply. i.e. the default identity for this account, as the identity sending the reply, since this setting is part of the per-account Default Identity settings.
I understood this meaning this as well. Even if not using a catchall, I would expect the full identity associated with the configured header to be selected, not "just" the matching header. Somehow the behavior detailed by Calum Mackay in #5 is very limited. Maybe we'd need something to specify an identity with a kind of "replacement" inside ?
So for example, if I have a catchall "*@mydomain.com", I could define my identity as "Raphaël Rigo <#{email_found_in_header}>", but also define "Raphaël Rigo <a_more_specific_email@mydomain.com>" we should be selected by any mail having "a_more_specific_email@mydomain.com" as destination (including X-Original-To).
Maybe we should open another bug or rename this one ?
|
|
Reporter | |
Comment 7•4 years ago
|
||
(In reply to Raphaël Rigo from comment #6)
I understood this meaning this as well. Even if not using a catchall, I would expect the full identity associated with the configured header to be selected, not "just" the matching header. Somehow the behavior detailed by Calum Mackay in #5 is very limited. Maybe we'd need something to specify an identity with a kind of "replacement" inside ?
In comment #5 I was suggesting a minimum change that would at least get the UI in sync with what the code appears to do: use the original recipient as the From address for the reply; nothing further. The current UI name seems quite wrong, to me.
Maybe we should open another bug or rename this one ?
I'd prefer this bug to serve as a bug for the UI description seeming not to match the action, or is at least misleading and, also, as suggested by Thomas in comment # 3, to allow anyone else who got caught out as I did, to easily find the cause.
Hi, I'm experiencing the same issue, in thunderbird 102.12.0, I did not understand the config field :
Reply from this identity when delivery headers match : *@companydomain
because as you say, the way it works is not the same as the field description.
Thank you the previous debug, and I hope the description is in good way to be be updated :)
Hi,
Same issue here, and it led to a very confusing - yet critical - situation (I sent an email with the mail address of my director). The description is not accurate (and it would be very interesting have an option working as it was expected).
Regards
Description
•