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