© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
(In reply to Ben Bucksch (:BenB) from comment #63)
> 3. DNS SRV does not give us some critical information we need to configure the accounts. Specifically, which form the username needs to be transmitted. Is it bbob, or <email address hidden>, or even something like EXAMPLE\\bbob? Get it wrong, and the configuration
> doesn't work.
> Sure, we can try them all. And risk authentication failures and - worst
> case - triggering
> 3-failures-
> We're back to guessing and trail&error.
> That defeats the entire point of getting an authoritative configuration
> that will definitely work.
> If we were to support DNS SRV, then only as a second-class, fallback,
> legacy format.
This question is already addressed by RFC 6186, see under Section 4:
> When a user identifier is required, MUAs MUST first use the full email address provided by the user, and if that results in an authentication failure, SHOULD fall back to using the "local-part" extracted from the email address. This is in line with the guidance outlined in Section 5. If both these user identifiers result in authentication failure, the MUA SHOULD prompt the user for a valid identifier.
According to Section 5, service providers SHOULD implement their service so that either the mail address or the "local-part" only is sufficient for authentication. So this should work for most cases.
I propose that for the username Thunderbird should do according to the RFC. If both variants fail, Thunderbird could then fallback to first try out the other auto configuration methods. If any other auto configuration method are configured, Thunderbird could use those and ignore the DNS SRV records. If only the DNS SRV are configured, it could ask the user. If such rare case happens, users should probably know which username they should use. If not, it is still better to only ask for the username instead of currently not implementing DNS SRV because it might not work perfectly and ask the user for the complete server configuration.
To me, it sounds like you want users to have a great experience with Thunderbird. However, I think users will now go to a mail provider which claims to support auto configuration according to common standard (referring to RFC 6186) and they will see that most mail applications support his mail provider out of box, but not Thunderbird, which in my opinion could lead that users might not want to use Thunderbird "because it does not just work".