1518025 - Allow identity to be marked as "Catch all" address. Implement matching incoming mail to this identiy (if e-mail doesn't match 100%, e.g. +suffix was used). Reply from this identity with the e-mail address received, not the identity's e-mail address.

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, enhancement)

Description

[illogical]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Receive a mail to one of my catch all address such as
[e-mail]

and hit "reply".


Actual results:

The reply mail address defaults to
[e-mail]


Expected results:

(I know that I can manually use the "Customize from address..." option in the drop down menu where I can select the identity)

Instead, it should default to the receive mail address, [e-mail] in this case. Or there should be an option in the account settings, where this behavior can be enabled.

Comment 1

[Jorg K (CEST = GMT+2)]

It currently defaults to the address in the account.

Comment 2

[illogical]

True, but when I have configured multiple identities for an account, then thunderbird already switches to the correct identity, altought its not the accounts' mail address. Meaning, to some extend this feature is already there in case of explicit identities.
With the "+" addresses, it would be like infinite but all the same identities which only differ in the mail address.

Comment 3

[rene]

I'm also interested in this feature and planning to start on implementing this.

Comment 4

[Dash]

I have multiple domains and emails that route into one email address, too many to setup individual identities for. Previously an extension took care of picking the correct address, but the changes to the extension system means that this no longer works and the author doesn't appear to be intending to continue maintenance.

But it seems we're almost there functionality wise. There needs to be some configuration and intelligence though.

e.g. at a minimum handling hidden To and CC addresses and looking for Envelope-To or Delivered-To headers.

It was the extension that was the killer feature for Thunderbird for me, being able to support numerous e-mail aliases with zero config.

Comment 5

[rene]

Attachment: Bug 1518025 - part 1 - modify OpenComposeWindow to enable setting of ComposeField-From.patch

Comment 6

[rene]

Attachment: Bug 1518025 - part 2 - changed getBestIdentity to return matching Hint and use makeFromDisplayAddress.patch

Comment 7

[rene]

Attachment: Bug 1518025 - part 3 - add new Identity attribute multiEmailSupport.patch

Comment 8

[rene]

Attachment: Bug 1518025 - part 4 - enable dynamic sender detection for reply-emails.patch

Comment 9

[rene]

Hi, above patches are the result of a first implementation.

It is working, requires some more testing and writing of some automated xpcshell-tests with the feature activated, but it's working. The implementation required the modification of two widely used functions (see part 1 and part 2 of the patches). The feature can be activated for each identity (see identity area in account settings, "Use multiple Email Addresses with matching domain name (Catch-All)"). If activated, thunderbird will use any email as sender for a reply when the domain-part of the email address is matching.

There is an hidden option of the headers to check to detect the real recipient of your emails (pref("mail.compose.multiEmailSupportHeaders", "envelope-to, x-original-to, to, cc")), I expect a power-user to be able to adapt these settings, but it should work for most setups as a beginning.

Please have a look at the implementation and suggest improvements. The complete patch was divided into four parts for better understanding, but thunderbird was never actually build with only some of these patches activated - I might have done something wrong while splitting everything apart.

Best regards, testing now, Rene

Comment 10

[rene]

Attachment: Bug 1518025 - part 3 - add new Identity attribute multiEmailSupport.patch

fixed typo

Comment 11

[Jorg K (CEST = GMT+2)]

Comment on attachment 9103169 [details] [diff] [review]
Bug 1518025 - part 1 - modify OpenComposeWindow to enable setting of ComposeField-From.patch

Those flags are used to **request** review or feedback, typically from a module peer. You would set r?mkmelin for example.

Comment 12

[rene]

Attachment: Bug 1518025 - part 4 - enable dynamic sender detection for reply-emails.patch

original selection of reply-identity was broken, fixed

Comment 13

[rene]

Attachment: Bug 1518025 - part 3 - add new Identity attribute multiEmailSupport.patch

Comment 14

[rene]

Attachment: Bug 1518025 - part 4 - enable dynamic sender detection for reply-emails.patch

Comment 15

[rene]

Attachment: Bug 1518025 - part 5 - new test to verify Reply identity and Reply address.patch

Comment 16

[rene]

Hi,

just added a test to verify the selected identity and the sender of any reply-to-mail with or without the new feature enabled (can be run with make -C obj-x86_64-pc-linux-gnu SOLO_TEST=composition/test-reply-identity.js mozmill-one )

As before, patches 1-4 had not been applied separately to Thunderbird and only separated to increase the understanding of these changes.

Waiting for review or comments, thanks! Rene

Comment 17

[Magnus Melin [:mkmelin]]

Comment on attachment 9103169 [details] [diff] [review]
Bug 1518025 - part 1 - modify OpenComposeWindow to enable setting of ComposeField-From.patch

Review of attachment 9103169 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/compose/public/nsIMsgComposeService.idl
@@ +25,5 @@
>                           in string originalMsgURI,
>                           in MSG_ComposeType type,
>                           in MSG_ComposeFormat format,
>                           in nsIMsgIdentity identity,
> +                         in string from,

This should be AUTF8String instead of string

Comment 18

[Magnus Melin [:mkmelin]]

Comment on attachment 9103170 [details] [diff] [review]
Bug 1518025 - part 2 - changed getBestIdentity to return matching Hint and use makeFromDisplayAddress.patch

Review of attachment 9103170 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/base/modules/MailUtils.jsm
@@ +423,5 @@
>     *                      account as last choice. This is useful when all
>     *                      identities are passed in. Otherwise, use the first
>     *                      entity in the list.
> +   *
> +   * @return An object containing an identity and the matching hint address

Better to have it return multiple things, which is ok in js. 
So it would be used like

 let [identity, matchingHint] = MailUtils.getBestIdentity(.....)

and for cases you don't need the matchingHint, just let [identity] = ....

@@ +461,5 @@
>  
> +    return {
> +      identity: identities.queryElementAt(0, Ci.nsIMsgIdentity),
> +      matchingHint: null,
> +    };

return [identity, matchingHint]

Comment 19

[Magnus Melin [:mkmelin]]

Comment on attachment 9103588 [details] [diff] [review]
Bug 1518025 - part 3 - add new Identity attribute multiEmailSupport.patch

Review of attachment 9103588 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/base/public/nsIMsgIdentity.idl
@@ +42,5 @@
>  
>    /**
> +   * Do we use multiple EMail addresses (like Catch-All) with this identity?
> +   */
> +  attribute boolean multiEmailSupport;

why would you ever not want to do have it then? If you're not using + addresses, you'd see no difference, no?

Comment 20

[Magnus Melin [:mkmelin]]

Comment on attachment 9103589 [details] [diff] [review]
Bug 1518025 - part 4 - enable dynamic sender detection for reply-emails.patch

