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
The short answer is no.
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
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.)