Re: CVS commit: src/bin/hostname

[Ken Hornstein <kenh%pobox.com@localhost>]

>You read it wrong.   I am using hostname for this (though it is hostname(2),
>or possibly uname(2), rather than hostname(1) - that is, nmh just runs the
>sys call, not the command - the value it gets would be the same either way of
>course).   I am using nmh on my laptop, it creates the message-id from my
>laptop's hostname (in the kre.to domain) (and nmh does not have a config
>option to change the message-id generation algorithm I don't think, it
>just does what it knows should work).   My "From" address (which is
>configurable in nmh) is @munnari.oz.au - that's my mail server's
>name, not my laptop's.   That one isn't used in  message-id construction
>(and as that is generated on my laptop, it really can't use that,
>or guaranteeing message-id uniqueness would be impossible).

Since Robert invoked nmh, and I do a fair amount of development on nmh,
I feel it's fair for me to chime in on this point, because some of the
stuff done in nmh is relevant to this discussion.

First off ... regarding "short" hostname versus "long" hostnames: in all
of my early career and exposure to Unix systems (late 80s - early 90s),
they ALL universally were configured so the output of hostname was the
short hostname.  Perhaps this was the wrong configuration; in that case,
nobody told us about that.  It was simply never discussed; the way you
set up your system was that "hostname" returned the short hostname, and
that was that.  There was a lot of SunOS 4 back then, and the convention
was that the domain name was used as the YP domain name, so as I recall
a lot of software would append the domain name to the short hostname to
construct the complete domain name (nmh would do this).  I never saw
setting the hostname to the FQDN until perhaps the mid 2000s, and even
then in my experience it's still very rare, at least in our neck of
the woods.  I make no claim that this is CORRECT, mind you; I'm just
telling you what I've seen.  I say this to make two points: a) it's not
clear in my mind that what "hostname" is supposed to return has been
ever defined, and b) software in general seems to be able to deal with
that; we've never run into any problems that I can ever recall.  FWIW,
nmh has always taken what it gets back from gethostname() and run it
through the resolver library to get something fully qualified.  We did
not invent this behavior; it was inherited from the original MH code.

Secondly ... a large number of the recent changes to nmh have been
to deal with the changing environment.  Back in the day you could
safely assume that appending @$(hostname)$(domainname) to your Unix
username was a valid email address (sometimes you had to run $(hostname)
through the resolver library), but at least for a lot of people that
assumption is no longer valid, for a variety of reasons.  You could
sort-of configure that before in nmh, but it turned out the internal
knobs changed a number of things, so we needed new, more specific knobs.
In looking around at other MUAs, I realized that pretty much all of the
other ones in common use had already dealt with this.  That again shows
that at least for email, all of the common programs in use had dealt
with the general decoupling of your email address having any relation to
your hostname.

And since you brought it up ... newer versions of nmh can generate a
completely random Message-ID (well, everything after the @ is random; the
stuff before the @ uses the same algorithm, which I forget now).  Again,
that's all an outgrowth of the issues with using something based on
$(hostname).  The default behavior is still to use $(hostname) for
everything after @.

However ... regarding the changes to the "hostname" command ... I'm
leaning toward thinking the changes should be reverted, although I don't
feel strongly about it.

--Ken