thunderbird / thunderbird/thunderbird-android

enhance k9 mail identity selection / catch-all support

Open
#935 66 comments 88 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type: enhancement
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.