thunderbird / thunderbird/thunderbird-android
enhance k9 mail identity selection / catch-all support
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 14k
- Forks
- 2.8k
- Avg merge
- 3d 3h
- Merged PRs (30d)
- 57
Description
Identity selection could enhanced to make life a lot easier.
Today, it is really painful as it is in most client email readers.
Identity selection should be :
-free to edit and modify when writing a message (more or less as the recipient field currently is)
-automatically set with the best value guessed from the recipient values, when replying.
This would be a great feature to differentiate K9 mail from other rigid email clients.
Why?
I use the catch-all of my domain to handle a lot of different addresses.
Catch-all is really a great feature as it allows me to give anyone a unique email address in order to send me an email.
Consequently, I can, if I receive spam on this address, deduce that this correspondant may have abused my personal information.
I also use it to differentiate between groups of interest, without having to mess with a lot of mailboxes or aliases on the server side, as it is a painful task that can never be done correctly and is completely useless.
The only problem I see is to correctly select the account to associate with the email to be sent.
It could be deduced from the receiving account, when replying. Just use the same.
When not replying, either you are in an account view, and it is this account, or you are in the unified view, and this where creativity lies. Simplest solution would be to use the default account, but in my case, it is not the catch-all, so it's not that simple. I would make it this way : if the identity is the one associated with an account, use that account. If the identity is not the one associated with one account, use the 'default unassociated identity account', which is, in my case, the catch-all. In the end, the list-based feature can be used to force any configured account to be used.
This way, current behaviour does not change, but is extended and a lot more flexible than a fixed list-based feature.
Just imagine such a list-based feature for the recipient field in order to see what I mean.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start by reviewing the current identity and recipient-selection flows described in the issue, then trace reply handling and account selection. Done means identities can be edited while composing, replies choose the best identity from recipients, and catch-all or unassociated accounts follow the stated selection rules.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100