On Thu, 7 Jan 2010, Cyrus Daboo wrote: > > The SRV solution is simple to implement - most OS network libraries now > provide simple access to SRV record results. Site and domain admins > these days are much more comfortable with setting up SRV (required for > services like XMPP). So I think SRV represents a simple solution that > can be adopted in a reasonable timeframe.
I have a stronger argument for the (potential) simplicity of SRV records: I've started writing a draft describing Outlook-style MUA configuration autoguessing. (I'm afraid the meat of it is still in my head, but once I have it salted and packed in XML it should become available as draft-fanf-mua-autoguess.) The exercise of describing all the probes that an MUA needs to perform and all the awkward cases it has to be aware of has made me realise that SRV records can make autoconfiguration MUCH simpler for the MUA author. (The issue of APIs for SRV lookup is trivial in comparison.) The key point is that at the moment an autoguessing MUA cannot assume any co-operation from the site operator, whereas we can require that the existence of MUA SRV records on a mail domain implies a certain service profile. This can massively reduce the amount of work that the MUA must do to configure itself. For example, the MUA can assume that the IMAP and POP services are actually related to the mail domain; it can ignore imaps and pop3s and port 25; it can assume that TLS is required; it can assume that the same login credentials will work for POP and IMAP and message submission; none of which are true when autoguessing. We could perhaps guarantee that if the service operator publishes SRV records for both IMAP and POP and both are supported by the MUA, then everyone agrees that IMAP is the one to use. Maybe we could also eliminate the guesswork needed to work out the user's login credentials. Outlook tries both the whole email address and the local part, but this can fail if (say) the user has a "friendly name" email address (e.g. [email protected]) which doesn't match their login name (e.g. fanf2). Perhaps we could require that the user's email address is a valid login name even if it is an alias of this kind. This kind of guaranteed service profile provides a fairly strong motivation for MUA authors to implement SRV-based autoconfiguration, at the expense of stricter requirements on email service operators. But I think most of the requirements are reasonable and many sites already follow them, so probably all that a site has to do is buy a new TLS certificate and publish a couple of SRV records. (Though I don't know if there's decent support for the TLS server name extension.) The only tricky requirement is email addresses as login names. If we add that guarantee then the MUA does not need to make any trial connections to get a correct configuration. However it is probably too much of a burden on email service operators. 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.
