Subject: Message ID

From: "David E. Martin" <[email-masked]>
Date: Mon, 8 Feb 1993 17:38:50 -0600

I'm having a problem with the Message-ID: header line.  Message IDs
should have the form
Message-Id: <[email-masked]>

but since I have my Sun hosts yp database set up as
...
131.225.40.41   nhmpw2 nhmpw2.hep.net
...

I get
Message-Id: <Pine.3.03.9302081747.A5911-5100000@nhmpw2>

I have 
user-domain=hep.net
in my pine.conf file, but it seems to be ignored when constructing
message IDs.

I have temporarily fixed the problem by re-ordering the entries
in the hosts yp database to be
...
131.225.40.41   nhmpw2.hep.net nhmpw2
...

but this breaks other things, like bootparams, which now seems to
demand entries have fully qualified domain names.

Any ideas?

David E. Martin
National HEPnet Management                      ||    Phone: +1 708 840-8275
Fermi National Accelerator Laboratory           ||    FAX: +1 708 840-8463
P.O. Box 500, MS 368; Batavia, IL 60510  USA   /  \   E-Mail: [email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Mon, 8 Feb 1993 22:58:12 -0800 (PST)

Hi -

     I'm surprised that your system really cares about the precise contents of
the Message-ID, since it is defined syntactically only.  I hope this is only
an esthetic issue.

     However, it really is important that the fully-qualified domain name
(FQDN) be listed before any nicknames or non-FQDNs in any host table.  In
several places internally, Pine uses the results of the equivalent of:
  gethostname (tmp,TMPLEN);
  myhostname = gethostbyname (tmp)->h_name;
to get the fully-qualified domain name.

     You may have other strange side effects caused by Pine's inability to get
the FQDN.  I'm surprised you haven't seen any by now.  Arguably, it's a bug
that YP and host tables allow a non-FQDN to show up as the result of the above
code sequence, but the sad reality is that they do...  :-(

     On my machines, I use FQDNs in my bootparams.  In general, I consider
non-FDQNs to be only for user typing convenience, and stick to FQDNs in all
configuration files, etc.  It makes life a lot easier and simpler just to
assume that only FQDN's work.  If you can do this, this may help a lot.

     Another possibility is to punt things like YP and NetInfo and stick with
the DNS, but I understand that that may not be a feasible or useful suggestion
for you.

-- Mark --

---

From: Paul Sutton <[email-masked]>
Date: Tue, 9 Feb 1993 10:05:11 +0000 (GMT)

> the Message-ID, since it is defined syntactically only.  I hope this is only

We had the same situation as the poster; for historical reasons we do not
have the FQDN in the hosts table. I wanted to ensure that the message-ID
contained the FQDN to ensure that the message-id's generated were unique.
I suppose it might be aesthetic only, but I can't see how you can
guarantee that message-ids are unique if you don't use the FQDN. 

> to get the fully-qualified domain name.

I think that the only place that obtains the hostname is the OS specific
files (os-unx.c, etc). This is stored into hostname[] for use elsewhere.
Based on this assumption I made a simple modification to gethostname() to
ensure that hostname[] always had our domain name taked onto its end.

> assume that only FQDN's work.  If you can do this, this may help a lot.

I agree with you, and if we started our systems from scratch we'd use
FQDNs everywhere. However, at the moment and for the immediate future we
are stuck with short names (changing to FQDN is not a trivial task, since
the hostname is used as a key is many places which will break when it is
changed). 

Paul
--
Paul Sutton                | Computer Centre, University of Bradford, 
[email-masked]  | Bradford, UK. Tel +44.274.383319

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 9 Feb 1993 11:36:30 -0500 (EST)

> ensure that hostname[] always had our domain name taked onto its end.

What library calls or other do you use to look up to domain you tack on? 
You might just send the code.

This is a common annoyance with Pine and I would like to see it fixed, but
in a way that folks installing Pine wouldn't have to worry about it. (No
compile time configuration). 

LL

---

From: Paul Sutton <[email-masked]>
Date: Wed, 10 Feb 1993 12:40:44 +0000 (GMT)

> compile time configuration). 

I'm afraid I don't do anything clever (or portable!) - just a straight
modification to os-unx.c to force the adding of our domain (which is
hard-coded in, ugh!). (It would be better if it got the domain from the
user-domain, maybe, or from the DNS, but I wanted to make the minimum
amount of changes to the source code so that I could apply it to future
versions without hassle!). 

Still, it works for us, so it may be useful, so here's the context diff
(if you aren't using os-unx as your OS specific files you'll have to apply
this to os-???.c instead). 

*** os-unx.c.orig       Thu Sep 17 16:17:23 1992
--- os-unx.c    Thu Sep 17 16:19:31 1992
***************
*** 986,991 ****
--- 986,993 ----
          strncpy(hostname, hname, hsize - 1);
      } else {
          strncpy(hostname, he->h_name, hsize-1);
+       if (strindex(hostname, '.') == NULL)
+          strcat(hostname, ".brad.ac.uk");
      }
      hostname[hsize-1] = '\0';

Paul

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 12 Feb 1993 09:10:07 -0500 (EST)

Yes, that's the problem. The only two ways I know to find out a systems
domain is to query the hosts table, DNS, NIS... or to read
/etc/resolv.conf. The best way to do it is to look it up with DNS, NIS and
such, but if you've got the entries in your hosts table unqualified
there's not much that can be done. 

I think you wind up having to have some hueristic that tries to decided if
the name you've got is fully qualified or not. (It could have a list of
top level domains hard coded or require at least two clauses separated by
a dot.) 

Given that we don't want the method set at compile time there are two
choices. (Don't want extra configuration hassle for system administrators
since ease of administration is also a Pine goal). 

1. Look up the name in /etc/hosts (DNS, NIS or YP) and try and fully
   qualify it with whats in /etc/resolv.conf if it's not qualified

2. Get the systems idea of the host name (via the hostname() call), decide
   if it's fully qualified or not and then try and fully qualify it 
   with what's in /etc/resolv.conf

Wither case we have to have the hueristic to decide if a name is fully
qualified or not, and this seems like a bad idea.

Personally, I would suggest just overriding all the look ups by setting
the user-domain in the .pinerc or pine.conf files. This does leave the
message ID unqualified, but I'd guess the likelyhood of a problem is
small. Most applications don't use it, and most host names are unique
(unless you use pc1-n, mac1-n or names of planets). 

Perhaps a solution to this in Pine might be to use the longer of the name
looked up in /etc/hosts and the name set in the user-domain variable,
assuming the longer is more unique.

Hope this makes sense....

LL