Review of attachment 9103589 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/base/content/mailCommands.js
@@ +283,5 @@
> +
> +          if (useMultiEmailSupport) {
> +            // if we use multiEmailSupport, we need to get all headers
> +            // MsgHdr retrieval is asynchron, do everything in the CallBack
> +            MsgHdrToMimeMessage(

I think you can avoid this work. The email addresses themselves are always ascsii (so far), so you can just match them regardless of encoded or not.

@@ +289,5 @@
> +              null,
> +              function(hdr, aMimeMsg) {
> +                let multiEmailSupportHeaders = Services.prefs.getStringPref(
> +                  "mail.compose.multiEmailSupportHeaders"
> +                );

I don't think this'd need a pref

::: mail/components/compose/content/MsgComposeCommands.js
@@ +3187,5 @@
> +      gComposeType == Ci.nsIMsgCompType.ReplyAll ||
> +      gComposeType == Ci.nsIMsgCompType.ReplyToSender ||
> +      gComposeType == Ci.nsIMsgCompType.ReplyToGroup ||
> +      gComposeType == Ci.nsIMsgCompType.ReplyToSenderAndGroup ||
> +      gComposeType == Ci.nsIMsgCompType.ReplyToList)

I'm not sure what why this is done, but it doesn't seem correct

Comment 21

[Magnus Melin [:mkmelin]]

(In reply to Dash from comment #4)

I have multiple domains and emails that route into one email address, too many to setup individual identities for.

All in all, setting up an identity is a quick task (20 sec?). It'd be very uncommon for people to have so many domains they couldn't do that.
So I think we could do some automatics especially for plus addresses, but it should be that, automatic, and no UI.

Comment 22

[rene]

Hi Magnus, thanks for taking the time to look at this. For sure I will implement the suggested changes for patches part1 and part2.

Comment 23

[rene]

(In reply to Magnus Melin [:mkmelin] from comment #19)

Comment on attachment 9103588 [details] [diff] [review]
Bug 1518025 - part 3 - add new Identity attribute multiEmailSupport.patch

Review of attachment 9103588 [details] [diff] [review]:

::: mailnews/base/public/nsIMsgIdentity.idl
@@ +42,5 @@

/**

• • Do we use multiple EMail addresses (like Catch-All) with this identity?
• */
• attribute boolean multiEmailSupport;

why would you ever not want to do have it then? If you're not using +
addresses, you'd see no difference, no?

The current approach is going to solve the reply-issue on a more general level ("+" is just a valid part of any email address). There is a case that a user creates some identity and likes to use it as it is - whatever he is replying to. That's the current standard behaviour, changing that seems to have a too big impact.

So with this option you can decide if you like to be flexible with your senders address and allow replying with any identity you received the mail with. As long as it matches the domain of some identity, where you activated the "multiEmailSupport" - that's at least the idea of the change.

Comment 24

[rene]

(In reply to Magnus Melin [:mkmelin] from comment #20)

Comment on attachment 9103589 [details] [diff] [review]
Bug 1518025 - part 4 - enable dynamic sender detection for reply-emails.patch

Review of attachment 9103589 [details] [diff] [review]:

::: mail/base/content/mailCommands.js
@@ +283,5 @@

•      if (useMultiEmailSupport) {
  

•        // if we use multiEmailSupport, we need to get all headers
  

•        // MsgHdr retrieval is asynchron, do everything in the CallBack
  

•        MsgHdrToMimeMessage(
  

I think you can avoid this work. The email addresses themselves are always
ascsii (so far), so you can just match them regardless of encoded or not.

I use MsgHdrToMimeMessage to get access to the headers even if you do a reply on a message which is not (yet) stored locally or to headers which are not displayed, as for instance "envelope-to" is (in most setups).

@@ +289,5 @@

•          null,
  

•          function(hdr, aMimeMsg) {
  

•            let multiEmailSupportHeaders = Services.prefs.getStringPref(
  

•              "mail.compose.multiEmailSupportHeaders"
  

•            );
  

I don't think this'd need a pref

None of the headers which are carrying the email address to which a mail was originally sent are standardized. Therefore headers like "envelope-to, x-original-to" should imho. not be encoded in source without the option to change these for some "power-users". But if you like it to be fixed, I can do, both headers work for me since years.

::: mail/components/compose/content/MsgComposeCommands.js
@@ +3187,5 @@

•  gComposeType == Ci.nsIMsgCompType.ReplyAll ||
  

•  gComposeType == Ci.nsIMsgCompType.ReplyToSender ||
  

•  gComposeType == Ci.nsIMsgCompType.ReplyToGroup ||
  

•  gComposeType == Ci.nsIMsgCompType.ReplyToSenderAndGroup ||
  

•  gComposeType == Ci.nsIMsgCompType.ReplyToList)
  

I'm not sure what why this is done, but it doesn't seem correct

There was already a restriction to apply Sender changes only for Drafts/Templates which somebody created itself to prevent issues with wrong sender identities for Drafts (see bug 1287268 and bug 394216). This restriction now allows Sender changes for the Reply-Cases I cared about, that's all - do I miss something here?

Comment 25

[rene]

(In reply to Magnus Melin [:mkmelin] from comment #21)

(In reply to Dash from comment #4)

I have multiple domains and emails that route into one email address, too many to setup individual identities for.

All in all, setting up an identity is a quick task (20 sec?). It'd be very uncommon for people to have so many domains they couldn't do that.
So I think we could do some automatics especially for plus addresses, but it should be that, automatic, and no UI.

We should not handle "+"-addresses special, as far as I know there is no RFC for this. "+" is just an allowed character in the localpart of an email address. Only that some/most mail-servers are configured in a way to handle these "+"-mail-addresses as catch-alls does not mean that there are no legal dedicated addresses including a "+" out there. I think a mail client should not enforce any special usage of "+" in email addresses, but simply should enable you to answer to any email with the address you received this mail with - if you wish so.

Comment 26

[Magnus Melin [:mkmelin]]

(In reply to rene from comment #24)

I use MsgHdrToMimeMessage to get access to the headers even if you do a reply on a message which is not (yet) stored locally or to headers which are not displayed, as for instance "envelope-to" is (in most setups).

That is a potentially long operation. If it's a large message you might wait seconds.

None of the headers which are carrying the email address to which a mail was originally sent are standardized. Therefore headers like "envelope-to, x-original-to" should imho. not be encoded in source without the option to change these for some "power-users"

I guess a hidden pref can be ok.

Comment 27

[rene]

(In reply to Magnus Melin [:mkmelin] from comment #26)

(In reply to rene from comment #24)

I use MsgHdrToMimeMessage to get access to the headers even if you do a reply on a message which is not (yet) stored locally or to headers which are not displayed, as for instance "envelope-to" is (in most setups).

That is a potentially long operation. If it's a large message you might wait seconds.

If messages are forwarded (inline), those messages are completely parsed as well via nsMsgComposeService::LoadDraftOrTemplate() and mimedrft.cpp -> mime_parse_stream_complete(). Don't see why this should be some issue on Replys but not on Forwards, but can't really judge the impact. I am not aware of any other way to get the headers of the mail and only see that even the current Reply-implementation seems broken if headers or messages are not displayed before Reply.

So how to continue?

Comment 28

[rene]

Attachment: Bug 1518025 - part 1 - modify OpenComposeWindow to enable setting of ComposeField-From.patch

changed "from" in nsIMsgComposeService.idl to AUTF8String (see comment #17)

Comment 29

[rene]

Attachment: Bug 1518025 - part 2 - changed getBestIdentity to return matching Hint and use makeFromDisplayAddress.patch

changed according to comment #18

Comment 30

[rene]

Attachment: Bug 1518025 - part 3 - add new Identity attribute multiEmailSupport.patch

changes because of updated part 1 and 2

Comment 31

[rene]

Attachment: Bug 1518025 - part 4 - enable dynamic sender detection for reply-emails.patch

changes because of updated part 1 and 2

Comment 32

[rene]

Fixed issues comment #17 and comment #18

Open issues:
comment #23 - identity attribute to enable multiEmailSupport, yes or no?
comment #25 - UI option? Hidden option? Set as new default behaviour?
comment #24 - MsgComposeCommands.js @@ +3187,5 @@, right or wrong?
comment #27 - MsgHdrToMimeMessage is long operation, does this hurt?

Comment 33

[martin]

(In reply to rene from comment #25)

(In reply to Magnus Melin [:mkmelin] from comment #21)

(In reply to Dash from comment #4)

I have multiple domains and emails that route into one email address, too many to setup individual identities for.

All in all, setting up an identity is a quick task (20 sec?). It'd be very uncommon for people to have so many domains they couldn't do that.
So I think we could do some automatics especially for plus addresses, but it should be that, automatic, and no UI.

We should not handle "+"-addresses special, as far as I know there is no RFC for this. "+" is just an allowed character in the localpart of an email address. Only that some/most mail-servers are configured in a way to handle these "+"-mail-addresses as catch-alls does not mean that there are no legal dedicated addresses including a "+" out there. I think a mail client should not enforce any special usage of "+" in email addresses, but simply should enable you to answer to any email with the address you received this mail with - if you wish so.

Besides Rene's good arguments that the "+" is a valid character in a normal mail address, the separator can be different. In my case I use this function longer than I knew of any Provider that supported the "+". I use over 10 domains and hundreds of virtual aliases. The features of the Virtual Identity Extension were the main reason why I use thunderbird.

@Rene many thanks for your work.

Comment 34

[Magnus Melin [:mkmelin]]

Sorry for the delay. I've been thinking about this, and looked at the code.
Overall, I think it's far too complex for the perceived advantage: very few people will have so many domains that they couldn't do the few clicks of adding an identity for each, and after that you don't have the problem. The checkbox in the UI is also not something you could easily explain what it's about...

Comment 35

[Magnus Melin [:mkmelin]]

Comment on attachment 9105511 [details] [diff] [review]
Bug 1518025 - part 1 - modify OpenComposeWindow to enable setting of ComposeField-From.patch

Not wanted per comment 34.

Comment 36

[Magnus Melin [:mkmelin]]

Comment on attachment 9105512 [details] [diff] [review]
Bug 1518025 - part 2 - changed getBestIdentity to return matching Hint and use makeFromDisplayAddress.patch

Review of attachment 9105512 [details] [diff] [review]:
-----------------------------------------------------------------

Not wanted per comment 34.

Comment 37

[Magnus Melin [:mkmelin]]

Comment on attachment 9105513 [details] [diff] [review]
Bug 1518025 - part 3 - add new Identity attribute multiEmailSupport.patch

Review of attachment 9105513 [details] [diff] [review]:
-----------------------------------------------------------------

Not wanted per comment 34.

Comment 38

[Magnus Melin [:mkmelin]]

Comment on attachment 9105514 [details] [diff] [review]
Bug 1518025 - part 4 - enable dynamic sender detection for reply-emails.patch

Review of attachment 9105514 [details] [diff] [review]:
-----------------------------------------------------------------

Not wanted per comment 34.

Comment 39

[MS]

(In reply to Magnus Melin [:mkmelin] from comment #34)

Sorry for the delay. I've been thinking about this, and looked at the code.
Overall, I think it's far too complex for the perceived advantage: very few people will have so many domains that they couldn't do the few clicks of adding an identity for each, and after that you don't have the problem. The checkbox in the UI is also not something you could easily explain what it's about...

So, in my case and reading the original bug the same for Illogical: It is not about having many domains, but using a catchall address and replying with them as well.
Basically I use a different email address for every other site I register and every survey or whatever wants an email address using one domain, e.g.
'[e-mail]', '[e-mail]' and '[e-mail]'.
In these cases I always want to answer using that exact address, otherwise I loose the purpose of those addresses (unique per service).

Comment 40

[rene]

(In reply to Magnus Melin [:mkmelin] from comment #34)

Overall, I think it's far too complex for the perceived advantage: very few people will have so many domains that they couldn't do the few clicks of adding an identity for each

I have to agree with MS, the modification is not about saving you the clicks to add some identity to your domains. It's to answer with the right senders address, nothing else.

But not arguing any more, just giving up. Regards, Rene

Comment 41

[sc]

(In reply to Magnus Melin [:mkmelin] from comment #34)

Sorry for the delay. I've been thinking about this, and looked at the code.
Overall, I think it's far too complex for the perceived advantage: very few people will have so many domains that they couldn't do the few clicks of adding an identity for each, and after that you don't have the problem. The checkbox in the UI is also not something you could easily explain what it's about...

(In reply to Magnus Melin [:mkmelin] from comment #34)

Sorry for the delay. I've been thinking about this, and looked at the code.
Overall, I think it's far too complex for the perceived advantage: very few people will have so many domains that they couldn't do the few clicks of adding an identity for each, and after that you don't have the problem. The checkbox in the UI is also not something you could easily explain what it's about...

As others have said you are not seeing the true purpose of this. It's not for people with a few domains. It's for people who care about their online presence. Virtual email addresses unique for each site, company etc. to track who sells your email, gets hacked etc. (Or for signing up to say bugzilla that tells me I'm making that email address publicly available.) To be easily removed from lists that don't honor unsubscribe lists and the like. There are many mechanisms to create these addresses, whether it be +, or catchall, or the unlimited forwarders available in every web hosting account. Their wide availability indicates they are likely used my more than "very few" people.

The changes Rene is proposing are the logical other half to these virtual addresses. It also helps to prevent you from accidentally replying with the wrong identity which a quick check shows there are several addons for. (Most no longer working of course because of the constant push to obsolete addon APIs).

Creating a new identity for every virtual address is not the solution. Especially looking at how TB store those identities. Many lines of text in a flat for each as all the fields are stored even when they have the default value.

Rene is the author of a long existing addon for this purpose, made untenable to maintain by the constant API changes and especially the most recent ones. It was a great feature of Thunderbird that now seems dead because Magnus Melin doesn't see any value in it. How sad.

"""Thunderbird is self-supported by its user community. We need and welcome you. Please give back to the community.""" Except when one person who doesn't need a feature decides that the support isn't needed nor welcome.

Comment 42

[martin]

Another fact to consider: Many providers, especially large ones, support the feature, e.g. here is a list I found in a few minutes:

• https://support.google.com/a/users/answer/9308648?hl=en
• The google style with the "+" works also with icloud, I tested it but didn't find the documentation
• https://kb.mailbox.org/display/MBOKBEN/How+to+use+mail+extensions
• https://www.fastmail.com/help/receive/alias-catchall.html
• https://www.ionos.com/help/email/general-topics/advantages-of-a-catch-all-email-address/

Comment 43

[Dash]

(In reply to Magnus Melin [:mkmelin] from comment #21)

(In reply to Dash from comment #4)

I have multiple domains and emails that route into one email address, too many to setup individual identities for.

All in all, setting up an identity is a quick task (20 sec?). It'd be very uncommon for people to have so many domains they couldn't do that.
So I think we could do some automatics especially for plus addresses, but it should be that, automatic, and no UI.

Maybe I wasn't clear in my comment. I have multiple domains. Each of these route emails into one address. And I have too many to setup individual identities (i.e. even a 20 second task is infeasible). Aside from business usage, I, as many tech-savvy people take advantage of this technique and use unique email addresses on a catch-all each and every time it is keyed in.

You assert that it is very uncommon for people to do this, can you support that statement? As this bug and thread, and the fact that somebody has gone to the effort to supply a patch for it would suggest otherwise.

Like other users that have commented on here, I am stuck on an ageing version of Thunderbird due to no native support for this functionality and the shift of addons being infeasible for the existing third-party plugin to continue to operate.

Rene, I'm not a TB developer, but is there any way I can assist you in your endeavour?

Comment 44

[u652081]

(In reply to Magnus Melin [:mkmelin] from comment #34)

Overall, I think it's far too complex for the perceived advantage: very few people will have so many domains that they couldn't do the few clicks of adding an identity for each

I support not bloating and complicating code for something that only very few users are interested in. That's why I support to not necessarily realize this as an already built-in feature! It should, however, be available opt-in!

• @Magnus Melin [:mkmelin] Can you guide/enable this patch towards an opt-in solution/add-on? Also, should the discussion already take place in the Discussion Forum?

• @rene Can you support this patch being an integrated feature with numbers of users of the Virtual Identity Add-on?

For reasons that sc already mentioned in the following cite, I actually use service-dedicated temporary mail addresses with the provider mailbox.org (See also my mail address here).
The address will be closed (and mails to it rejected) automatically if I don't renew. Usually I never reply to these mails, but sometimes it is necessary. With the expiry of the temporary address, I also try to close the account that was registered with this mail address. Alternatively, if I want to keep the contact and after a service gained my trust, I move to permanent "+-address" or completely dedicated address.

(In reply to sc from comment #41)

It's for people who care about their online presence. Virtual email addresses unique for each site, company etc. to track who sells your email, gets hacked etc. (Or for signing up to say bugzilla that tells me I'm making that email address publicly available.) To be easily removed from lists that don't honor unsubscribe lists and the like.

+1

Comment 45

[rene]

• @rene Can you support this patch being an integrated feature with numbers of users of the Virtual Identity Add-on?

Sorry, have no numbers, the extension was not hosted on mozilla.org and I did not collect any statistics on my server.

Comment 46

[paole]

(In reply to sc from comment #41)

...
Rene is the author of a long existing addon for this purpose, made untenable to maintain by the constant API changes and especially the most recent ones. It was a great feature of Thunderbird that now seems dead because Magnus Melin doesn't see any value in it. How sad.
"""Thunderbird is self-supported by its user community. We need and welcome you. Please give back to the community.""" Except when one person who doesn't need a feature decides that the support isn't needed nor welcome.

This.

How on earth can such a great feature be rejected in such an ignorant manner? I know a lot of people who use virtual addresses on a daily basis and esp. Rene's extension made working with emails per se less painful. And it's not only about those "+-addresses", in the end Rene's extension gave us the possibility to use catchall-domains, multiple domains, service-related addresses etc. without a hustle. And with Rene's proposal here it would even make everything easier again.

So, maybe Magnus Melin [:mkmelin] reconsiders his quick rejection, let's at least hope for it. Not updating your email client because an extension is missing can't be the solution.

Comment 47

[Nick Cross]

(In reply to Magnus Melin [:mkmelin] from comment #34)

Sorry for the delay. I've been thinking about this, and looked at the code.
Overall, I think it's far too complex for the perceived advantage: very few people will have so many domains that they couldn't do the few clicks of adding an identity for each, and after that you don't have the problem. The checkbox in the UI is also not something you could easily explain what it's about...

Just to be clear - I have a single domain and a main email address on that. I give companies their own email address e.g. "[e-mail]" ; while I understand I could create a vast amount of custom identities or edit the address manually it would be much less laborious and seems ripe for automation - that way any replies to that company would automatically use the same email address.

Comment 48

[Alessandro Vesely]

(In reply to Nick Cross from comment #47)

(In reply to Magnus Melin [:mkmelin] from comment #34)

Sorry for the delay. I've been thinking about this, and looked at the code.
Overall, I think it's far too complex for the perceived advantage: very few people will have so many domains that they couldn't do the few clicks of adding an identity for each, and after that you don't have the problem. The checkbox in the UI is also not something you could easily explain what it's about...

Just to be clear - I have a single domain and a main email address on that. I give companies their own email address e.g. "[e-mail]" ; while I understand I could create a vast amount of custom identities or edit the address manually it would be much less laborious and seems ripe for automation - that way any replies to that company would automatically use the same email address.

+1, so-called "trash" email addresses, a.k.a. "finger" email addresses are commonplace nowadays. Having to plan in advance every identity that one will possibly want to use is a PITA.

Anyway, (B)CC recipients used as shortcuts to the Sent folder shouldn't participate in the identity selection.

Comment 49

[mozilla]

(In reply to Magnus Melin [:mkmelin] from comment #34)

Sorry for the delay. I've been thinking about this, and looked at the code.
Overall, I think it's far too complex for the perceived advantage: very few people will have so many domains that they couldn't do the few clicks of adding an identity for each, and after that you don't have the problem. The checkbox in the UI is also not something you could easily explain what it's about...

Dear Magnus,
what is your recommendation for users who have extinsively uses multiple identities to subscribe / register to hundreds of services, who used virtual identity so long for writing with the correct from: address? For me, among them are several mailinglists, some of which are not self-subscribed so changing the address is tedious not only for myself but even for others.

Comment 50

[lakano]

Hello,
I'm using Thunderbird since may be 15 years, I have wildcard mail addresses on my domain for security reason, as some users here, I use one email per service on internet ( ex: firefox-sync@mydomain, but also one email to each of my contact, so alice-to-guillaume@my-domain ). Since the last WebExtensions changes in Thunderbird, I've lost my best plugin Virtual Identity. Since, I need every day to create manually the identity in Mozilla before replying, it's really annoying and waiting a solution... but the message of Magnus have killed my hope.

I'm really surprised because Mozilla claims to be attached to privacy (or it's may be marketing bullshit). Now, I'll try to found another mail client that permit to use virtual identities. Thanks Mozilla for this great application, thanks Rene for your great plugin, and good bye Thunderbird.

Comment 51

[Alessandro Vesely]

(In reply to lakano from comment #50)

I'm really surprised because Mozilla claims to be attached to privacy (or it's may be marketing bullshit). Now, I'll try to found another mail client that permit to use virtual identities. Thanks Mozilla for this great application, thanks Rene for your great plugin, and good bye Thunderbird.

Using TB 68.2.2, the drop down box for the From: has a "Customize From Address..." option, which makes the field directly editable.

Comment 52

[Jorg K (CEST = GMT+2)]

I've been watching this bug from afar. Basically, in bug 394216 we introduced inspecting drafts based on their From header, this code was added
https://hg.mozilla.org/comm-central/rev/76ceed2ef472#l1.44
which is now here:
https://searchfox.org/comm-central/rev/2b1d1a5035c455aad12f56fdadab3bb748d7e44d/mail/components/compose/content/MsgComposeCommands.js#3104-3195
In there, we call emailSimilar() which basically ignores +suffixes.

I'd say that if an e-mail is received to [e-mail] and we have an identity with [e-mail] but no identity with [e-mail], we should send out the reply using [e-mail], but with the other properties of the identity that has [e-mail]. Is that the desired result? Can that not be implemented a little simpler?

Magnus, what's your opinion? At first, you didn't seem to be opposed to the idea, if I read the bug correctly. However, the implementation is a little heavy. If, however, you're opposed to make the system behave as described in the previous paragraph, then the bug should be a WONTFIX.

Personally, the two workarounds offered here are any good: 1) Customise the From address again and again and again 2) Have an identity for every +suffix address.

Also note bug 1604935. There seems to be an issue somewhere in identity selection, so we may have to visit this area anyway.

P.S.: I tried to make the summary a little clearer to match the last paragraph of comment #0.

Comment 53

[Alessandro Vesely]

(In reply to Jorg K (GMT+1) (PTO to 5th Jan 2020, sporadically reading bugmail) from comment #52)

In there, we call emailSimilar() which basically ignores +suffixes.

Would it make sense to have the "+" in split("+", 1)[0] configurable? Courier-MTA, for one, uses "-" for suffix separation, and that's not configurable.

Comment 54

[Wayne Mery (:wsmwk)]

I'm not a person who needs this feature, and obviously didn't use the add-on, but perhaps I can add some perspective.

(In reply to Dash from comment #43)

(In reply to Magnus Melin [:mkmelin] from comment #21)

(In reply to Dash from comment #4)

I have multiple domains and emails that route into one email address, too many to setup individual identities for.

All in all, setting up an identity is a quick task (20 sec?). It'd be very uncommon for people to have so many domains they couldn't do that.
So I think we could do some automatics especially for plus addresses, but it should be that, automatic, and no UI.

Maybe I wasn't clear in my comment. I have multiple domains. Each of these route emails into one address. And I have too many to setup individual identities (i.e. even a 20 second task is infeasible). Aside from business usage, I, as many tech-savvy people take advantage of this technique and use unique email addresses on a catch-all each and every time it is keyed in.

You assert that it is very uncommon for people to do this, can you support that statement? As this bug and thread, and the fact that somebody has gone to the effort to supply a patch for it would suggest otherwise.

There is in fact no data to support either side of the argument of whether there is sufficient numbers of users to justify the increased code

Like other users that have commented on here, I am stuck on an ageing version of Thunderbird due to no native support for this functionality and the shift of addons being infeasible for the existing third-party plugin to continue to operate.

It's quite unclear to me that this the API approach has been exhausted, and if Rene is unwilling to pursue this further, perhaps someone else would (several addons have been adopted after the author abandoned the code). Does anyone know what APIs would be required, and were they even requested? (Geoff might know)

(In reply to paole from comment #46)

(In reply to sc from comment #41)

...
Rene is the author of a long existing addon for this purpose, made untenable to maintain by the constant API changes and especially the most recent ones. It was a great feature of Thunderbird that now seems dead because Magnus Melin doesn't see any value in it. How sad.
"""Thunderbird is self-supported by its user community. We need and welcome you. Please give back to the community.""" Except when one person who doesn't need a feature decides that the support isn't needed nor welcome.

This.

How on earth can such a great feature be rejected in such an ignorant manner? .... So, maybe Magnus Melin [:mkmelin] reconsiders his quick rejection,

This is no way to win friends nor support. And in fact Magnus minused the patches after a month of consideration, so it doesn't seem to be a quick rejection.

That said, Jorg has some good suggestions. It might be helpful for someone to summarize the several use cases that have just been posted, especially ones where current behavior is just plain wrong. And, maybe a different approach is possible - like simplifying or making identities more powerful?

Comment 55

[Wayne Mery (:wsmwk)]

Magnus ^ and ^^

Comment 56

[Jorg K (CEST = GMT+2)]

Wayne, you know that we don't have user data on anything :-( - To me the question is simply: If you get an e-mail set to [e-mail] and you reply, should the From be [e-mail] or [e-mail] given that you have an identity for the latter.

"Virtual Identity" from here https://www.absorb.it/virtual-id could of course be made to work for TB 68, but as we all know, for TB 78 it would then have to become a WebExtension Experiment unless all the required API would be available as WE APIs. I don't think Geoff can tell unless someone does a "show and tell" for the APIs used.

Finally, "subaddressing" (https://en.wikipedia.org/wiki/Email_address#Subaddressing) mostly uses a plus character, but there are other MTAs that use other characters. So yes, an option/preference makes sense.

Comment 57

[lakano]

(In reply to Alessandro Vesely from comment #51)

(In reply to lakano from comment #50)
Using TB 68.2.2, the drop down box for the From: has a "Customize From Address..." option, which makes the field directly editable.

Thanks Alessandro for this information. I've never seen it before, and as I'm using the WebExtension « Identity Chooser » too, the menu option « Customize from address... » it's not present. If I remove this plugin, I can use this option, but now I need to be sure to not forget to switch between my personal account and my professional account.

(In reply to Wayne Mery (:wsmwk) from comment #54)

That said, Jorg has some good suggestions. It might be helpful for someone to summarize the several use cases that have just been posted, especially ones where current behavior is just plain wrong. And, maybe a different approach is possible - like simplifying or making identities more powerful?

I'm pretty sure it's not a good solution to try to detect some special characters in the email address, « + » is the most used but not the only one separator, and I'm not the only one to not use any separator (eg: mozilla@mydomain ). If I receive a mail to mozilla@mydomain I simply want when I click "Reply", that Thunderbird use the « To: » header information as a Sender email address. And when I compose a new mail, to let me edit easily the Sender field.

I don't known if this could be a solution of all uses cases, @Rene could surely add more precisions. Thanks for your interests on this problem ! :)

Comment 58

[u652081]

emailSimilar() is not sufficient to support identity selection for catch-all adresses. A list of domains on an identity could enable the selection based on a match of the domain part.

(In reply to Jorg K (GMT+1) (PTO to 5th Jan 2020, sporadically reading bugmail) from comment #52)

I'd say that if an e-mail is received to [e-mail] and we have an identity with [e-mail] but no identity with [e-mail], we should send out the reply using [e-mail], but with the other properties of the identity that has [e-mail].

So if, in addition, the domain part of a receiving address matches a domain that is entered to be covered by an identity, this receiving address with the covering identity should be adopted as the sender.

Example:

Mailserver

• Sub-addressing enabled with +
• Catch-all enabled for domains example.com to [e-mail] and temp.example2.com to [e-mail]

Thunderbird

• Identities: 1: John Doe <[e-mail]>, 2: John <[e-mail]>
• Identity 2 John <[e-mail]> set up to cover mails to temp.example.com

Behaviour

On reply to a mail that was received with the lefthand-side, the identity selection should set the sender with the righthand-side:

Mails to identity 1 John Doe <[e-mail]>

Received with (To, CC, Envelope-To, Delivered-To)	Compose with (Identity, From)	Adopted from receiving address
[e-mail]	1 John Doe <[e-mail]>
[e-mail]	1 John Doe <[e-mail]>	Address part: tag/sub-address-part
[e-mail]	1 John Doe <[e-mail]>

Mails to identity 2 John <[e-mail]>

Received with (To, CC, Envelope-To, Delivered-To)	Compose with (Identity, From)	Adopted
[e-mail]	2 John <[e-mail]>
[e-mail]	2 John <[e-mail]>	Address part: tag/sub-address-part
[e-mail]	2 John <[e-mail]>	Address (fully qualified)

Notes

Note that [e-mail]' is mapped to identity 1 without change, [e-mail]' (because it is covered by identity 2) is mapped with the adoption of the entire, fully qualified mail address.

• The sub-addressing character + may vary to at least - or be customizable
• The covered domain temp.example.com does not have to be related with the identities domain example.com

Comment 59

[u652081]

This is a corrected version of comment #52 (please delete comment #52 as I can neither edit nor delete it)

---

emailSimilar() is not sufficient to support identity selection for catch-all adresses. A list of domains on an identity could enable the selection based on a match of the domain part.

(In reply to Jorg K (GMT+1) (PTO to 5th Jan 2020, sporadically reading bugmail) from comment #52)

I'd say that if an e-mail is received to [e-mail] and we have an identity with [e-mail] but no identity with [e-mail], we should send out the reply using [e-mail], but with the other properties of the identity that has [e-mail].

So if, in addition, the domain part of a receiving address matches a domain that is entered to be covered by an identity, this receiving address with the covering identity should be adopted as the sender.

Example:

Mailserver

• Sub-addressing enabled with +
• Catch-all enabled for domains: example.com to [e-mail], temp.example.com to [e-mail]

Thunderbird

• Identities: 1: John Doe <[e-mail]>, 2: John <[e-mail]>
• Identity 2 John <[e-mail]> set up to cover mails to temp.example.com

Behaviour

On reply to a mail that was received with the lefthand-side, the identity selection should set the sender with the righthand-side:

Mails to identity 1 John Doe <[e-mail]>

Received with (To, CC, Envelope-To, Delivered-To)	Compose with (Identity, From)	Adopted from receiving address
[e-mail]	1 John Doe <[e-mail]>
[e-mail]	1 John Doe <[e-mail]>	Address part: tag/sub-address-part
[e-mail]	1 John Doe <[e-mail]>

Mails to identity 2 John <[e-mail]>

Received with (To, CC, Envelope-To, Delivered-To)	Compose with (Identity, From)	Adopted from receiving address
[e-mail]	2 John <[e-mail]>
[e-mail]	2 John <[e-mail]>	Address part: tag/sub-address-part
[e-mail]	2 John <[e-mail]>	Address (fully qualified)

Notes

Note that [e-mail] is mapped to identity 1 without change, while [e-mail] (because it is covered by identity 2) is mapped to identity 2 with the adoption of the entire, fully qualified receiving address.

• The sub-addressing character + may vary to at least - or be customizable
• The covered domain may be unrelated domains (In the example temp.example.com may vary such to be no subdomain of the identity's default domain example.com)

Comment 60

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) (PTO to 5th Jan 2020, sporadically reading bugmail) from comment #52)

I'd say that if an e-mail is received to [e-mail] and we have an identity with [e-mail] but no identity with [e-mail], we should send out the reply using [e-mail], but with the other properties of the identity that has [e-mail].

That sounds like a very useful behaviour to me, would love that and praise TB every time it does that automatically for me. Those are the convenience and efficiency features that can make us stand out from the crowd. Make it optional please (some users may not want different sender addresses for their sub-addresses), enabled by default.

However, the implementation is a little heavy.

I haven't looked at the patches yet, but I'm confident this must be achievable at a reasonable cost. Even at a higher cost, I'd still take it.

Personally, the two workarounds offered here are any good: 1) Customise the From address again and again and again 2) Have an identity for every +suffix address.

The "workarounds" are indeed not feasible.

P.S.: I tried to make the summary a little clearer to match the last paragraph of comment #0.

Thank you. We should be as supportive as we possibly can if real users are approaching us with ideas from their real-life user experience. More so if they are even willing to offer patches. If the patch isn't good enough, let's improve it together instead of discarding the idea.

Comment 61

[rene]

Hi all,

now that JorgK changed the subject the patches are not matching the bug anymore... I interpreted the bug in a way that answering to some mail uses the wrong email address and fixed it in this sense. Imho. there is no special handling of "+" or "-" in Thunderbird required. The "+" is some valid mail address character, which might be handled differently by some MTA, but not by the mail client. There is no special RFC for "+" or "-" in your email address. You can break more than you fix if you add special cases for that. Therefore the suggested implementation is generic.

And a special approach is also not required, at least when it comes to selecting the senders address of some reply. You like to answer with the mail address which is on the envelope of the mail - easy. There might be some special handling needed for selecting the right identity, but I took a straight forward approach to use a domain part match as suggested here by JorgK for the special case as well. This might be questionable, but I did not cared about that enough.

So I will suggest to change the subject again and discuss replying on a broader level here for instance into "When replying, use the recipient email as a sender" (with the "+" and "-" and whatever else in mind). Or we should keep this ticket as it is now, just for "+" and I can open some other ticket to add the patches for documentation or any future usage.

Some additional words to the process from my perspective:

The suggested implementation is quite complex. This might be some indication that a) the implementation is bloat garbage code or b) the implementation was a lot of work.
The complexity of the patches is caused by Thunderbirds quite complex code to send some email. There is a lot of "special-case" code inside current Thunderbird sending code, a lot of that pointing to the good old times of "initial import". Anybody knows why there is a special section to handle non-standard "delivered-to" headers required? Anybody knows why it's important to handle the composition of forwarding and reply's with completely different strategies and code segments (forwards are mime-parsed, replies are just using the mail content, if it's available)? I was surprised how deep I had to dive into thunderbird to do the suggested changes.

I would say the mail-sending-code is quite a mess and should be cleaned up completely. This would have been a fair suggestion and some acceptable answer to me after any review: 'Lets do it the hard way but do it right'. 'Lets collect all issues about mail senders detection and solve it all together'. Ok. But complaining about usage numbers nobody has and not even finding the time to understand the use cases completely is no fair exchange for my attempt to contribute.

Regards and happy 2020, Rene

Comment 62

[Jorg K (CEST = GMT+2)]

now that JorgK changed the subject the patches are not matching the bug anymore

Hmm, well, the description in comment #0 says:
Instead [of [e-mail]], it should default to the receive mail address, [e-mail] in this case.

I'm really confused about what we're trying to achieve here. The examples in comment #59 (correcting comment #58 not comment #52) are mostly matching the bug summary. I also had a look at the "Virtual Identity" and was even more confused about the amount of code I saw.

So maybe we can used the old-fashioned software lifecycle model here: Requirements, design, implementation, etc. IMHO it's no good to post five patches if we don't even know exactly what we want to implement.

Comment 63

[derWolle]

Hi all,

I'm new to this, but I'm also really missing the Virtual Identity addon.

My use case is simple: I use a catch-all-mailaccount (*@catchalldomain.com) as easy (without any further config needed) login for different websites or contacts ([e-mail], [e-mail]) which are all delived to one mailbox ([e-mail]).
If I hit reply to a mail To/CC'd to [e-mail], I would like the sender ("From") to be [e-mail], regardless of any special characters and without the need of any manual configuration.

(In reply to Jorg K (GMT+1) (PTO to 5th Jan 2020, sporadically reading bugmail) from comment #62)

now that JorgK changed the subject the patches are not matching the bug anymore

Hmm, well, the description in comment #0 says:
Instead [of [e-mail]], it should default to the receive mail address, [e-mail] in this case.

That is exact the behaviour I would expect, just use the "To/CC" address for the "From" address.

I'm really confused about what we're trying to achieve here. The examples in comment #59 (correcting comment #58 not comment #52) are mostly matching the bug summary. I also had a look at the "Virtual Identity" and was even more confused about the amount of code I saw.

The examples in comment #59 from are different! In this case the "+" is used as a separator and only local parts containing the "+" are used as new "From" as-it-is. Identity1 [e-mail] uses default identity [e-mail] as "From" address, which is different from the description in comment #0.
Only the identity2 case <something>@temp.example.com -> <something>@temp.example.com seems to meet comment #0 for my understanding.

Please correct me if I am wrong but the initial comment #0 seems to be quite more clear and easy than the handling of special characters or different identities TB has to choose from which evolved in this bug in the meantime.
Maybe we should start with the "easy" part and open a new bug for the special handling of further cases.

BR and happy 2020 :)
Wolfgang

Comment 64

[rene]

in short, and that's what the patches had been about:

(In reply to illogical from comment #0)

... hit "reply".
Expected results:
... it should default to the receive mail address
[e-mail] in this case

The "+" was just an example, therefore "in this case". I didn't wrote 5 patches before I understood what the bug was about.

Regards, Rene

Comment 65

[u652081]

(In reply to Jorg K (GMT+1) (PTO to 5th Jan 2020, sporadically reading bugmail) from comment #62)

I'm really confused about what we're trying to achieve here.

You're right. I also think a breakdown into different enhancements makes sense. We do discuss about different extend, right?

• In comment #0, the address - if a sub-address of a/the current identity - will be taken as the sender.
• In comment #59, the address - if a sub-address or a catch-all of a/the current identity - will be taken as the sender
• In addition, there is an implicit requirement for the functionality of the virtual identity extension, which I'm not sure about the extend. The extension will even store recipient-specific rules for sending future mails.

---

(In reply to derWolle from comment #63)

The examples in comment #59 from are different! In this case the "+" is used as a separator and only local parts containing the "+" are used as new "From" as-it-is.

As for my comment #59 the description and terms (covered, sub-addressing) may be misleading and Rene correctly pointed out that + is a valid address character. Rene is again right, for the case sub-address-part you like to answer with the fully-qualified receiving address (since it is equivalent to adopting the tag). Yet I believe there is a case distinction in the use cases:

1. Identity1 [e-mail] uses default identity [e-mail] as "From" address, which is different from the description in comment #0.

   This is the current behavior of Thunderbird and correct if you're not allowed to send from [e-mail]

2. Only the identity2 case <something>@temp.example.com -> <something>@temp.example.com seems to meet comment #0 for my understanding.

   This is missing in Thunderbird and correct if you're allowed and in purpose to send from <something>@temp.example.com

Comment 66

[Jorg K (CEST = GMT+2)]

OK, so I'll try summarising the requirements again. Why don't you provide a good summary?

Maybe we should start with the "easy" part and open a new bug for the special handling of further cases.

So what's the "easy" part?

Can someone write down the exact requirements before we proceed any further.

Comment 67

[rene]

Hi, thanks for the summary update.

Requirements.
If you receive some email, it was sent to you to some email address. If you choose to reply, it should be possible for you to answer with this exactly same email address as the preselected senders address.
This all will result in three parts:
a) give some option to activate/deactivate this behaviour ("should be possible")
b) figure out what the email address was, where the mail was sent to reach you
b) use this email address as the preselected senders address

I think it's hard to leave any design attempts out of these requirements, and I'm unsure if this is really useful in our discussion phase. But for now I keep it like that. What do you think? Please update.

Regards, Rene

Comment 68

[u652081]

Take the following as an attempt to avoid the difficulty of finding the right identity. Just a draft, feel free to make changes of any kind.

Requirements

If no identity is set up to automatically select an identity in reply to an email, and if the "Automatically Customize From Address" option is enabled, in the email compose window, apply the settings of an identity that the user has to select among the set up identities and preset/customize the sender (From-address-field) to the email address that was used to receive the message that is being replied to.

This all will result in 4 parts:

1. Give some option to activate/deactivate this behaviour (i.e. option "Automatically Customize From Address")
2. Work out the email address that was used to receive a message that is being replied to, in the following named receiving email address
3. Make the user select an identity as the underlying sender identity for this single response
4. Use the receiving email address to preset/customize customize the sender (From-address-field) in the email compose window of the reply

Comment 69

[sc]

T, in your summary I assume if the user has only one TB identity it would be automatically selected for 3.

Also from discussions here it seems this capability already exists in latest TB, but I will suggest it be added for clarity.

5. Provide the ability to customize the sender (From-address-field) in the email compose window when creating a new email, i.e. one that is not a reply.

For those unfamiliar with the virtual identity extension I'll illustrate the reason it stores the recipient-specific rules for sending future emails and why 5 above is the minimum implementation of this behavior.

Scenario:
You have an email conversation with [e-mail] using the virtual identity [e-mail]. In the context of this enhancement [e-mail] is the customized sender that does not directly correspond to a TB identity.

The conversation ends.

In the future you wish to start a new conversation with [e-mail]. If you just send a new email to [e-mail] rather than reply to the previous conversation TB will use the default sender address of the identity, say [e-mail]. This is probably not what you want. Rather you probably want to use [e-mail] as that is the email address [e-mail] already knows.

Virtual identity stores the recipient-specific rule that says if you create a new email to [e-mail] use [e-mail] as the sender. It's a nice feature that prevents you from accidentally sending from the default TB identity sender address to someone you previously contacted using a virtual identity.

I'd love to see this behavior retained, but I realize it is additional work and certainly beyond the scope of the bug as stated. I suggested 5 as the minimum because even though it is less convenient than having the relationship stored it does allow one to originate a new conversation using a virtual (or catchall) address without having to create a new TB identity or somehow modify your existing one to be aware of the virtual address.

5 is also necessary for situations where you make the original contact (no previous relationship) with say [e-mail] and wish to use a virtual address such as [e-mail].

The virtual identity extension implements 5 as it does allow you to override and use whatever send address you want whether it has a stored relationship or not.

Comment 70

[Alessandro Vesely]

Just a few thoughts:

The receiving email address. For a given identity (account), the Delivered-To: right before the relevant Received: ... by my-domain.com.... Consider a message that was sent to [e-mail], forwarded to [e-mail] and from there to itself as [e-mail]. There are corresponding Received: for each hop, possibly including Received: from localhost ..., which is not the relevant one. To complicate further, consider messages to a mailing list where my-domain.com was used as a submission server. There is a bottommost Received: ... by my-domain.com... which is not the relevant one either. Obviously, that is just heuristics, since Delivered-To: is not universally used, neither is the Received: ... for <address@domain> ... construction. Should that be a customizable algorithm?

Recipient-specific rules. Some recipients are CC'ed or BCC'ed often, using whatever From: address that is derived from the main recipient(s). In this case Virtual Identity style rules don't work well. There are other recipient-specific rules that may be more or less useful. For example, whenever I write to [e-mail] I'd like the From: to be [e-mail]. Another customizable algorithm?

Automatically Customize From Address Loudly. Whenever the From: address is automatically changed, display it in flashing red background or whatever, so that the writer will give a glance at it. Given the likelihood of wrong guesses, this would seem to be a good precaution.

Comment 71

[Magnus Melin [:mkmelin]]

I think people are underestimating the difficulty of determining the right from address, that is, which address it really was sent to. It's not necessarily available, at all. Especially for Bcc. The implementation needs to also take into consideration that you can have many accounts, and many identities under each account. Just a global "use this" will not really work.

I guess we could add something under the identity private section, where you could have an option
Default recipient for mails to: [ *@example.com ]

But the implementation would have to be kept as simple as possible not to impact the large masses that wouldn't use it. E.g. match only on the email address so you don't need the mime-decoding-encoding. The feature also needs an automated test. (And please just put it all in one patch.)

Comment 72

[Jorg K (CEST = GMT+2)]

Sounds like a good way forward to me :-)

Comment 73

[lakano]

To follow the Magnus way, we could set in any identity configuration an option to tell this domain have a wildcard configuration.
Then, the code logic could be something like that:

function matchingAddress($address)
{
	if ($address in identities list) {
		return $address
	}

	// Our case, the $address isn't listed in our identities configuration:
	for each ( « Received » header) {
		$recipient = extract( « for » address )
		if (hostname($recipient) is a configured wildcard domain) {
			return $recipient
		}
	}

	// Not found, try with other headers fields
	$otherHeaders = [ 'X-Original-To', 'Delivered-To', 'To', ... ]
	for each ( $otherHeaders ) {
		$recipient = extract( « email » address from header )
		if (hostname($recipient) is a configured wildcard domain) {
			return $recipient
		}
	}

	// Not found, so don't set default identity, force user to choose the good one
	return ''
}

This way sounds good for me too.

Comment 74

[rene]

Hi Magnus,

(In reply to Magnus Melin [:mkmelin] from comment #71)

I think people are underestimating the difficulty of determining the right from address, that is, which address it really was sent to.

But the implementation would have to be kept as simple as possible not to impact the large masses that wouldn't use it. E.g. match only on the email address so you don't need the mime-decoding-encoding.

sorry, I think you are asking for the impossible. You correctly state that it's difficult to get the right address. The right address is - if at all, not only for bcc, also for catch-alls - usually in some header which is not retrieved by displaying and replying to a message. The way to get the headers is by mime-parsing the message, or is there any other way?

The suggested implementation with the already supplied patches enabled the mime-parsing only for those people, who like to enable this feature. I don't see why the mime-parsing of messages is suitable for the forwarding of emails, but optionally for reply's it will be too heavy. Is there something I'm missing?

Best regards, Rene

Comment 75

[rene]

Hi all, just to summarize and give an abstract about the suggested patch(es), if you check patch 4 it will contain most of the coding:

if thunderbird_detects_reply {
search through all identities if this new feature (multiEmailSupport) is enabled on any identity.
if the folder has already a "customIdentity" set, do not use the new feature

if (use multiEmailSupport on any identity) {
mime-parse complete message, get all headers

create hint for search of identity:
  "to" and "cc" are added by default
  list of additional headers to care about is configurable (but order not)
    additional_default = "envelope-to, x-original-to"

compare found headers with existing identities, get most suitable identity
  this was already in use for replys, as follows:
    search trough all identities for matches between hint and identity email
  added now:
    if not found, use "week" search trough all identities with domain-only match
  added also:
    returnValue to tell which "hint" made the catch of the identity

if to-be-used identity is catch-all (multiEmailSupport enabled) {
  use email from hint
  check if hint has a name for this email set,
    if not, check other hint's for same email and use name from them
}

open compose window!
if sender not equal identity email, set new field and make field editable

}
if not do as before

Which is already close to a lot of expectations and takes care to integrate into the existing thunderbird implementation as well. Currently don't know if the order of the ("received") headers will be suitable, but this can be checked

Regards, Rene

Comment 76

[Alessandro Vesely]

(In reply to Magnus Melin [:mkmelin] from comment #71)

I think people are underestimating the difficulty of determining the right from address

Right, a comprehensive analysis should also consider external services like, e.g. trash mail. Since there is no standard, the algorithm must be tailored to the behavior of the 1st receiver —the first MTA which forwarded to an address different from what the message author had set. There is no error-free rule.

Let each user roll their own heuristics, if they dare. The task can be simplified by letting users choose the order of a few canned heuristics, like Virtual Identity used to. Then let users choose whether they want those heuristics to automatically replace the default identity or just affect the order in which alternative identities in the drop-down box are proposed.

I guess we could add something under the identity private section, where you could have an option
Default recipient for mails to: [ *@example.com ]

Hmm, why "*"? Another possibility is to enhance "Customize From address" so as to remember typed addresses without having to navigate to the identity manager. If address book auto-saving is enabled, the replaying identity can be stored in the record of each new recipient. That would give an exact match, which can easily be disabled by editing the address book.

Comment 77

[Magnus Melin [:mkmelin]]

If you don't have something like the [ *@example.com ] field, how would this all work with many accounts? There could be different catch-alls for different domains.

Comment 78

[rene]

Hi Magnus, the domain-matching is done per identity in patched getBestIdentity(identities, optionalHint, useDefault = false)

diff --git a/mail/base/modules/MailUtils.jsm b/mail/base/modules/MailUtils.jsm
--- a/mail/base/modules/MailUtils.jsm
+++ b/mail/base/modules/MailUtils.jsm
@@ -445,16 +445,38 @@ var MailUtils = {
           if (!identity.email) {
             continue;
           }
           if (hints[i].email.toLowerCase() == identity.email.toLowerCase()) {
             return [ identity, hints[i] ];
           }
         }
       }
+
+      // lets search again, this time for a matching domain if
+      // multiEmailSupport is enabled
+      for (let i = 0; i < hints.length; i++) {
+        let hintParts = hints[i].email.split("@");
+        if (hintParts.length != 2) {
+          continue;
+        }
+        let hintDomain = hintParts[1].trim().toLowerCase();
+        for (let identity of fixIterator(identities, Ci.nsIMsgIdentity)) {
+          if (!identity.email || !identity.multiEmailSupport) {
+            continue;
+          }
+          let emailParts = identity.email.split("@");
+          if (emailParts.length != 2) {
+            continue;
+          }
+          if (hintDomain == emailParts[1].trim().toLowerCase()) {
+            return [ identity, hints[i] ];
+          }
+        }
+      }
     }
 
     // Still no matches? Give up and pick the default or the first one.
     if (useDefault) {
       let defaultAccount = MailServices.accounts.defaultAccount;
       if (defaultAccount && defaultAccount.defaultIdentity) {
         return [ identity, null ];
       }

if multiple identities with same domain selected for multiEmailSupport, only first identity is used.

Regards, Rene

Comment 79

[m]

+1

Comment 80

[martin]

Hi, any updates here? Still an annoying issue...

Does anyone know another email client who can handle it or who has a plugin for it?

Comment 81

[m]

In order to bring everybody to the same level, can someone from Thunderbird, please, sum up the current status and the next action as they see?

Comment 82

[m]

In order to bring everybody to the same level, can someone from Thunderbird, please, sum up the current status and the next action as they see it?

Comment 83

[Magnus Melin [:mkmelin]]

It's waiting for someone to address comment 71.

Comment 84

[rene]

See my address in comment 75, can't do more by now. There is no solution which fulfils the requirements made in comment 71, so it can't be fixed on that base.

Comment 85

[m]

If all experts agree that the requirements in comment 71 are impossible to fulfill, then the only option to have an improvement over the current situation is to reduce the requirement. Can we agree on a very light requirement that would require a very light implementation and would be very straightforward for the users to understand and handle, but would hopefully cover 80% of the cases?

If yes, we could make a big step ahead with minor effort and risk, roll out the feature and see how the masses react and possibly enhance the light implemented improvement based on their feedback.

Comment 86

[rene]

The are two critics to the implementation:

1. the messages are mime-parsed to get all headers, which is too heavy
2. the patches are too complex regarding to the benefit
   Even without implementing the mime-parsing (there was no answer yet why this is ok for forwarding messages) the complexity of the implementation will not reduce. To transfer some senders address to the message composer will require, as far as I understood the code, nearly all the suggested changes. So there is no 'light option', except one option which is 10% useful for me and uses 95% of the code.
   At least I agree with Magnus on one point: Having such a complex midifcation and not doing it right is not right. For me this means: Taking the 95% of the code but ignoring, that often target adresses are hidden in other headers than 'to' or 'cc' is a too small step with a too high risk.

Comment 87

[m]

I apologize in advance if I am wrong and/or ignorant, but what about this light requirement?

When the user is replying to an email and previously enabled this new feature (disabled by default) in Settings, then

1. if Recipient (as computed by Thunderbird, no code change) has exactly one email address, then use the Recipient email address as Sender with the default SMTP account, and warn the user about the automatic change by e.g. flashing/coloring Sender.
2. otherwise (i.e. Recipient is empty or contains 2+ email addresses) do as before (no code change).

In other words, we tackle only replying, and only if it is completely straightforward. And the user is always responsible to make sure that the right address is used which he can easily do (flashing + existing Thunderbird feature to edit Sender in place).

If any user does not like the heuristics (e.g. he would like to use the non-default SMTP account), then he has to disable this new feature and go back to the normal, old implementation; he has nothing to lose.

I believe this would cover half of my cases and it would be clear when Thunderbird reduced my effort (and risk), and when I would need to fix Sender by hand.

// We could use the same straightforward logic for creating new emails: if the feature is enabled and user's custom email address is saved (e.g. in Addressbook) and there is exactly one Recipient email, then use the custom email address as Sender with the default SMTP account and flash it. This feature would be more complex than replying as we would also need to provide a way to store, edit, delete the custom email addresses.

Comment 88

[rene]

THis is exactly what 95% of the code is about. Only that with the suggested implementation the feature is disabled by default and had to be actively enabled by the user. Transferring the senders address to the compose-window is not possible until now and was added by the patches. Verifying the senders address against all available identities and selecting the right one is the other part of the complexity. There is no way to get rid of this when we like to have it implemented. No chance for doing it 'light'.

Comment 89

[Magnus Melin [:mkmelin]]

I looked a bit at the patches again. Maybe it's not so bad. Can you add the test, change how it's exposed in the UI (per commetn 71) and fold them into one patch?

Comment 90

[rene]

Thanks, this is really good news. I will do as you suggested, but this will take a while. Best regards, Rene

Comment 91

[rene]

(In reply to Magnus Melin [:mkmelin] from comment #71)

I guess we could add something under the identity private section, where you could have an option
Default recipient for mails to: [ *@example.com ]

Some questions about the naming of this feature: Shouldn't it be better "Default sender identity for mails to: [ *@example.com ]"?

And can we agree on some name for the internal identity attribute and internal naming of this feature? Until now the name was "multiEmailSupport". Related to the new option I suggest to name it "defaultForDomain" or "isDefaultForDomain"?

Regards, Rene

Comment 92

[Magnus Melin [:mkmelin]]

(In reply to rene from comment #91)

(In reply to Magnus Melin [:mkmelin] from comment #71)

I guess we could add something under the identity private section, where you could have an option
Default recipient for mails to: [ *@example.com ]

Some questions about the naming of this feature: Shouldn't it be better "Default sender identity for mails to: [ *@example.com ]"?

"Sender" is a bit overloaded. Maybe just "Default identity for mails to: [ *@example.com ]"?

And can we agree on some name for the internal identity attribute and internal naming of this feature?

How about just catchAll?

Comment 93

[bugzilla.mozilla.org]

IMHO there is one more feature needed.

Everybody here assumes that you are replying to some email and then it should set the sender on the reply to the original to adress of the email you're replying to. However the virtual identity addon has one more thing in storage:

Storing the relationship between recipient and sender address.

You don't always reply to an existing mail but compose a new email. If you then select a recipient, it should check if you've sent an email to this recipient before and use the same sender address as in the previous sent email (or at least ask like virtual identity does if you've used another address).

As for stats:

I don't use a catchall address because that got badly abused. I had thousands of incoming mail when I used a catchall address because spammers just could create any recipient address. What I do now is just using aliases. I wrote a little bash script "addAlias xxx". If I run it like that, the bash script will my an api call to my mailserver software and add [e-mail] as an alias address for my actual [e-mail].

Checking the db now I have over 800 aliases. For every website, app etc. I need to sign up for, I create a new alias.

Comment 94

[Alessandro Vesely]

(In reply to bugzilla.mozilla.org from comment #93)

You don't always reply to an existing mail but compose a new email. If you then select a recipient, it should check if you've sent an email to this recipient before and use the same sender address as in the previous sent email (or at least ask like virtual identity does if you've used another address).

As handy as that can be, it should never be done for BCC. Or, maybe, for a list of recipients. In fact, BCC: <[e-mail]> is often used to save the message to the Sent folder during the same SMTP session (thereby avoiding to repeat the upload with IMAP). There may be cases where a number of other recipients frequently play varying roles, so recipients in that list should never trigger such check.

Comment 95

[rene]

Attachment: Bug 1518025 - Implemented handling of catchAll mail identities.patch

Hi all, Hi Magnus,

now the patch has adapted to the changes in the codebase from last half year and includes all required fixes. Included in the patch is some mochitest, I hope I implemented this the right way and positioned it at the right place (comm/mail/test/browser/composition/browser_replyCatchAll.js)

The patched thunderbird was also tested with "./mach mochitest --quiet comm/mail/test/browser/composition" without any errors. I am open for any required modifications, thanks for taking the time to look into this.

Best regards, Rene

Comment 96

[Magnus Melin [:mkmelin]]

Comment on attachment 9139968 [details] [diff] [review]
Bug 1518025 - Implemented handling of catchAll mail identities.patch

Review of attachment 9139968 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for updating

::: mail/base/content/mailCommands.js
@@ +256,5 @@
>            );
>          } else {
>            // Replies come here.
> +          let useCatchAll = false;
> +          // check if we are using catchAll on any identity. If current

Nit: Check

@@ +273,1 @@
>            }

MailServices.accounts.allIdentities was converted so it doesn't need fixIterator anymore.

You should now be able to use
let useCatchAll = MailServices.accounts.allIdentities.some(identity => identity.catchAll);

@@ +273,5 @@
>            }
>  
> +          if (useCatchAll) {
> +            // if we use catchAll, we need to get all headers
> +            // MsgHdr retrieval is asynchron, do everything in the CallBack

Please fix capitalization, use period at end. asynchron -> asynchronous. CallBack -> callback.

@@ +280,5 @@
> +              null,
> +              function(hdr, aMimeMsg) {
> +                let catchAllHeaders = Services.prefs.getStringPref(
> +                  "mail.compose.catchAllHeaders"
> +                );

just split the result directly. no need for the tmp variable below

let catchAllHeaders = Services.prefs.getStringPref("mail.compose.catchAllHeaders").split(",").map(header => header.toLowerCase().trim());
	
                );

@@ +288,5 @@
> +
> +                // collect probable senders addresses from given headers
> +                let collectedHeaderAddresses = "";
> +                for (let i = 0; i < catchAllHeadersArray.length; i++) {
> +                  let currentHeader = catchAllHeadersArray[i]

for (let header of catchAllHeaders) {

@@ +295,5 @@
> +                  if (aMimeMsg.has(currentHeader)) {
> +                    // The email address is still RFC2047 encoded but libmime
> +                    // has already converted from "raw UTF-8" to "wide" (UTF-16)
> +                    // characters.
> +                    for (

Is this part really necessary?

@@ +321,5 @@
> +                if (
> +                  identity.catchAll &&
> +                  matchingHint
> +                ) {
> +                  // if name is not set in matchingHint, search trough other hints

Nit: If, and . at the end

@@ +333,5 @@
> +                        hdr.ccList +
> +                        "," +
> +                        collectedHeaderAddresses
> +                    );
> +                    for (let i = 0; i < hints.length; i++) {

for (let hint of hits)

::: mail/base/modules/MailUtils.jsm
@@ +420,5 @@
>     *   account as last choice. This is useful when all default account as last
>     *   choice. This is useful when all identities are passed in. Otherwise, use
>     *   the first entity in the list.
> +   * @returns [identity, matchingHint] type [nsIMsgIdentity|null,
> +   *   String|null] An array containing the identity and the matching hint

Not sure there's a proper way mark up a an array return value like this. Maybe

@returns {Array} - An array of two elements, [identity, matchingHint]. identity is an nsIMsgIdentity and matchingHint is a string.

@@ +421,5 @@
>     *   choice. This is useful when all identities are passed in. Otherwise, use
>     *   the first entity in the list.
> +   * @returns [identity, matchingHint] type [nsIMsgIdentity|null,
> +   *   String|null] An array containing the identity and the matching hint
> +   *   address

.

@@ +449,5 @@
> +      }
> +
> +      // lets search again, this time for a matching domain if
> +      // catchAll is enabled
> +      for (let i = 0; i < hints.length; i++) {

for (let hint of hints)

@@ +455,5 @@
> +        if (hintParts.length != 2) {
> +          continue;
> +        }
> +        let hintDomain = hintParts[1].trim().toLowerCase();
> +        for (let identity of fixIterator(identities, Ci.nsIMsgIdentity)) {

fixIterator is not needed anymore

::: mail/locales/en-US/chrome/messenger/am-main.dtd
@@ +12,5 @@
>  <!ENTITY name.label "Your Name:">
>  <!ENTITY name.accesskey "Y">
>  <!ENTITY email.label "Email Address:">
>  <!ENTITY email.accesskey "E">
> +<!ENTITY catchAll.label "Default identity for mails to ">

How about this?

Reply from this identity when a message not matching any other identity and the domain is: [              ]

Shouldn't it be a box to fill in there? How do you handle multiple identities setting themselves as catch-all?

::: mailnews/base/prefs/content/am-identity-edit.xhtml
@@ +86,5 @@
>                <html:td>
>                  <html:input id="identity.email"
>                              type="email"
>                              class="uri-element input-inline"
> +                            oninput="updateCatchAllDomain();"

onchange perhaps?

Comment 97

[rene]

Hi, thanks for the feedback. Most of this seems clear and will be implemented / changed as suggested.

(In reply to Magnus Melin [:mkmelin] from comment #96)

Reply from this identity when a message not matching any other identity and
the domain is: [ ]

Shouldn't it be a box to fill in there? How do you handle multiple
identities setting themselves as catch-all?

As of now the domain will be stripped live from the entered identity email address. This is the one which defines the domain of the catch-all. If multiple identities are marked as catch-all:

1. if they have a different domain part, they will be used for the relevant domains.
2. if they have the same domain part, they will be used first come first serve.

The solution for 2. is not perfect, but will save some additional overhead checking against already enabled catch-alls. Can be done, if you think that's better.

•                        oninput="updateCatchAllDomain();"
  

onchange perhaps?

onchange will trigger only when the input element loses focus, therefore with the new preferences interface you might not realize that you have changed the catchAll-domain when you had changed your email address. Therefore the choice was for oninput. What do you think?

Best regards, Rene

Comment 98

[Magnus Melin [:mkmelin]]

I think it would be more flexible and useful if you can set the domains, like for instance, you always want to reply to those @mozilla.org things with my +mozilla identity.

Comment 99

[rene]

Hi Magnus,

this is not what the bug and the code is all about. It is not about selecting the right 'stored' identity for some user-entered domain(s). It is to declare one 'stored' email identity as an catchall identity for the domain, which it owns.

Therefore adding some field to enter the domain can be done but won't fit the current bug: "Allow identity to be marked as "Catch all" address. Implement matching incoming mail to this identiy (if e-mail doesn't match 100%, e.g. +suffix was used). Reply from this identity with the e-mail address received, not the identity's e-mail address."

Please check again, regards, Rene

Comment 100

[Magnus Melin [:mkmelin]]

Yes, but why not implement it so that that case is covered as well? I would imagine it's a more common use case too.

Comment 101

[rene]

You can create some email address (with a suitable domain) for every catchall-domain you like and add it to the same account. So it will also work for now, not that easy as you wish but possible. I personally think the additional feature will required some more work and would prefer to put it in some other feature-request if really needed.

Additional requirements:

• some array of domains is required as some new identity property, to add all relevant catch-all domains to that identity
• adapt the matching functions to match against this collection of domains as well
• create some tests for the new additional domains

This can be done, but as said I would prefer to get this done trough some new feature/bug. Because of the impact of the current implementation on so many different files it is already hard to keep track with the ongoing thunderbird developments. It will be better to have some implemented base at some point and not being required to adapt all the existing code every time again to match the current thunderbird status. Yes, that's mainly for programmers convenience, but its a valid point for me as well - I can't say when I might be able to implement the additional requirements and until than the current patches might have been outdated again.

Best regards, Rene

Comment 102

[Magnus Melin [:mkmelin]]

I guess that's reasonable

Comment 103

[rene]

Attachment: Bug 1518025 - Implemented handling of catchAll mail identities.patch

Hi, just uploaded the patch with the requested changes. I checked with mochitest, but with the current thunderbird status some of the tests in comm/mail/test/browser/composition fail even without the patch (I hope it's not a problem with my own setup). The provided test for this patch is working and there is no difference regarding the fails with or without the patch.

Regards, Rene

Comment 104

[Magnus Melin [:mkmelin]]

Comment on attachment 9143351 [details] [diff] [review]
Bug 1518025 - Implemented handling of catchAll mail identities.patch

Review of attachment 9143351 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/base/prefs/content/am-identity-edit.js
@@ +518,5 @@
> +  let catchAllElem = document.getElementById("identity.catchAll");
> +  // If email address contains some domain part, use this in the checkbox
> +  // description. Else disable the whole field and reset catchAll option.
> +  if (atPos > 0 && atPos + 1 < emailAddress.length) {
> +    catchAllElem.setAttribute("disabled", false);

"false"

@@ +522,5 @@
> +    catchAllElem.setAttribute("disabled", false);
> +    catchAllElem.setAttribute(
> +      "label",
> +      catchAllElem.getAttribute("labelPreset") + emailAddress.substr(atPos + 1)
> +    );

For setting strings dyncamically, you should do it another way. See https://searchfox.org/comm-central/rev/38cc63e25d5b2f6aa935d5280576bf3decd57b0c/mailnews/base/prefs/content/am-identity-edit.js#27
Languages can need to put the domain at a different place, and there are also rtl languages...

@@ +524,5 @@
> +      "label",
> +      catchAllElem.getAttribute("labelPreset") + emailAddress.substr(atPos + 1)
> +    );
> +  } else {
> +    catchAllElem.setAttribute("disabled", true);

"true"

Comment 105

[rene]

Attachment: Bug 1518025 - Implemented handling of catchAll mail identities.patch

Hi, thanks for pointing me to this issue, it's solved with the updated patch. Best regards,

Rene

Comment 106

[Julian]

haven't reviewed the patch code but i really hope that the implementation has all the features of rene's awesome virtual identity addon. also see my comment there https://github.com/absorb-it/Virtual-Identity/issues/22#issuecomment-620492215

Comment 107

[Magnus Melin [:mkmelin]]

Comment on attachment 9143754 [details] [diff] [review]
Bug 1518025 - Implemented handling of catchAll mail identities.patch

Review of attachment 9143754 [details] [diff] [review]:
-----------------------------------------------------------------

There's some extra whitespace in the test file.

Fixed the entity and sent to try: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=7f1531834a9a792244386bcf8c8f2b4d976244f6

::: mail/locales/en-US/chrome/messenger/prefs.properties
@@ +70,5 @@
>  identity-edit-req=You must specify a valid email address for this identity.
>  identity-edit-req-title=Error Creating Identity
>  
> +## LOCALIZATION NOTE (identityCatchAll): %S is the domain part of the email address
> +identityCatchAll=Default identity for mails to %S

Reply from this identity when a message does not match any other identity and the recipient matches %S

::: mailnews/base/prefs/content/am-identity-edit.js
@@ +531,5 @@
> +    catchAllElem.setAttribute("disabled", "true");
> +    catchAllElem.checked = false;
> +    catchAllElem.setAttribute(
> +      "label",
> +      prefBundle.getFormattedString("identityCatchAll", [ "..." ])

let's use ellipsis instead of three dots

::: mailnews/base/prefs/content/am-identity-edit.xhtml
@@ +201,5 @@
>                          aria-labelledby="identity.input.label"/>
>            </hbox>
> +          
> +          <hbox align="center" class="input-container">
> +            <checkbox id="identity.catchAll" labelPreset="&catchAll.label;"

labelPreset is not used/needed and catchAll.label is not defined anywhere

::: mailnews/base/prefs/content/am-main.xhtml
@@ +188,5 @@
> +
> +      <hbox align="center" class="input-container">
> +        <checkbox id="identity.catchAll" wsm_persist="true" prefattribute="value"
> +                accesskey="&catchAll.accesskey;" style="width:100%;"
> +                prefstring="mail.identity.%identitykey%.catchAll"/>

please align attributes with id

Comment 108

[Magnus Melin [:mkmelin]]

Oh, and i think the option should move above the SMTP selection

Comment 109

[rene]

Attachment: Bug 1518025 - Implemented handling of catchAll mail identities.patch

Hi, thanks for pointing to the issue with am-identity-edit.xhtml, I completely missed that part while cleaning up. Everything should now be in order and I also tried to remove the whitespaces, hope I found all.

One thing about the naming of the checkbox, I still don't like this and you also seem to be uncomfortable with the previously chosen option. If not described exactly, users won't expect a flexible email address hidden behind this option - the email address is part of the identity. So lets think about this again or add some tooltip at least...

Suggestions:

a) Default identity for mails to %S
b) Reply from this identity when a message does not match any other identity and the recipient matches %S
d) CatchAll identity: reply from any recipient address matching domain %S and settings of this identity when a message does not match any other identity

reg. a) short, can be used if clarified with some tooltip text, else option stays unclear
reg. b) sounds more like some default identity (with a fixed email address), but that's not meant
reg. c) Maybe including CatchAll will bring people to the right idea about some more flexible use of the senders address? I intentionally used "settings of this identity" instead of "this identity" to bring users closer to the idea of some flexible email address, For most of the users the email address is 'the identity'

I'm open to some suggestions, at the end the accesskey should be matching as well, I can change this than.

Regards, Rene

Comment 110

[Dash]

IMO catch all is a big prescriptive, as this can easily be used for a simple shared/forwarded alias.

B is probably most appropriate, maybe something like this:

"When enabled %S will be used as the From address when no existing identity matches the recipient address"

Thanks for the hard work.

Comment 111

[rene]

@Dash: thanks fro your suggestion, but the line will look like follows once the domain is inserted: "When enabled example.com will be used as the From address when no existing identity matches the recipient address". This will not be consistent, because the domain will be no address and the identity (email address) will not match the recipient address. Difficult.

Hi Magnus, any chance to get some feedback on the suggestion from #109? It will be great to finalize the patch, it might already require additional changes to harmonize with the last changes of thunderbird.

Thanks for your help, best regards, Rene

Comment 112

[Magnus Melin [:mkmelin]]

Comment on attachment 9144372 [details] [diff] [review]
Bug 1518025 - Implemented handling of catchAll mail identities.patch

Review of attachment 9144372 [details] [diff] [review]:
-----------------------------------------------------------------

This is more or less ok.
I'll add another patch on top to get the more flexible catch all.

Comment 113

[Magnus Melin [:mkmelin]]

Attachment: catchall.png

Comment 114

[Magnus Melin [:mkmelin]]

Attachment: Bug_1518025_-_Implemented_handling_of_catchAll_mail_identities.patch

Unbitrotted.

Comment 115

[Magnus Melin [:mkmelin]]

Attachment: catcall2.png

Comment 116

[Magnus Melin [:mkmelin]]

Attachment: bug1518025_catchall_input.patch

Changed the logic slightly, linted and such.

We would reserve the meaning of initial star, so that initial *@ would mean mean that you want to use the address it was sent to as the reply address. For other matches, it would use the normal identity from for replying.

Comment 117

[rene]

Hi Magnus, thanks for checking and cleaning up the code.

Regarding your additional changes I have two comments:

-// Additional headers to check to find the right sender if catchAll is active.
-pref("mail.compose.catchAllHeaders", "envelope-to, x-original-to");
+// Headers to check to find the right from identity to use when catchAll is active.
+pref("mail.compose.catchAllHeaders", "envelope-to, x-original-to, to, cc");

you added "to, cc" to the list of checked headers, but they are already added in in mail/base/modules/MailUtils.jsm -> getIdentityForHeader for all reply-cases except ReplyToList.

    let hintForIdentity = "";
    if (type == Ci.nsIMsgCompType.ReplyToList) {
      hintForIdentity = hint;
    } else if (
      type == Ci.nsIMsgCompType.Template ||
      type == Ci.nsIMsgCompType.EditTemplate ||
      type == Ci.nsIMsgCompType.EditAsNew
    ) {
      hintForIdentity = hdr.author;
    } else {
      hintForIdentity = hdr.recipients + "," + hdr.ccList + "," + hint;
    }

so I think this is not required and also can't easily prevented without changing the main code (they are added before the additional headers, therefore I named them as "additional" in the comment above).

The second point is the changing behaviour of this new option depending on using a domain match or a full email address.

+            // If the hint started with *@, it applies to the whole domain. In
+            // this case return the hint so it can be used for replying.
+            // If the hint was for a more specific hint, don't return a hint
+            // so that the normal from address for the identity is used.

It seems to me that it would be really difficult to describe this feature the right way. If the behaviour of this option changes from using the recipient address to using the identity address as sender, only based on the "*@", nobody will expect this. What if somebody enters "*[e-mail]"? Based on the experience with the domain match "*@example.com" you will expect that this will use the recipient address as sender, not the identity address of this identity. But none of both things will be used, it can be even the identity address of any other identity, this seems not consistent for me.

Maybe it is worth to add one additional checkbox to differentiate between answering with the identity email address or the recipient email address? This way it could be more transparent what might be happening?

Thanks again for your input and for your help in this case,
best regards, Rene

Comment 118

[Magnus Melin [:mkmelin]]

I thought a bunch about that. In the end, it's probably relatively unusual for people to use the domain option. I would like not to add additional UI complexity. I guess the code could strip all such cases where it's not strictly *@domain to make it clear.

Comment 119

[rene]

Hi Magnus,

I definitely get the point of reducing the complexity of the interface and can live with the current implementation very well. But I still would prefer a full * match, than it at least will reduce the complexity of this option from three different cases (full adress, invalid use of * and valid use of *) to two different cases (full address, use of *).

What do you think? Best regards, Rene

Comment 120

[Magnus Melin [:mkmelin]]

I'm not sure what you're suggesting. To have only "*" to match anything?

Comment 121

[rene]

we have now three different behaviours:

• enter full email address: identity incl. address will be used
• enter *@domain.tld: received header email address with rest of identity will be used
• enter *[e-mail]: nothing will happen and 'random' identity is used

I suggest to reduce this to two cases:

• as above, enter full email address: identity incl. address will be used
• enter "* with anything" and this will match against the headers, if matching received header email address with rest of identity will be used

So just let differentiate between full address and wildcard matching, which gives two different behaviours in the end. What do you think?

Best regards, Rene

Comment 122

[Magnus Melin [:mkmelin]]

My suggestion was to drop the 3rd case. It's not needed, the matches are not for a "full" mail, it just need to include the string. If someone enters stars as part of the address, we can add code to remove those also from the string shown in the UI.

Comment 123

[rene]

(In reply to Magnus Melin [:mkmelin] from comment #118)

I guess the code could strip all such cases where it's not strictly *@domain to make it clear.

Ahh, sorry, did not understood that the right way. Yes, perfect!

Thanks a lot for your engagement in this issue, best regards,
Rene

Comment 124

[Khushil Mistry [:khushil324]]

I am trying to test this patch.
What I did was create another identity with just the change of the username and set the “Reply from this identify when delivery headers match”. A new identity is not the default identity. Both identities share the same email address. And I have added that email address in the input box of 2nd newly created not default identity.
And when I try to reply, it’s not going to the 2nd identity.
Am I missing something? How do you test this patch then ??

Comment 125

[Magnus Melin [:mkmelin]]

You can take some random email (like junk) you got where you are not a recipient but bccd. Then set the identity to catch all for an email or the domain of some email that was in To/cc. Then you reply. For the domain case the from address in the reply window should use the address it was addressed to. For the address only case, it the reply window should use the normal from address of that identity.

Comment 126

[Alessandro Vesely]

(In reply to Magnus Melin [:mkmelin] from comment #125)

You can take some random email (like junk) you got where you are not a recipient but bccd. Then set the identity to catch all for an email or the domain of some email that was in To/cc. Then you reply. For the domain case the from address in the reply window should use the address it was addressed to. For the address only case, it the reply window should use the normal from address of that identity.

Somewhat cryptic, eh?

In the documentation for the new functionality, I'd prepend some text to recall that (tentatively):

• An account corresponds to a an incoming mail server (IMAP or POP), and possibly multiple outgoing mail server (SMTP). A user on a host can configure multiple accounts.
• An identity corresponds to a role that the user plays when replying to received messages, which is distinguished by the name and address appearing in the From: header field. An account can have multiple identities. (Does that affect which outgoing server is used? Are we assuming that all outgoing servers accept any From: address? Is the MAIL FROM, a.k.a. Return-Path, going to be set to the same address as From:?)
• A catchall identity (wouldn't it be better to call it catchsome, given the above?) is an identity endowed with the ability to be automatically selected even when no explicit To: or Cc: header fields match exactly.

Is the above correct? Is it clear?

Comment 127

[Khushil Mistry [:khushil324]]

Comment on attachment 9151484 [details] [diff] [review]
bug1518025_catchall_input.patch

Review of attachment 9151484 [details] [diff] [review]:
-----------------------------------------------------------------

Look good to me. It worked as Magnus has described. Both the patches are needed to be rebased. Newly added mochitests are passing.

::: mail/base/modules/MailUtils.jsm
@@ +448,2 @@
>        for (let hint of hints) {
> +        dump("xxmagnus hint=" + hint + "\n");

Left from debugging.

::: mailnews/base/prefs/content/am-identity-edit.js
@@ +58,5 @@
>        identity.attachSignature;
>      document.getElementById("identity.htmlSigText").value =
>        identity.htmlSigText;
>      document.getElementById("identityHtmlSigFormat").checked =
> +      identity.htmlSigFormat;

id should be identity.htmlSigText.

@@ +254,1 @@
>        "identityHtmlSigFormat"

id should be "identity.htmlSigText".

::: mailnews/base/public/nsIMsgIdentity.idl
@@ +46,5 @@
>    attribute boolean catchAll;
>  
>    /**
> +   * Hint for when to use this identity as catch all. It is a comma separated
> +   * list of things to look for dlivery in headers when replying to a message

Typo delivery.

::: suite/locales/en-US/chrome/mailnews/pref/am-main.dtd
@@ +13,5 @@
>  <!ENTITY name.accesskey "Y">
>  <!ENTITY email.label "Email Address:">
>  <!ENTITY email.accesskey "E">
> +<!ENTITY catchAll.label "Reply from this identity when delivery headers match:">
> +<!ENTITY catchAll.accesskey "d">

Is the accesskey case sensitive?

Comment 128

[Magnus Melin [:mkmelin]]

(In reply to Khushil Mistry [:khushil324] from comment #127)

Is the accesskey case sensitive?

They are, but fall back to working if the right case is not found.

Comment 129

[Magnus Melin [:mkmelin]]

Will land it now but keep open to adjust how the stars are handled.

Comment 130

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/499ba850e064
Implemented handling of catchAll mail identities. r=mkmelin
https://hg.mozilla.org/comm-central/rev/59a341e3a12e
catchall - make it apply to general case, not just domain. r=khushil DONTBUILD

Comment 131

[Raphaël Rigo]

Attachment: good_identity_selected.png

Comment 132

[Raphaël Rigo]

Attachment: from_shows_only_email.png

Comment 133

[Raphaël Rigo]

Hello,
Thank you for merging this. I've just tried daily build "79.0a1 (2020-06-07) (64-bit)" and it seems to work great when the To: is an alternate identity. However, when it's a mailing list, it finds the alternate identity (using X-Original-To I guess) but the reply window only sets the email address in the "From" field, not the full identity (with name etc.).

I've attached 2 images to show the different behaviors, note that both are showing the same identity, the only obvious difference seems to be ML vs direct To:.

Thanks,
Raphaël

Comment 134

[rene]

Hi Raphaël, I can't make any real outcome of your screenshots, but I assume that the X-Original-To header is only containing your email address, not your username. If some email is not containing any user name, it can't be added automatically. Can you verify that your header contains some full name beside the email address?

Regards, Rene

Comment 135

[Raphaël Rigo]

Hi, sorry if it wasn't clear.
So, to make it clearer:

• good_identity_selected.png is what i get when I hit "reply" on a mail with a "To:" which includes my alternate identity. It contains all the info I entered in the TB identities list ("Raphaël Rigo" + "SSTIC").
• from_shows_only_email.png is what i get when I hit "reply" on a mail sent to a mailing list. Obviously the X-Original-To header is parsed at some point as the "From:" of the reply is the right address. Indeed, the X-Original-To header only contains the email address. However, I expected the full identity to be matched in the list of identies I configured in Thunderbird and used accordingly as in the good_identity_selected.png screenshot.

Was I wrong in my expectations ?

Also, thanks a lot for your work on virtual identity, I've used it happily for years.

Comment 136

[rene]

Hi, can't test this by now, but this should be able (only) if you enter the complete target email address (as in X-Original-To) into the new field beside the option. but in this case the complete identity including the email address and the name will be used - that's probably not what you like.

You might have to wait for the next step in this implementation to get this working for you. I am planning to add some option to store the senders fullname and email address when sending and retrieve this for any reply. Still unsure if this part can be done with some extension or must reside in the core as well. But this will be handled in another bug.

Best regards, Rene

Comment 137

[Raphaël Rigo]

I did some tests, and I'm not sure what the expected behaviour is. In the identies options, I have a 2nd identity, let's call it "Id2" with a full email address "[e-mail]"

When receiving a mail with To: [e-mail] the behaviour differs depending on the state of "Reply from this identity when delivery headers match: [e-mail]":

• if checked, if I reply to an email sent directly to "[e-mail]" without any name, when I reply, I get the bare email as "from": [e-mail]
• if unchecked, if I reply to an email sent directly to "[e-mail]" without any name, when I reply, I get the full identity as "from": Raphaël Rigo <[e-mail]>

So I think there's something wrong, no ? The full identity should be selected either way ?

In the case of a mailing list (X-Original-To):

• checked: bare email as "From:" when replying
• unchecked: the account's default identity is used (so the X-Original-To header is not checked)

Comment 138

[fcu-github]

For my use case (having multiple virtual recipients mapped to one identity), the patch works fine, thank you very much, finally I can reply properly again without being too careful.

Do you have any idea, when this will go into thunderbird-main?

One thing I noticed - and I don't know if it's intended: If I reply-to-all my virtual recipient is included in the recipient-list and set as sender. I think this was different with the virtual-identity add-on

Thank you for your work!

Comment 139

[rene]

Hi fcu-github,

that's a problem the extension solved by checking recipients and removing the sender from this list, but not part of the current implementation. But it might make sense to create another bug and fix this for reply-all cases by default - good point.

Hi Raphaël,

I have to find the time to check this part of the implementation, I'm not so familiar with this. I mainly made it possible to add "*@example.com" in the related field, not adding some dedicated email address. Maybe Magnus can clarify this behaviour, I see if I can find to check this part over the weekend.

Best regards, Rene

Comment 140

[Jim DeLaHunt]

(In reply to Magnus Melin [:mkmelin] from comment #21)

(In reply to Dash from comment #4)

I have multiple domains and emails that route into one email address, too many to setup individual identities for.

All in all, setting up an identity is a quick task (20 sec?). It'd be very uncommon for people to have so many domains they couldn't do that.
So I think we could do some automatics especially for plus addresses, but it should be that, automatic, and no UI.

I am one of the people who has 10s, maybe 100s of email addresses coming in to one email inbox. Some are based on a common prefix and "+" sign and address-specific suffix. Some are unique patterns. This is too many addresses for me to want to set up different identities. Also, I want Thunderbird to select the correct identity automatically. I do not want to have to select between many identities, even if manually created.

So, I question your claim that it would be "very uncommon" for people to have so many domains that they want this feature instead of manually creating identities. Do you have data to back up that claim? Because you have bug commenters who are counter-examples to that claim.

Comment 141

[Jim DeLaHunt]

(In reply to Jim DeLaHunt from comment #140)

I am one of the people who has 10s, maybe 100s of email addresses coming in to one email inbox.…

Please disregard my comment #140. I posted it having read comment #21, but not having gotten as far as comment #139. My comment is moot, because Magnus Melen [:mkmelin] already did tons of work to review and integrate the changes. Thank you very much for that, and I apologise for posting before reading all the way to the end.

Comment 142

[rene]

Attachment: Bug 1518025 - remove sender address from ReplyAll-List after catchAll triggered.patch

As fcu-github mentioned in comment 138, there is a problem with Reply-To-All cases, because the senders address will be not removed from the list of recipients. This is handled in nsMsgCompose.ccp -> QuotingOutputStreamListener::OnStopRequest, where until now only the email from the used identity is matched against the recipients.

See the proposed fix for this problem. I am really unsure about the string handling, there is probably some easier way which I did not found.

@Magnus: Please check if this should be handled in some separate Bug or if the patch can be added within this Bug.

Best regards, Rene

Comment 143

[Magnus Melin [:mkmelin]]

Attachment: bug1518025_catchp_stars.patch

Adjust star handling, per comment 118.
"[e-mail], *[e-mail], *@zz.com, *[e-mail], *[e-mail]" -> "[e-mail], *@yyy.com, *@zz.com, *@rrr.com, *@hhh.com"

Comment 144

[Khushil Mistry [:khushil324]]

What should we do when we enter @yyy.com? Should we replace "@yyy.com" to "*@yyy.com"?

Comment 145

[Magnus Melin [:mkmelin]]

Attachment: bug1518025_catchp_stars.patch

I guess we could do that. (Also cleaning up double spacing, spaces around comma, correcting ;->,)

Comment 146

[Magnus Melin [:mkmelin]]

Comment on attachment 9156577 [details] [diff] [review]
Bug 1518025 - remove sender address from ReplyAll-List after catchAll triggered.patch

Review of attachment 9156577 [details] [diff] [review]:
-----------------------------------------------------------------

Almost, you can just use nsAutoCString sender(_compFields->GetFrom()); Will attach a patch for that. Sorry for the delay.

Comment 147

[Magnus Melin [:mkmelin]]

Attachment: Bug_1518025_-_remove_sender_address_from_ReplyAll-List_after_catchAll_triggered.patch

Comment 148

[Khushil Mistry [:khushil324]]

Comment on attachment 9159705 [details] [diff] [review]
bug1518025_catchp_stars.patch

Review of attachment 9159705 [details] [diff] [review]:
-----------------------------------------------------------------

Here, once we add "," then space is added automatically which is nice but now backspace is not working because backspace to ", " will make it "," and the function will again convert it to ", ".
I guess this should be enough as we are splitting the string with identity.catchAllHint.toLowerCase().split(","). 

event.target.value = value
    .replace(/(\*[^@]+)/g, "*")
    .replace(/(^|\s)@/g, "$1*@");

Or we can detect the backspace/delete and return the function.

Comment 149

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d9d2b00f6064
clarify catch-all strings with stars, only allow matching whole domains with stars, not partial addresses. r=khushil
https://hg.mozilla.org/comm-central/rev/32430448e033
remove sender address from ReplyAll-List after catchAll triggered. r=mkmelin

Comment 150

[Magnus Melin [:mkmelin]]

I think we're done here now.

Comment 151

[Dotan Cohen]

I would like to start testing this, but I'm not sure which patches to apply. Now that the issue is marked RESOLVED, is there a build that I can try?

Comment 152

[Magnus Melin [:mkmelin]]

For a build with all the patches, grab one from here: http://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central/

Comment 153

[Jorg K (CEST = GMT+2)]

Uff, another "cross version landings" bug. Magnus, you're going to organise having it all in TB 78?

Comment 154

[Magnus Melin [:mkmelin]]

Comment on attachment 9159705 [details] [diff] [review]
bug1518025_catchp_stars.patch

[Approval Request Comment]
User impact if declined: Slightly unclear UI for the new catch-all feature
Testing completed (on c-c, etc.): yes
Risk to taking this patch (and alternatives if risky): Not very risky since it's a very local change

Comment 155

[Magnus Melin [:mkmelin]]

Comment on attachment 9159706 [details] [diff] [review]
Bug_1518025_-_remove_sender_address_from_ReplyAll-List_after_catchAll_triggered.patch

[Approval Request Comment]
User impact if declined: alternative (own) email not removed properly from replies
Testing completed (on c-c, etc.): yes
Risk to taking this patch (and alternatives if risky): in practice only affects users of the new catch-all feature it's finishing

Comment 156

[Wayne Mery (:wsmwk)]

Comment on attachment 9159705 [details] [diff] [review]
bug1518025_catchp_stars.patch

Approved for beta

Comment 157

[Wayne Mery (:wsmwk)]

Comment on attachment 9159706 [details] [diff] [review]
Bug_1518025_-_remove_sender_address_from_ReplyAll-List_after_catchAll_triggered.patch

Approved for beta

Comment 158

[rene]

(In reply to Magnus Melin [:mkmelin] from comment #146)

Comment on attachment 9156577 [details] [diff] [review]
Bug 1518025 - remove sender address from ReplyAll-List after catchAll
triggered.patch

Review of attachment 9156577 [details] [diff] [review]:

Almost, you can just use nsAutoCString sender(_compFields->GetFrom()); Will
attach a patch for that. Sorry for the delay.

Hi Magnus, thanks for fixing the patch and applying this. Best regards, Rene

Comment 159

[Dotan Cohen]

Thank you. During testing on Daily 78.0a1 (2020-06-01) (64-bit) I do not see any behaviour relevant to this issue.

I create a new mail and set the From address to "test-from@mydomain". I then set the To address to "test-to@mydomain". I set a Subject and message text, and send the mail. Seconds later I see that I've received the mail, but when I try to reply to it the From address is the default address of my identity, not the "test-to@mydomain" that the mail was sent to. Furthermore, creating a new message to "test-to@mydomain" does not reuse the "test-from@mydomain" From address.

I have reviewed the Thunderbird UI up and down, and the only thing relevant to set that I have found may be the Account Settings options "Reply from this identity when delivery headers match" and "Manage Identities". I've checked "Reply from this identity when delivery headers match" and set it to a *, as this behaviour should be present on all my messages. Under "Manage Identities" I have only a single Identity with fields duplicated from the current Account.

How to enable this feature for all mails?

Comment 160

[Magnus Melin [:mkmelin]]

You need a newer beta, we're building beta4 tonight - that will include it.
In the account settings, you should see something similar to comment 115.

Comment 161

[Rob Lemley [:rjl]]

Thunderbird 78.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/43f4af1ddecc
https://hg.mozilla.org/releases/comm-beta/rev/033d1425a57f

Comment 162

[Fab Stz]

Hi all. Great new feature in Thunderbird !

I created 2 enhancement requests:
⋅ Bug 1677329 : In case of "Catch All" use other info from identity (eg. the Name) (already mentioned in comment #137)
⋅ Bug 1677368 : Fine tune "Catch All" star management to detect yahoo disposable addresses

Comment 163

[CC]

Does there yet exist an enhancement request for when you create a new message having TB remember the last-used source address? E.g. what was discussed in comment #93 and comment #94?

https://bugzilla.mozilla.org/show_bug.cgi?id=1518025#c93

This is a crucial feature, IMO.

Thanks for the work on this!

Comment 164

[Erik Johnson]

(In reply to comment #93, #94, #163)

I need this as well, at the very least to use the original " for <xxx>" in the "Received:" header if this hasn't been learned yet, since "to:" is not reliable and often a fake/mailinglist

Comment 165

[CC]

Yeah, fancier parsing from Received headers would also be a nice enhancement. (Note that you can add the Delivered-To to mail.compose.catchAllHeaders, in case that helps.)

My ESP changes [e-mail] to Delivered-To: [e-mail] for catchall addresses, unfortunately, so I might be out of luck (and nothing in Received either.)

Personally, if I could only choose one feature, between using the delivered address vs. remembering the last-used customized address when composing, I would choose the latter feature.

Comment 166

[CC]

I created two enhancement requests as well:
• Bug 1679100 -- Remember custom sender identity used with "catch all" address responses
• Bug 1679103 -- Improve parsing for determining response address used for "catch all" identities
These are in addition to Fab's:
• Bug 1677329 : In case of "Catch All" use other info from identity (eg. the Name) (already mentioned in comment #137)
• Bug 1677368 : Fine tune "Catch All" star management to detect yahoo disposable addresses

Comment 167

[Alex]

Can the detection be (optionally) made based on X-Delivered-to ?

Comment 168

[CC]

You can modify the mail.compose.catchAllHeaders config variable to include that header if you like. For example, mine is set to:
envelope-to, x-original-to, to, cc,delivered-to

Comment 169

[bugzilla.mozilla.org]

How is it supposed to work now? I have TB 78.5.1 and it doesn't seem to work. Pretty sure I need to enable something somewhere, but where?

Comment 170

[Neil Bird]

I'd thought I'd seen it written up somewhere, but must have deduced it from comments here: in an account's settings (top-level page “Account Settings - name”), enable Reply from this identity when delivery headers match and put in some matching pattern(s) like: *@mydomain1.com,*@mydomain2.com

Comment 171

[bugzilla.mozilla.org]

(In reply to Neil Bird from comment #170)

I'd thought I'd seen it written up somewhere, but must have deduced it from comments here: in an account's settings (top-level page “Account Settings - name”), enable Reply from this identity when delivery headers match and put in some matching pattern(s) like: *@mydomain1.com,*@mydomain2.com

So, you want me to create 800+ identities? From what I gathered is that it will try to find out the correct sending address and no that you have to set it up in every single case.

Comment 172

[Neil Bird]

I don't want you to do anything, I was just trying to help, I wasn't a part of the work on this.

No, you don't need an identity per match, but you do need to tell TB which of your identities to use for which catch-all replies. If you have loads of email addresses, just try * as the match, I guess.

Comment 173

[bugzilla.mozilla.org]

(In reply to Neil Bird from comment #172)

No, you don't need an identity per match, but you do need to tell TB which of your identities to use for which catch-all replies. If you have loads of email addresses, just try * as the match, I guess.

Ok, you are right it works. But the wording in the account settings is misleading.

Comment 174

[Jason]

Hello, could this also be applied to forwarding?

The anti-spam I use (ASSP) allows one to forward emails to an address to put them on a white-list (or black-list).

Thanks!

Comment 175

[CC]

@Jason you might see comments 167 and 168. Hopefully your forwarding includes a header with the original destination address in it.

Comment 176

[Jason]

Thanks @CC. I read most of the thread up until I saw that the main feature was implemented and excitedly rushed off to try it. Apologies if I wasted yours or anybody else's time.

Comment 177

[Frank Maas]

Using TB 78.13.0 I can't seem to get this to work. I have configured an email account with several identities. One of those identities is configured such (https://imgur.com/Xli96ln):

Now an email arrives using a different address for myself (it's my name without a dot...) (https://imgur.com/zwkrNUa):

So my assumption would be that, when I reply to this email, the correct identity is chosen. That, however is not what happens, it just uses the default account identity (which is something completely unrelated to @re****.nl)

Am I doing something wrong, or could this feature use a little tweak?

(ps... although using Markdown styling the preview does not show my images, hence the URLs)

Comment 178

[Martin Sch]

Attachment: Screenshot from 2021-10-22 15-10-03.png

Screenshot of configuration