Re: SMTP option for DHCPv6

> On 5/27/2005 5:04 AM, Cristian Cadar wrote:

> > There is already a standardized SMTP option for DHCPv4. My question is:
> > Do you know any implementation where SMTP option is used by somebody for
> > delegating IPv4 SMTP server addresses to the clients? do you think that
> > the SMTP option for DHCPv6 will be used in the future by the email
> > clients?

> The short answer is no.

Agreed.

> The long answer consists of multiple parts. For one thing, most of the
> client DHCP stacks are not integrated with application software very well.
> About the best you can expect (and this isn't very good) is for the DHCP
> client to overwrite config data for an application (like updating a
> mail.conf file that it has been told about). Very few applications
> actually make DHCP calls themselves, and in some cases this isn't even
> possible because the DHCP client has bound to the ports and is preventing
> the applications from making their own requests.

> Another point of difficulty here is that DHCP is mostly geared towards
> "host configuration" and not to "user-specific configuration". This has
> some security implications in application layer software--you may not want
> anonymous guest users using your mail server, or your mail server may
> require authentication (which won't work with guests), etc.

Indeed. In the past these sorts of options that silently change configuration
based on remote data have been the source of a lot of user problems and support
headaches. I imagine that even if this option were generally useful - which it
isn't - sites will be reluctant to use it for this reason.

> Along the same lines, mail sessions are keyed to user identity, and user
> identity is independent of the current network topology, while DHCP is
> focused on topology identity.

Additionally, nothing says that a user will have a single email identity. Lots
of users - including many fairly unsophisticated ones - have multiple email
accounts, each one requiring the use of a different server.

> Having said all of that, defining the option could still be useful and the
> work should be done. But I wouldn't expect it to be used except in the
> minor subset of instances where the above factors coincide with actual
> installation considerations.

I will also note that it is essential that the option provide a means of
specifying the port to connect to in addition to the server name, and it might
be best if the default port was the SMTP-submit port 587 rather than port 25.
(I haven't looked at the IPv4 version of the option so I don't know if it
provides this capability or what the default is.)

				Ned