Further options

[umoenks]

Addition of two settings per identity:

1. Choice if the sender address shall be removed from the recipient lists (might also affect Recipient list changes #37).
2. Choice to keep the original recipient address as sender address.

Remarks:

1. To not contradict with current behaviour, this setting is enabled by default - sender was tried to be removed in v2.4.1 already.
2. Disabled by default, though useful for catch-all identities: say you have a catch-all mailbox foo@xyz.com and also configured this as an identity in Thunderbird. Whenever you receive an email under bar@xyz.com or any other, you want to answer using the original recipient bar@xyz.com instead of foo@xyz.com or any manual fiddling with custom sender address in Thunderbird. You might want to add additional headers like x-forwarded-for, x-rzg-fwd-by or x-envelope-to to be able to detect newslist mails sent to those catch-all mailboxes.

Happy to discuss!

BTW: 2. was the functionality I missed in Thunderbird and found closest in Correct Identity. The only missing part was to setting the original recipient address as sender. The rest, what was already existing: Awesome! Great work!

[ldreier]

Hi @umoenks,

thank you for your proposals, I need some days to test, understand and give feedback (or approve)

[umoenks]

Let me know, if you think I can help you to understand what I did, @ldreier. 👍

[ldreier]

@umoenks, first tests look OK. Seems not to break existing functionality. (I run some automatic testing tools ... sometime adapting the test tools take some time ...)
More progress need to wait for next weekend...

[ldreier]

@umoenks,
regarding your second point.
What prevents you from using additional identities for an account from Thunderbird?

Your change proposes to change the "from" entry, but keep a different sender identity:
See "from" entry in ComposeDetails

[umoenks]

Simply put: the amount of work related to this, @ldreier.

The longer explanation comes here.
My setup is as follows:

• I own a domain, say xyz.com.
• I set up a catch-all mailbox on this domain, say foo@xyz.com.
• This catch-all is used to create trash mail/trace back addresses on the fly: whenever a web site wants me to register, I simply put in an e-mail alias related to that web site, say github.com@xyz.com or facebook.com@xyz.com.
• Benefits from this: no hassle configuring these aliases in my mailbox or mail client, these aliases just work out of the box for receiving e-mails.
• Downside: Thunderbird does not pick the identity configured for this catch-all address (foo@xyz.com), which I use to respond to received e-mails from automatically. This job is done by tb-correctidentiy.
• To be able to respond from the actual address on which I received a message, I have two choices:
  1. Configuring the identity in Thunderbird before sending the e-mail. As I have a couple of 10 such web site-related e-mails, which come to life spontaneously, this is a lot of work to maintain the identities. Since they require to use the SMTP of the catch-all mailbox, they all would be a clone of it except for the e-mail address itself. Possible, but tedious. I'm an engineer, I'm lazy. I see the point in spending the effort to automate my work so I don't have to do repetitive tasks manually. 😉
  2. My usual work flow therefore is to choose the catch-all identity (automated thanks to tb-correctidentidy), choose “different sender“ and adjust the sender address to that I received the original e-mail on (my mailbox accepts sending emails from github.com@xyz.com using the foo@xyz.com mailbox). My PR automates the last part - optionally to not break previous behavior of the add-on.

This is actually a scenario which is not so rare among e-mail users. Before I came across tv-correctidenty, I searched the internet and found a good amount of posts asking for such a behavior in TB. The add-on ReplyAsOriginalRecipient does a major part of this job, but it does not change to the identity I need to send the e-mail from.

[ldreier]

@umoenks , I am not sure if it helps in the discussion, but I tried to capture what the addon is actually doing...

(including your proposed changes)

Questions:

• would it make sense to use the detection pattern to chose the "from" email address instead of the "first" entry from origRecipientList? (The same pattern (e.g. xyz.com) would be used to find the sender identity "foo@xyz.com" in your case and also find the "from" address e.g. "bar@xyz.com")
• I have not yet tested it ... but does using the "foo@xyz.com" identity make its way into the smtp headers, so that the outgoing mail contains not only the "bar@xyz.com" from address but also "foo@xyz.com" which may be unwanted..
• The same could apply to the "newIdentity.name" you prepend to the email address. Maybe this is also not desired in all cases.

regarding proposed commits...:
Restoring the initial state before fixing to/ccRecipientLists ... I assume this "reverting" of a change was not intended to make its way in the final solution? (I.e. the final code should contain still "toRecipientsList = gcd.to; ccRecipientsList = gcd.cc;" from the other pull request.)

[ldreier]

@umoenks , I prepared locally some changes along my questions in the last post. Do you have feedback to the questions?
I could consider the answers before publishing the changes (could be on a branch if you like to test them).

[umoenks]

Thanks for asking back, @ldreier.
I'm really sorry I didn't answer. I wanted to, but then life took over and didn't allow me, yet.
If you could wait for feedback till the weekend, that would be great. If not, feel free to go ahead.

[umoenks]

Hi @ldreier,

So, let's see. 😊

@umoenks , I am not sure if it helps in the discussion, but I tried to capture what the addon is actually doing... (including your proposed changes)

At least it visualizes your understanding, and from what I see, I think that's pretty identical to, let's say, "my intended behavior", yes.

would it make sense to use the detection pattern to chose the "from" email address instead of the "first" entry from origRecipientList? (The same pattern (e.g. xyz.com) would be used to find the sender identity "foo@xyz.com" in your case and also find the "from" address e.g. "bar@xyz.com")

This, I am not sure if I get it right. From what I understand: what you described is realized with the code in my PR along with my following settings (actual settings GIMPed to fit the xyz.com theme):

If you meant something else, please excuse my wrong understanding and let's discuss further.

I have not yet tested it ... but does using the "foo@xyz.com" identity make its way into the smtp headers, so that the outgoing mail contains not only the "bar@xyz.com" from address but also "foo@xyz.com" which may be unwanted..

The same could apply to the "newIdentity.name" you prepend to the email address. Maybe this is also not desired in all cases.

These two points I actually do not care about as my e-mail provider does not care about. 😅
Jokes aside, I just checked the mails I sent since submission of my PR, in which I cc'ed myself (so I received the same copy with comparable headers as the actual recipient would receive): Only the custom sender Address bar <bar@xyz.com> (like dkim=pass header.i=@xyz.com, smtp.mailfrom="bar@xyz.com";, and envelope-from=bar@xyz.com";) is stored in the headers, not the identity used to send the mails (foo <foo@xyz.com>).

Admittedly, this is bound to my setup, especially my e-mail provider. There might be some others which might inject the mailbox used to the mail (foo <foo@xyz.com> in my case) to the e-mail headers. That's also one reason, why I made this change as a user-defined option: by dectivating "keep the sender address [...]", tb-correctidentity will behave like it did ever since.

regarding proposed commits...: Restoring the initial state before fixing to/ccRecipientLists ... I assume this "reverting" of a change was not intended to make its way in the final solution? (I.e. the final code should contain still "toRecipientsList = gcd.to; ccRecipientsList = gcd.cc;" from the other pull request.)

Correct, that was something where I tried to get the code clean without using branches. Didn't work properly.
"toRecipientsList = gcd.to; ccRecipientsList = gcd.cc;" needs to remain in the final code, otherwise cleaning up recipients would not work as intended.

I hope I was able to clarify your questions. If not, I'm happy to give further hints to my thoughts.

[umoenks]

HI @ldreier, I just hope my answer didn't complicate things...

[ldreier]

@umoenks ... hope not ...
I was updating the flow graph...

I uploaded my current code into a branch
2024_11_proposal

I think the main changes to your proposal are in the "use match for "from"" commit. (Reflected in flow graph a.o. by dotted arrow)

The updated flow graph and the referenced config is added below.

Todos planned:

• Update GUI text (need to think about improvements...)
• Add "catch-all" use case description to README.md
• Add pictures (below) to documentation.

[umoenks]

Sounds great! Thrilled to see it merge to main one day or the other. 😊

[ldreier]

@umoenks
did some minor changes (mainly around Documentation) and released it as version 2.5.0 on the master branch.

An update on the Thunderbird Add-on site was not yet triggered... should I?

[umoenks]

Installed the Github release und did some superficial tests - all, that is important to me. Looks good to me, @ldreier!

As far as I'm concerned: pull the trigger, release it to TB Add-on store. 👍