On 7/20/2005 9:34 AM, Hallam-Baker, Phillip wrote:
If I have pbaker(_at_)verisign(_dot_)com there is only going to be one set of
servers for incomming mail for that address, the place for POP3 and
IMAP4 services is obvious.
Traditionally it was possible to choose the outgoing mail service. That
option is effectively closing due to spam control measures. But even if
the email service has a choice of outboud email relay it is a limited
choice and this does not affect the means used to advertise each relay.
Finding your retrieval servers is harder still. You may get lucky with
somebody's local submission servers, or you may have different internal vs
external submission servers on your home network that you access based on
where you are currently located, but your retrieval servers don't ever
change based on location information. This is partly due to the way that
repositories are generally bound to the disks they are stored on, but also
partly due to the way that retrieval clients preserve state across session
lines (such as remembering which messages have already been seen).
Worse is that your retrieval server's location is specific to your account
within a domain, and not tied to the domain itself. I mean, user(_at_)comcast
could have their mailstore in Nashville or any other city, so the user@
part is really the lookup key that matters.
http://www.ehsco.com/misc/I-Ds/draft-hall-email-srv-02.txt tries to deal
this with by pushing some of the algorithm to the server administrator,
although that's not something I'm not really happy with since it allows
for different responses in different cases, which isn't what protocols are
supposed to do. An artifact of this vagueness is that the service is
declared as only being usable for initial configuration and not really
useful for ongoing configuration.
Making it work would require generating queries for the servers associated
with localpart.domain.dom (ie, your email address), which is fraught with
problems, large and small. One of the bigger problems is that I'm opposed
to storing user data in the DNS on principle--DNS is a miserable directory
and trying to make it one would make it a miserable naming service. But
the IETF has not produced a workable distributed directory service. So
we've got a real dilemma here.
About the best we can do at the moment is to make it vague and limit the
lookup role accordingly.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf