1679103 - Improve parsing for determining response address used for "catch all" identities, e.g. using regex

Status: UNCONFIRMED

(Thunderbird :: Account Manager, enhancement)

Description

[CC]

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

Steps to reproduce:

Bug #1518025 has been implemented, which allows Thunderbird to use the delivery address of a message as the responding identity when configured to do so.

Unfortunately, in many cases the system that determines the delivery address does not parse the correct email, e.g. in cases where certain forms of plus addressing are used, or the common case where ESP's use "pseudo" delivery addresses; e.g. mine changes the Delivered-To from [e-mail] to Delivered-To: [e-mail], which will not work with the current "catch all" system.

There exists a hidden pref mail.compose.catchAllHeaders that allows the user to configure which headers are search for an identity, which is helpful, but the system in general could use improvement. E.g.

• It would be great if regular expressions could be configured to match and alter addresses that are parsed
• it would be great if addresses could be parsed from Received headers, with some intelligence available to find the most recent containing a usable email address, etc.

See also bugs Bug 1677329 and Bug 1677368 which are related to this.

There is obviously a wide range of complexity this could involve, from simple hidden config parameters that specify additional regex to use when matching, to GUI configuration that allows configuring matching settings per header, etc. Anything would be welcome to address the use cases described above.

Thank you for considering this!

Comment 1

[Thomas D. (:thomas8)]

Thank you. Sounds worthwhile to me. Not sure about free cycles. Indeed the regex sounds like a lower-hanging fruit.
Maybe you can elaborate a bit: Does this RFE involve enterprise use cases?

Comment 2

[CC]

Re: enterprise, I'm not sure: I would imagine that some enterprises use this kind of system, but I think of it more as a security/privacy/spam-prevention issue, since liberal use of invented addresses is a fantastic way to sandbox senders, protect identity, trace the buying/selling of identity, and shut down spam. AFAIK TB would be (and already is?) unique in this feature, and I can say from experience that once you have a setup like this going (as we did with Virtual Identity plugin) you never want to lose it, hence the energetic support in the original bug.

TB currently parses the emails from the headers at this line:
https://hg.mozilla.org/comm-central/file/cdea27c3fabd6930d5616b25d860a62db6b305f7/mail/base/content/mailCommands.js#l280

I'm just guessing, but it seems like that might be the place where a regex would be appropriate. Virtual Identity had a sophisticated method of deciding which recipient identity to use, how to choose the responding identity depending on the sender address, detecting when the user changed the responding identity from the stored value and prompting to update it, and so forth. It's obviously a bit of a rabbit hole to implement a fully-featured system like that with attendant GUI, etc, but here are a few versions of the most basic idea, from simple to more complex:

• v1: hidden pref mail.compose.catchAllRegEx (default empty) specifies a regex that is applied to the results of the parsing described above, applicable to all headers. Regex is applied to [e-mail] only, no "display name" is modified. If a valid email address results, it is used (and preferred over addresses that are not transformed by the regex.) This enhancement might just be a few lines of code, and would enable the user to strip off plus addressing and manage the case that I described above ("[e-mail]" -> "[e-mail]").

• v2: instead of a hidden global pref, user configures the regex per account (presumably requiring GUI).

• v3: GUI to allow user to specify which header(s) to search for an account, and individualized regex for transforming those headers.

• v4: like v3, but user can also specify rules to match senders: "if sender matches R1, then transform recipient address with R2 and use that as response identity"

• bonus points: searching through and intelligently parsing out of Received headers

I'd vote for v2 as a first pass: doesn't seem (?) too hard to implement, minimal impact on users that don't use the feature, and it really lets TB users get the value from the hard work that was put in to Bug #1518025 (especially if bug #1679100 can be implemented as well.)

Comment 3

[Alex]

Any progress?