A few comments on draft-daboo-srv-email: There's no way for a service provider to describe the order of preference for the various protocols. For instance, we support both IMAP and POP but we strongly prefer our users to use IMAP, however Outlook's autoguess feature prefers POP. We could, I suppose, not deploy any _pop3 SRV records, but then that means POP-only clients can't autoconfigure themselves. The priority question also applies to imap/imaps and pop3/pop3s - some paranoid firewall admins are prepared to let ports 995 and 993 through because they know passwords will be encrypted, but not 143 and 110. [Insert rant about smtps here.]
The requirement to use the "service domain" in server certificates conflicts with current practice, which is to use the server host name. For example our server hostnames have the form imap.hermes.cam.ac.uk, which also appears in the certificate CNs - not hermes.cam.ac.uk. This implies that our servers would have to support TLS Server Name Indication to the extent of being able to present differing certificates, which AFAIK they can't currently do. The draft ought to recommend that clients keep configuration discovery separate from normal operation. That is, clients should (1) do the SRV lookups (2) make trial connections to discover TLS capabilities and login name formats (3) ask the user ONCE to confirm that everything is correct (4) save this information (5) when connecting to the server during normal operation, verify that the saved configuration is still correct wrt the real world, and if it isn't, ask the user if they want to try reconfiguring, but do not automatically fall back to a less secure setup. Cacheing the configuration avoids repeated login failures if the server doesn't support full-email-address login names; it avoids repeated questions to the user about service domain / server hostname mismatches; it avoids some DNS attacks; and it avoids STARTTLS downgrade attacks. (The continued existence of "TLS when available" options in most MUAs is a disgrace.) The specification needs to be clearer about what it means for a service domain and a server host name to match. It has often been noted that MUAs can do nearly as well without explicit SRV records just by guessing. However if the following wishes were answered then draft-daboo-srv-email might be worth implementing. It would be nice if there were some kind of virtual domain support, e.g. so a customer of an ISP can just redirect MUAs to their ISP's mail servers, preferably by changing two DNS records instead of six. Even better if this means the ISP's mail servers don't have to have TLS certificates for each of their customer domains. I would really like support for virtual domains which have multiple back-end servers, for example, cam.ac.uk is served by hermes.cam.ac.uk and admin.cam.ac.uk and medschl.cam.ac.uk and mole.bio.cam.ac.uk et cetera ad nauseam. Ideally given an @cam email address the MUA could present the user with a list of potential back ends. It would also be nice if we could attach descriptive text to the domain, such as "University of Cambridge Computing Service - Hermes email service". To step back a bit, perhaps it would be easier to solve all these problems by defining a simple (XML?) configuration document which an MUA could download. This suggestion is not a million miles from the autodiscover support in Microsoft Outlook 2007, except that its protocol is a disgusting series of hacks which is best used as an example of how not to do it. http://fanf.livejournal.com/95018.html I wonder if NAPTR would be useful part of a clean autodiscover protocol, instead of SRV. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
