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. tony(_dot_)finch(_at_)ucs(_dot_)cam(_dot_)ac(_dot_)uk)
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 <dot(_at_)dotat(_dot_)at> http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.