Open Bug 342242 Opened 19 years ago Updated 2 months ago

mail account autoconfiguration via DNS SRV (possibly with DNSSEC) rfc6186

Categories

(Thunderbird :: Account Manager, enhancement)

Product:
Thunderbird
Component:
Account Manager
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: dbaron, Unassigned, NeedInfo)

References

(
URL
)

Details

(Whiteboard: See comment 63)

Attachments

(1 obsolete file)

This enhancement request depends on having DNSSEC (see http://www.dnssec.net/ ) support, which we don't currently have, although there is a project at http://www.dnssec-tools.org/ working on adding some to Mozilla. It is in some ways similar to bug 242867, but would be even easier for users. I propose that Thunderbird implement a not-yet-existant standard for auto-configuration of email via DNS which would operate only when the DNS records could be verified via DNSSEC. It could be a single DNS record that defines what servers can be used for handling email from a domain so that a user doesn't have to enter the information into the account manager. For example, given a DNSSEC-verified DNS record that looked something like "imaps:outgoing.example.com;smtptls:incoming.example.com;ldaps:directory.example.com" the user could enter "john@example.com" in the account wizard and everything else could be filled in for him. This is one step less than what bug 242867 would get you. I'm not sure exactly what information would go in such an autoconfiguration format, but at least some of the advantages include: * Making it much easier for users to start using Thunderbird. * Getting users to use secure SMTP and secure IMAP (either via STARTTLS or via the SSL-specific ports) rather than insecure (which greatly reduces the chances of their password being sniffed). * getting users to use authenticated SMTP (preferably secure, and preferably on the smtps (465) or submission (587) port), which can help make it easier for servers to block things spammers do. The autoconfiguration format would probably also need to contain information about how to form the IMAP and SMTP login name from the user part of the email address, i.e., whether the user should log in as "john" or "john@example.com"; this might be specified as "%u", "%u@%d", or "%u@example.com", or something like that. It probably also needs some additional information that I'm not thinking about.
Thanks for taking the time to file this in such detail David. I'll put this in the Thunderbird 3 bucket for right now while we watch dnssec get added to mozilla (is there a bug for that part of this feature?)
Target Milestone: --- → Thunderbird 3
I couldn't find a bug on DNSSEC.
Nice idea. > Getting users to use secure SMTP and secure IMAP How do you set up the finer details of the account (see Server Settings, including esp. Advanced... for IMAP)? Outlook Express config files contain a lot of info (usually 10-20 lines long, and a lots more optional). > information about how to form the IMAP and SMTP login name from the user part > of the email address There are quite a number of large ISPs where the login name has no relation to the email address. IIRC that the case for both T-Online (Germany, maybe 50% market share) and France Telecom / Orange (maybe 80% market share).
> login name has no relation to the email address Sorry, more concretely: login name is numeric and generated by ISP, e.g. 858675467; email address username part can be freely chosen by user (e.g. ben.bucksch).
Most great idea for next major release. DNS SRV records do half of this job and this is where it should starts. Mostly in controlled environments (enterprise, university, etc) this do great job not everything like ISP hooks but most and with almost no efforts at all. Probably I ask one coder to contribute code as extension for TB.
Assignee: mscott → nobody
current implementation for next generation of TB lies here http://wiki.mozilla.org/Thunderbird:Autoconfiguration also maybe bug 242867 dup of this one, I'm not sure about this!
Wayne, could you put url in comment #6 to bug url
Flags: blocking-thunderbird3?
Version: unspecified → Trunk
Priority: -- → P1
Please leave setting the Priority to assignees.
Priority: P1 → --
Summary: mail account auto-configuration via DNS (and DNSSEC) → mail account auto-configuration via DNS and/or DNSSEC
Taken from my comment to bug 389275, this proposal has the following disadvantages: - Uses DNSSEC, which is not widely deployed and has well-known deployment and operational issues (like DNS root and most TLDs not being signed). - Requires an effort of DNS coordination when a single e-mail provider wants to deliver automation for accounts under multiple domains, as opposed to providing auto-config for a single (own) domain. - Forces the user to enter his own data, and hence does not cover the important case where you provide a configuration file with ALL the account's configuration (including e-mail address, IMAP/POP user id, default folder names, and perhaps even password), to prevent users from making mistakes.
Blocks: 389275
David can we have this in beta1 or beta2? This is one of major thing we like to introduce in TB3. But its seems it need lots work and probably can't make it for b1.
Nikolay, I planned to start with this soonish.
Assignee: nobody → ben.bucksch
FYI, there is some forward motion on the dialog for auto-configuration w/o DNS/DNSSEC, as per the design here: http://clarkbw.net/designs/account-wizard/account-dialog/account-dialog-2.html in bug 422814. Bienvenu has some of the backend code working, and I've got a start on the front-end (I'll attach a screenshot of the WIP). IMO, that is relatively low-hanging fruit, based on port sniffing & heuristics for domain names. There are a bunch of added layers that we can put on, including DNS/DNSSEC-based approaches, hosting a database of known configurations, etc.
Note that the DNS stuff we have in necko is not really a resolver, but just a wrapper around the host OS getaddrinfo() implementation. In order to do anything interesting that's DNS-based, we'd need a real resolver in Gecko, which is a non-trivial amount of work. If someone wants to do that, we should investigate the license & code compatibility of the various available open-source resolvers. For the Tb3 time frame, though, doing something DNS-based seems a little impractical.
FYI, I am planning to fetch the configuration from a webservice database via http for now, not DNS. The most I may do via DNS is to lookup a certain predefined hostname. See https://wiki.mozilla.org/Thunderbird:Autoconfiguration, Section "Proposal", Step 2 ("contact a mail configuration server of the provider"), Alternative 2: "just try to contact https://autoconfig.emailaddressdomain/mail/mozilla.xml?emailaddress=emailaddress and see whether that host/URL exists"
Thanks David, I also keep track of bug 422814. Ben, that's great, I'll be glad to do QA for this.
The DNS/DNSSEC parts of auto-configuration will most likely not make 3, but other forms of autoconfig likely will.
Flags: blocking-thunderbird3? → blocking-thunderbird3-
(In reply to comment #16) > FYI, I am planning to fetch the configuration from a webservice database via > http for now, not DNS. The most I may do via DNS is to lookup a certain > predefined hostname. Comment 0 is pretty clear about the scope of this bug. It sounds like the work you're doing should be tracked in another bug.
OK, filed bug 450710 about what I want to implement.
Assignee: ben.bucksch → nobody
The proposal "that Thunderbird implement a not-yet-existant [sic] standard" is fine and all, but there is an existent standard that we should be seriously looking at, already supported in Outlook 2007, and theoretically also in Apple Mail on Mac OS X 10.6 "Snow Leopard" and the iPhone (although I have filed bugs with Apple because I can't get it to work). Word document: http://office.microsoft.com/download/afile.aspx?AssetID=AM102105061033 Exchange 2007 whitepaper: http://technet.microsoft.com/en-us/library/bb332063.aspx Autodiscover reference: http://msdn.microsoft.com/en-us/library/aa581522.aspx
First, Exchange autodiscover is not a standard by any means. It's only supported by Microsoft. Second, we have been looking at Autodiscover closely, even discussing with Microsoft at length. Third, Autodiscover does not work via DNS. That's what this bug is about.
s/only supported by Microsoft/only supported by Microsoft Exchange (server side)/
Most of the documentation for server-side implementation is for Exchange, but I've implemented it myself with a Perl script. I've seen a PHP script for it floating around as well.
Depends on: 356104
Yes, of course exchange auto discovery is not a standard, but it is a specification which is used in outlook 2007, apple mail and iPhone. Why not use it, instead of building our own ? Here a example of a PHP (serverside) script for generation the config file: http://www.andrewyager.com/content/view/52/27/ It is very simple to configure the web server to provide such a script.
Andre, a) This is offtopic here, because this bug is specifically about DNS, and the MS protocol is based on XML. (Outlook can also look up DNS SRV records, but only when explicitly enabled by pref.) b) Microsoft itself dropped the protocol that Exchange 2007 uses, because they didn't like it anymore. Exchange 2010 uses a different, SOAP-based protocol. c) Both protocols require the user not only to know the username in advance, but also to authenticate to Exchange, before the server returns any configuration (even though it's just hostnames etc.). I find myself often not knowing how exactly my username is expected (with @ or //, with or without domain, email address or other username), so that alone is a no-go. We go from only realname, email address and password. That the XML-based protocol has already been implemented in Thunderbird 3. This bug is about finding servers via DNS.
I filed bug 521538 for supporting Microsoft's autodiscovery protocol; please go there for that. :-)
No longer blocks: 389275
(In reply to comment #27) > That the XML-based protocol has already been implemented in Thunderbird 3. Could you post an URL with the specification for such protocol?
I did, in comment 16. Please read before writing, thanks.
(In reply to comment #30) > I did, in comment 16. Please read before writing, thanks. The stuff in https://wiki.mozilla.org/Thunderbird:Autoconfiguration has some implementation notes, but is not a specification.
That and <https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat> (linked there) is sufficient to implement it.
(In reply to comment #32) > That and > <https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat> > (linked there) is sufficient to implement it. I am aware of the subpages, but: 1) All the IMAP stuff is missing. 2) A lot of things are undefined or unclear, including very basic things (for example the defaults handling, or how to deal with multiple identities). 3) "All settings and enum values" are also in the TODO list, which does not sound as "sufficient to implement it". In any case, apparently it has the same design faults that were pointed out for the Autoconfig RDF files in TB2, years ago. For example, linking the identity of the email provider with the domain of such provider (although this is also unclear, as it is unknown the role of the 'id' attribute in the 'emailProvider' element). If this has been already implemented following the lines shown in these notes, IMHO this is a lost opportunity for a highly important feature.
morz, please email me about concrete problems you see (in more detail than above). I don't want to respond here, because it would be offtopic.
After many years, DNSSEC is starting to be deployed. ICANN and IETF plan that in 2 months from now, the first public root server publishes a DNSSEC-signed root. TLD .org is already signed.
I'm voting for the bug, but only on the condition it uses a standard mechanism such as the approaching finalized IETF proposal: http://tools.ietf.org/html/draft-daboo-srv-email I don't see that it's necessary to wait for DNSSEC to implement that. DNSSEC will deploy when it deploys and we'll get the extra security bump when it shows up. I consider central-server based architectures such as the Mozilla ISPDB to be a poor design that introduces a single-point of failure. One customer is correctly worried about the extra dependency that creates.
Am I the only one who thinks that Mozilla's new centralized approach of client autoconfiguration is a poor idea? https://wiki.mozilla.org/Thunderbird/ISPDB/Requirements http://ispdb.mozillamessaging.com/ https://wiki.mozilla.org/MailServerList It allows for unverified users to submit the information (which has already happened for our domain, but they mostly got it right.) It is also kind of a pain to manage if you host lots of domains (we host 270 domains.) It also makes mozilla.org a dependency, which leads to concerns about their reliability and longevity. How can we ensure that this mozilla-centric model won't interfere with other clients that want to implement autoconfiguration. If we have to backfill this information for 270 domains, I don't want to do it again for each client that chooses to implement their own centralized database.
Coincidentally, the XMPP folks are struggling with the same problem. XMPP client SRV records work wonderfully, but they rely on the server using Start-TLS with a signed certificate that matches the virtual domain. This has been a complaint of mine for some time, because obtaining certificates for all of our 270 domains is the biggest obstacle to enabling all of the email domains within our chat service. They have recognized the shortfall in this methodology (no doubt Google Apps Talk had something to do with this) and are working on the following draft to solve the problem. http://tools.ietf.org/html/draft-hildebrand-dna-00
(In reply to comment #36) > I'm voting for the bug, but only on the condition it uses a standard mechanism > such as the approaching finalized IETF proposal: > > http://tools.ietf.org/html/draft-daboo-srv-email I do agree with you Chris, but you may look into bug 356104 and bug 14328, these are showstoppers. Necko doesn't have code right now to resolve SRV records.
Target Milestone: Thunderbird 3 → ---
> Am I the only one who thinks that Mozilla's new centralized approach of > client autoconfiguration is a poor idea? No, you're not. It wasn't intended for the use case you mention. Please see https://wiki.mozilla.org/Thunderbird:Autoconfiguration and bug 534722.
(In reply to comment #36) > I don't see that it's necessary to wait for DNSSEC to implement that. DNSSEC > will deploy when it deploys and we'll get the extra security bump when it shows > up. I'd agree that it's not necessary to wait for DNSSEC if all servers found in this manner require SSL/TLS (i.e., the connection is configured to fail if TLS can't be initiated or if the cert doesn't match).
> (i.e., the connection is configured to fail if TLS can't be initiated or if the cert doesn't match) Requiring that certs match the domain will be a show stopper for services that host lots of domains. We are an EDU, and we host 270 domains. Just think about services that host thousands of domains! Supposing it is practical for email service administrators to maintain hundreds or thousands of valid signed matching certificates for domains that they don't own - it isn't practical, IMHO - do we know if the major MTAs support the ability to present a different cert for the individual domain during the Start-TLS negotiation? If not, that will also be a show stopper. Is it feasible to abandon plain old TLS? Outlook still seems to work better with port 465/TLS. Start-TLS would be a new requirement since the domain needs to be known before the server can present a matching cert. Take a look at http://tools.ietf.org/html/draft-hildebrand-dna-00 for some ideas on other methods of asserting domain ownership without the need for DNSSEC.
> Please see https://wiki.mozilla.org/Thunderbird:Autoconfiguration and bug 534722. Yes, step 2 is a more rational approach. I still think that step 3 is problematic just in its existence. I see that there is mailing list http://groups.google.com/group/ispdb so I'll voice my concerns there.
Depends on: 545866
Blocks: 490234
See bug 14328 for the work being done on extending DNS support to include the resolution of SRV records, which seems to me to be closely related to the work being discussed here.
Yes, I filed bug 545866 (arbitrary DNS queries in Mozilla) based on that and made it block this bug.
Narrowing bug summary to DNS SRV records, to differentiate from DNS MX, which I filed as bug 551519.
Summary: mail account auto-configuration via DNS and/or DNSSEC → mail account auto-configuration via DNS SRV (possibly with DNSSEC)
draft-daboo-srv-email is now http://tools.ietf.org/html/rfc6186
Summary: mail account auto-configuration via DNS SRV (possibly with DNSSEC) → mail account auto-configuration via DNS SRV (possibly with DNSSEC) rfc6186
If this is implemented, I'd suggest it be in compliance with rfc6186. I don't see DNSSEC as a requirement, but rather an extra. There's really little harm that can be done on a DNSSEC-less scenario that can't be done right now. And even if the SRV records are on a DNS domains that implements DNSSEC, the actual IMAP/SMTP servers might be in DNSSEC-less domains.
No longer depends on: 356104
Any updates on this issue? The improvements to user experience by implementing this are huge: Now: User need to know email, username, password, smtp server, imap server, smtp port, imap port. With RFC6186 User needs to know email, password.
Just FYI: RFC 6186 doesn't give username. The following method gives username and a number of other parameters, and it works today, see https://developer.mozilla.org/en/Thunderbird/Autoconfiguration
There are some severe downsides to the ISBDB: 1) It's controlled by Mozilla, instead of each ISP. 2) It won't work on LANs. 3) It requires intervention on Behalf of mozilla to update information. 4) Only thunderbird uses this information. If each email client had it's own non-standard mechanism, then ISPs would have a huge burden to update each of them with new information when they change their email server. The other mechanism: 1) Shares point (4). 2) Is inheretly insecure (why HTTP instead of HTTPS?) While I have nothing in particular AGAINST maintaining support for mozilla's in-house mechanism, I belive that supporting standardized mechanisms (especially RFCs) is ultimately important.
> 1) It's controlled by Mozilla, instead of each ISP. > 2) It won't work on LANs. > 3) It requires intervention on Behalf of mozilla to update information. Not true for the ISP fetch. > 2) Is inheretly insecure ... HTTP So is DNS (at least without DNSSEC)
(In reply to Hugo Osvaldo Barrera from comment #53) > 4) Only thunderbird uses this information. If each email client had it's > own non-standard mechanism, then ISPs would have a huge burden to update > each of them with new information when they change their email server. Evolution uses it too, although it looks like they host their own copy of the database. Check out: http://git.gnome.org/browse/evolution/tree/mail/e-mail-autoconfig.c which uses a (sadly non-SSL) base url of: http://api.gnome.org/evolution/autoconfig/1.1/ The upcoming Firefox OS Gaia e-mail client also uses the ISP database too. Note: Neither this nor I believe Ben's comments are meant to suggest that we don't want to support DNS SRV. Unfortunately, it's still a non-trivial undertaking to get the support in the gecko platform that has not been prioritized on the platform side. For Firefox OS v2 we are hoping to get it prioritized.
(In reply to Ben Bucksch (:BenB) from comment #54) > > 2) Is inheretly insecure ... HTTP > > So is DNS (at least without DNSSEC) So rfc6186 provides secure autoconfiguration for domains that implement DNSSEC. There's no way to achieve secure autoconfiguration with this mechanism, since HTTP provides no security mechanism. However, my strongest point is it's non-standardness, while rfc6186 is standard, and grants total control (and optional security) to the ISP. Also, there's no reason both autoconfiguration mechanisms can't exist. (In reply to Andrew Sutherland (:asuth) from comment #55) > (In reply to Hugo Osvaldo Barrera from comment #53) > > 4) Only thunderbird uses this information. If each email client had it's > > own non-standard mechanism, then ISPs would have a huge burden to update > > each of them with new information when they change their email server. > > Evolution uses it too, although it looks like they host their own copy of > the database. Check out: > http://git.gnome.org/browse/evolution/tree/mail/e-mail-autoconfig.c > which uses a (sadly non-SSL) base url of: > http://api.gnome.org/evolution/autoconfig/1.1/ Sadly, this is a perfect example of how rfc6186 is superior, since every email server's configuration is in it's owner's DNS server. > > The upcoming Firefox OS Gaia e-mail client also uses the ISP database too. > > > Note: Neither this nor I believe Ben's comments are meant to suggest that we > don't want to support DNS SRV. Unfortunately, it's still a non-trivial > undertaking to get the support in the gecko platform that has not been > prioritized on the platform side. For Firefox OS v2 we are hoping to get it > prioritized. Actually, there's an alternate fix for this issue; if Mozilla's ISPDB contains no information related to a particular domain, it could query it using rfc6186, and return that. This means that Thunderbird would still [indirectly] resolve using rfc6186, with no actual changes to the client code.
Shouldn't this depend on bug 14328 instead of 545866?
With the DNS-SD support brought with Flyweb in Firefox, the lack of DNS support in Gecko should have been mitigated. The security implications of using DNS data do not seem worse than those of using the current HTTP based mechanism.
I would love to have this implemented in Thunderbird, as a sysadmin that would like to make it easier for our users to connect to our service. Regarding the security context of this, I actually think it's a great improvement, because it means people are more likely to automatically set up encrypted mail through imap(S) than if they have to manually enter the details. 2. As pointed out the MiTM risk is no worse than the current http method, and the guessing method (which actually uses the wrong server for us) 3. The MITM risk is only at setup time. If the user doesn't use autoconfig, and ends up using unencrypted mail, they are at MiTM risk everywhere they go, every coffee shop wifi, etc. Since the MitM risk is only at setup time, it's extremely hard for an attacker to exploit, because they have to convince the user to delete and recreate the connection in order to be able to hijack the autoconfigure request. 4. Doesn't the current UX flow mean that the users password is only sent to the server *AFTER* the autoconfigure completes and the server details are shown to them? What is the problem here? Doesn't the user get a chance to verify the server details?
If you want to make it easy for users, you can already do that today with http instead of DNS SRV: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration
Attachment #333621 - Attachment is obsolete: true
(In reply to Ben Bucksch (:BenB) from comment #60) > If you want to make it easy for users, you can already do that today with http Literally "http://". Bug 986967 is about that and is a real security problem.
RFC 6186 was published in 2011, but it remained only an option. In January 2018, RFC 8314 was published: https://tools.ietf.org/html/rfc8314 This explicitly sais: > User-configurable MUAs SHOULD support the use of [RFC6186] for account setup. https://tools.ietf.org/html/rfc8314#section-5.1 So please, let's follow the RFC and provide this option in Thunderbird. Thanks, and keep up the good work!
Although RFC8314 is on the standards track, it's more a "best practices" document than an actual protocol definition. It's true that Thunderbird does not implement configuration via DNS SRV (this bug here). There are several fundamental reasons: 1. Arbitrary DNS lookups - bug 545866 / bug 14328 - are not implemented by Gecko. I've spent a lot of time implementing it, over 8 years ago (April 2010), only for the patch to be ignored and not reviewed. Forgive me when I'm a little less excited today. 2. DNSSEC is very hard to administrate without shooting yourself in the foot, and consequently, it's not widely deployed on second level domains. APNIC says: "Unfortunately, our recent study showed that DNSSEC deployment is still very low (only ~1% of .com, .net and .org domains deploy DNSSEC)" https://blog.apnic.net/2017/12/06/dnssec-deployment-remains-low/ On most domains, DNS is completely insecure. I don't see it gaining quickly, either. APNIC <https://stats.labs.apnic.net/dnssec/XA> actually shows declining deployment in the last year. Without DNSSEC, DNS SRV is no more secure than http. In that light, comment 61 is a little ironic. 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 bbob@example.com, 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-in-a-row-and-you're-out security mechanisms. 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. DNS SRV is not widely used now. Why trying to establish a mechanism that has known shortcomings? I think people here want this, because they want a standards-based mechanism. I fully concur with that. But I'd rather make a new standard than implement a bad standard that nobody else implements anyway.
On the up side: Thunderbird already implements most of what RFC8314 requests, including most SHOULDs. In fact, it seems RFC8314 took Thunderbird as reference implementation, and basically says "Everybody should do what Thunderbird does" ;-) .
The goal in RFC 8314 was to reasonably promote security/interoperability improvements without forcing a lot of software to be declared broken. It wasn't actually based on what Thunderbird does, but if that's the impression, that's good. The IETF has backed SRV records in general and email+SRV in particular so the spec followed that trend on the auto-configuration front. If the various ad-hoc proposals for HTTP+XML email auto-configuration were to come up with a single compromise proposal and bring that to the IETF, I wouldn't expect major problems moving that to the standards track, but unless that's done, DNS SRV is the only standard for email account auto-configuration and Thunderbird has a standards-gap by not implementing it.

It's easier to add a dns field, than to configure via a web server
We will hope that the RFC will be applied

For the record (and potential inspiration), implementation of rfc6186 in kmail is done: https://github.com/k9mail/k-9/pull/4719

After 14 years this is still open. What I can't figure out is why not having DNSSEC with RFC 6186 is seen as such a big problem while the currently implemented Autoconfiguration feature gets the information from plain HTTP URLs. Both methods are identically vulnerable to MitM.

Esa, I answered that 3 years ago in comment 63. I mentioned 3 separate reasons. Each reason on its own is a serious problem.

Whiteboard: See comment 63

(In reply to Ben Bucksch (:BenB) from comment #69)

Esa, I answered that 3 years ago in comment 63. I mentioned 3 separate reasons. Each reason on its own is a serious problem.

Thanks, Ben! Some good and valid arguments there. It's just that while the current approach might have some clear advantages over RFC 6186, it doesn't seem any better security wise – quite the opposite. Or does the Autoconfiguration perhaps support HTTPS and HSTS (RFC 6797) with preloading, which would make forcing TLS possible?

(In reply to Ben Bucksch (:BenB) from comment #63)

  1. 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 bbob@example.com, 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-in-a-row-and-you're-out security mechanisms.
    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".

Severity: normal → S3

Hello,

at what stage is the implementation of RFC6186? It seems like it still doesn't work. It would really make life easier for us ISPs.

bug 1852752 seems to be necessary before this can be done

(In reply to Selek Respa from comment #73)

bug 1852752 seems to be necessary before this can be done

Flags: needinfo?(brendan)
Summary: mail account auto-configuration via DNS SRV (possibly with DNSSEC) rfc6186 → mail account autoconfiguration via DNS SRV (possibly with DNSSEC) rfc6186

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

a) This is not good enough, because it's guessing / try&error.
b) We also need to know the authentication method: Password or OAuth2 or CRAM MD5 or SCRAM or one of the other SASL mechanisms. Together with the 2 username forms, there are too many permutations (2 * 5 = 10, just for these 2 factors), and we cannot try them all.
c) The servers may block the user account after too many failed login attempts, so even one pass with all the permutations might lock the user out and make even the working (!) config fail as well. Which, together, makes guessing fairly futile.

We need both username form and authentication method, and we need to be certain about both of them.

If the reasoning is about DNS SRV being a standard: Autoconfig is already a quasi-standard today, supported by over 10 email clients and many servers and server-side software, and we (i.e. the people at the IETF and me) are currently in the process of standardizing it as IETF standard.

Hi,

(In reply to Ben Bucksch (:BenB) from comment #75)

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

[…]

We need both username form and authentication method, and we need to be certain about both of them.

I understand and I agree with the reasons you give here to need both username form and authentication method. I read the draft you are working on too, nice work, thanks for this.

However, in the Autoconfig method there is one missing information, too: what if one can't setup a webserver on port 80 or 443? Think about people with limited port range, for any reason.

That's a real use case not addressed by Autoconfig. Only a kind of mix of DNS + Autoconfig can solve this issue (like the one explained in this outdated but interesting wiki page, but I know this may not be very convenient).

What do you think?

For some hard data, I wrote a script to check all of the config files in Mozilla's IPSDB, which includes over 900 domains. Of those 153 config files, I was able to find a full configuration directly from the provider for 41 of them. I of course first looked for an XML autoconfig file, but then fell back to looking for DNS SRV records. Of the 41 configurations I was able to find, 9 were from DNS SRV records, so by supporting RFC 6186, we could potentially remove at least 9 config files from the ISPDB. See this comment on the ISPDB repository for more information the full results. If anyone wants to reproduce these results or test other providers, the script is available here.

A couple of things to note: The current autoconfig standard that Thunderbird follows already requires looking up the DNS MX record, which without validating the DNSSEC is just as vulnerable as looking up DNS SRV records. In addition, Thunderbird actually already uses DNS SRV records without validating the DNSSEC when determining the CardDAV and CalDAV configuration per RFC 6764. Obviously, we will need local DNSSEC validation in Thunderbird, as well as private DNS with DoH.

Keep in mind though that local dns resolvers on your local cpe might already get the data via dot&doh. Don' tie these requirements together too strictly.

Keep in mind though that local dns resolvers on your local cpe might already get the data via dot&doh. Don' tie these requirements together too strictly.

The problem is that many ISP provided DNS servers do not support DNSSEC, so directly supporting either DoH or DoT would be required for Thunderbird to validate the DNSSEC for those users. For example, if I try to make a DNS request using my default DNS resolver and delv, which attempts to validate the DNSSEC, I just get errors:

$ delv +short example.com
;; broken trust chain resolving 'example.com/DS/IN': 10.255.255.254#53
;; broken trust chain resolving 'example.com/DNSKEY/IN': 10.255.255.254#53
;; broken trust chain resolving 'example.com/A/IN': 10.255.255.254#53
;; resolution failed: broken trust chain

However, if I instead use CloudFlare's DNS resolver, it works as expected:

$ delv @1.1.1.1 +short example.com
23.192.228.80
...

Therefore, if Thunderbird were to support local DNSSEC validation without private DNS, it would be somewhat useless for many users. The good news is that Mozilla has already implemented DoH support in Firefox, so it would just need to be copied over to Thunderbird and enabled (partly bug 1757761). Thunderbird would also need the UI that was added to Firefox in bug 1610741/bug 1596847. My script uses Mozilla's CloudFlare DoH endpoint by default for the DNS record lookups and per the standard, it also shows if it found the configuration using an insecure method (the DNS records were not signed with DNSSEC).

What is really ironic is that Thunderbird's new Thundermail e-mail service actually supports RFC 6186, but this could only be used by other clients:

$ delv @1.1.1.1 +short _imaps._tcp.tb.pro SRV
0 1 993 mail.tb.pro.
$ delv @1.1.1.1 +short _pop3s._tcp.tb.pro SRV
0 1 995 mail.tb.pro.
$ delv @1.1.1.1 +short _submissions._tcp.tb.pro SRV
0 1 465 mail.tb.pro.

DNS MX record ... is just as vulnerable as looking up DNS SRV records

Yes, but we use MX only as fallback when we cannot get the config directly. If possible, we use HTTPS from the provider directly, or ISPDB, which is also HTTPS. But you're recommending to replace these secure mechanisms with the less secure DNS SRV:

by supporting RFC 6186, we could potentially remove at least 9 config files from the ISPDB

In addition, DNS SRV does not provide a solution for reason 3 in comment 63. DNS SRV only provides hostname and port. It's simply lacking the majority of the information: username form, authentication method, OAuth2 server etc.pp.. Scrambling and guessing and try&error are not a solution, esp. when it comes to login, and considering the multiplication of the various factors - that's what we did 15 years ago, before AutoConfig, and it did not work, that's why I invented AutoConfig in the first place.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: