Subject: RE: SRV continued

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 20 Jul 2005 06:34:22 -0700

> Because it raises some very "interesting" issues about just 
> which server a particular client should be bound to.  The 
> network-nearest available one or  the one associated with the 
> same organization as the client are typical possibilities 
> (along with the somewhat vague "email address") and, if the 
> wrong one is chosen, it may be inaccessible.  

The user still needs to specify their email address. I get my IP service
from comcast but I do not use their mail service. This is why I do not
see DHCP as a mechanism.

If I have [email-masked] 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.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 20 Jul 2005 12:03:55 -0400

> 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/