--On Wednesday, January 06, 2010 17:38 +0000 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:
On Wed, 6 Jan 2010, Alexey Melnikov wrote:
I think there is value in just being able to do easy MUA
configuration for an email address. Something based on DNS is
going to be easy to deploy. SRV RR are more widely deployed
and supported, that is why draft-daboo-srv-email is using
them.
But what is the motivation to implement and deploy the SRV
record scheme? An MUA can do better (better coverage, easier
deployment) by probing several common setups until it finds
one that works. Outlook 2007 already does this (sorry, can't
find a more detailed description than
<http://support.microsoft.com/kb/287532>) and it looks like
Thunderbird has something similar in hand. All it requires
from the operator is to use common host names for the various
servers. So I think this draft does too little too late.
I'm inclined to agree with Tony, especially the moment the
question moves past "find the nearly Submission server" toward
"find the mail". The marketplace seems to have decided that
hunting around the DNS for commonly-used naming structures and
then probing is sufficient. Given the difficulties of finding
the "right" domain with which to associate an SRV record, it
seems unlikely that this proposal will add significant value to
that approach, even though I think it definitely would have been
a good idea some years ago. Conversely, serious per-user
configuration, which requires multiple parameters, an understand
of security mechanisms used, locations of user mailboxes and
protocol and access mechanisms for them, etc., almost certainly
requires the ability to retrieve a configuration file (in some
plausible format), not just the identity of a host providing a
mail-specific service.
Such a file could also do two things that no "find the server"
mechanism can provide: (i) deal with the POP/IMAP (or really
POP/IMAP/Webmail) question on a per-user or per-environment
basis and (ii) deal with multiple mailboxes, on multiple
servers, for the same user in an efficient way. I think both
are realistically necessary today in a world where signing up
for various IM or other services carries mailboxes with them.
For that purpose, one could think of any of the approaches that
have been mentioned, even though my mentioning ACAP was intended
mostly as a bad joke and sad commentary about a lost opportunity.
Like Tony, I don't think Outlook's approach is the right answer:
I think it could be a good place to start thinking about how to
do things right, but what I remember of its actual mechanism,
refreshed by Tony's notes, is that it isn't something we (or
probably even Microsoft today) would want to standardize. A
careful look at why ACAP never really got any traction would
also be instructive.
john