Re: CVS commit: src/bin/hostname

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 25 Jul 2013 20:09:22 +0400
    From:        Valery Ushakov <uwe%stderr.spb.ru@localhost>
    Message-ID:  <20130725160922.GA17192%pony.stderr.spb.ru@localhost>

  | Personal name is also a very misleading analogy.

Agreed, it isn't great, though not really misleading I think.

  | I bet David is
  | addressed as "David" more often than as "David Laight".

Probably.  And hosts are more often (most of them) referred to by their
nickname (hostname without all but the first label).

The point is that it is trivial to convert the full form to the shortened
one (not quite so for personal names as you pointed out, which is one reason
it isn't such a great analogy) and essentially impossible to go the other
way.

  | So when you need to provide a "name" you really must be aware of the
  | context that that name will be used in (by the other party!) and
  | provide a suitable one.  Whether the output of hostname(1) is (or
  | should be) a suitable default for most such contexts is an operational
  | decision.

Agreed.   But we cannot make that decision unless we know what the output
of hostname is defined to be, can we?    No-one is claiming that its value
(especially unmodified) is going to be useful for everyone, just that we need
to know what that value is intended to be, so we can decide if it is
appropriate to use or not.

  | So you tell your MTA what is the globally-unique name that it should
  | use for such purposes.  Whether it is the same one as returned by
  | hostname(1) is a separate question.

And yes, that should be possible - but wouldn't it be better if, for most
users, that extra configuration was not required, even if it is possible?

  | So, if I read this right, you are *not* using hostname(1) for this
  | yourself, why do you insist others should? :) :)

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).

 Aside: nmh doesn't, by default, generate message-id's at all, it normally
 leaves that up to the MSA to do - I prefer to have it done by nmh as I want
 to be able to refer to the message-id of a msg I have just composed and
 submitted, even before it has successfully transferred to the MSA (and I
 certainly do not want to have to wait until the message comes back to me,
 if it ever does, to find out what message-id was assigned to it.)  I suspect
 most users simply don't care, which is fine.

  | Software shouldn't assume it, it should check/enforce it.  E.g.
  | postfix complains if the name is not an FQDN.

But doing that *is* assuming it - that's the point.   That is, it is
assuming what value should be there.   Good software will always validate
its input data, rather that simply assuming it is correct, as much as
is possible anyway (checking the name is a fqdn doesn't check that the same
fqdn isn't assigned to some other host as well, nor that it is legitimately
assigned).   But when it does that, postfix (if it does as you say, I don't 
know, I don't use postfix) is assuming that the hostname is supposed to
contain a fqdn.   If the people who believe that the hostname data should
be just the nickname were correct, then by complaining when that is the
result it gets, postfix would be broken, and should be fixed.   It isn't,
complaining is just fine - and reinforces the point that the hostname should
be set to a fqdn, which is what I am trying to say here... (and consequently,
of course, hostname(1) doesn't need an option to cause it to convert the
name it gets from hostname(2) into a fqdn - just to relate this message back
to the original thread.)

  | And "what assumptions software can make" also reminds me of the whole
  | domainname - the NIS one - mess.  IIRC, at that time a lot of programs
  | assumed that hostname was the short form and that FQDN is obtained by
  | adding domainname.

Of course, we need good documentation of what the value should be, and
what assumptions one is intended to be able to make about that value.
I think that somewhere in the NetBSD doc, it does actually say to use a
FQDN, though I don't recall at the minute where I saw that.   That mess
was because it wasn't clear what the role of each name was to most users,
and all they saw was the labels, which kind of created confusion.

kre