When the app can't find a configuration, users have to manually specify the server settings. In the past we've suggested a server name (e.g. imap.EMAILDOMAIN). The idea was to save the user time typing the server name when there's a good chance our suggestion (partially) matched the actual server name. However, often the name wasn't correct but users assumed the app auto-detected the value. So they went ahead and tapped the "Next" button, only to get an error when checking the server settings.
To avoid the above scenario we could suggest the name ".EMAILDOMAIN" (e.g. .domain.example when the user's email address ends in @domain.example). It has the advantage of being an invalid hostname. So users will see an error message when tapping the "Next" button without making a change.
I don't know if that belongs here, but it would be very handy if tunderbird stores the previous server settings for a specific domain and reuses them when the user adds a different account with the same domain.
When the app can't find a configuration, users have to manually specify the server settings. In the past we've suggested a server name (e.g. imap.EMAILDOMAIN). The idea was to save the user time typing the server name when there's a good chance our suggestion (partially) matched the actual server name. However, often the name wasn't correct but users assumed the app auto-detected the value. So they went ahead and tapped the "Next" button, only to get an error when checking the server settings.
To avoid the above scenario we could suggest the name ".EMAILDOMAIN" (e.g.
.domain.example
when the user's email address ends in@domain.example
). It has the advantage of being an invalid hostname. So users will see an error message when tapping the "Next" button without making a change.