On 7/20/2005 9:34 AM, Hallam-Baker, Phillip wrote: > If I have pbaker@xxxxxxxxxxxx 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@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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf