Subject: PINE, please don't generate headers

From: [email-masked] (Phillip Vandry)
Date: 26 May 1995 18:28:05 -0400

Quite a while ago, I noticed that the message IDs of the messages coming
from PINE do not use the FQDN of the sending host. The reason? It does
a simple uname() call (or something similar, I forget) to fetch the
node name, which is not the FQDN.

I left this alone because it's not a big deal. But IMHO it would be better
to not generate any such headers and leave the task to the MTS. That's how
it works with most/all other MUAs.

Recently, I ran into the same problem with From: lines. Not all of our
users live under the same domain name. We have some which are mapped to
other names (different domain name, possibly different username) using
sendmail 8.6.x's userdb facility. Our mail configuration accomodates
this well. But PINE insists on slapping a constant string on the end of
the username.

The solution I've used for both problems is the same: supress the
generation of the Message-ID: and From: headers in outgoing mail & news.

Why doesn't PINE work that way in the first place? It doesn't make sense
for the MUA to compute the correct values of those headers. It makes many
MUAs to configure when we could get away with only configuring the MDA.
Not to mention complex configurations supported by sendmail but not
some or all MUAs!

My 2 cents...

If anyone is interested in my patches to pine-3.91 to supress these
headers (including the implementation of posting via inews since it was
previously unimplemented), mail me.

-Phil

---

From: Mark Crispin <[email-masked]>
Date: Tue, 30 May 1995 09:07:32 -0700

> node name, which is not the FQDN.

Pine uses a gethostbyname() call to get the FQDN from the official name
return value in the returned hostent structure.  If gethostbyname() does
not do so on your system, it is because your system is misconfigured.
99.9% of the time, it is because you have an /etc/hosts entry for your
local machine which looks like:
	10.20.30.40	blurdybloop blurdybloop.foo.com
when the correct entry is
	10.20.30.40	blurdybloop.foo.com blurdybloop

The first name in /etc/hosts is the official name; all other names are
nicknames.  It is not good to have the FQDN as a nickname instead of the
official name.

> it works with most/all other MUAs.

This makes a big -- and misguided -- assumption.  You are assuming that
the MTA will do the fixup.  This is not true on many systems.  Nor is it
really the proper the role of the MTA to generate MUA fields.

For every system in which sendmail has been carefully crafted to override
the MUAs to do exactly what the system manager wants, there are hundreds
in which sendmail's configuration is straight out of the box.  We have to
make Pine do the right thing for the majority of systems.

Another reason is that the Message ID's identify the generating program
and its version.  This is sometimes useful for us in dealing with bug
reports.  Separate headers often get filtered by gateways.

-- Mark --

DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
Science does not emerge from voting, party politics, or public debate.

---

From: Rahul Dhesi <[email-masked]>
Date: 30 May 1995 22:24:37 GMT

In <looong-message-id> Mark Crispin <[email-masked]> writes:

>If gethostbyname() does
...
>This makes a big -- and misguided -- assumption.
...
>in which sendmail's configuration is straight out of the box.

Here is something from my archives.

Date:    06 Apr 95 00:43:51 GMT
From:    Rahul Dhesi <dhesi>
Newsgroups: comp.mail.pine,comp.mail.sendmail
Subject: Re: Message-ID
Organization: a2i network

In <looong-message-id> Mike Lipscomb <[email-masked]> writes:

>> the former gives a Message-ID  <xxxxx@host>

>I had the same 
>problem until I read the PINE technical docs!  always have the 
>fully-qualified domain name first and then any aliases for the /etc/hosts 
>entry.

After some experimentation I found that although pine will use any
specified 'user-domain' when forming the reply address, it will still
use the local host name for the message-id, and apparently does not 
check to make sure that the part after the '@' is a fully-qualified
domain name.  It *could* append the 'user-domain' after the host name
if the host name does not contain a dot, but does not do so.  The basic
problem is that the MTA is not being given an opportunity to do the
things it knows most about, such as setting the correct reply address
and message-id.  The MUA is trying to do the MTA's job.

A similar design flaw exists in the MH mail system, though it's not as
acute, becaue MH tries to form the reply address but not the
message-id.

What saves the user is that in almost all cases, syntactically-invalid
message-ids will be accepted by receiving software.  I don't believe I
have ever observed email to be bounced or dropped because of an invalid
message-id.  The only likely exception is that if a mail-to-News
gateway preserves the message-id, the gatewayed posting will likely be
dropped by inn sites, unless the gateway takes steps to correct the
syntax in the message-id or generate a new one.  Fortunately most such
gateways just replace the old message-id with a new valid one.

This issue is something to think about, but not worth losing sleep
over.
-- 
Rahul Dhesi <[email-masked]>
"please ignore Dhesi" -- Mark Crispin <[email-masked]>

---

From: [email-masked] (Stephen R. van den Berg)
Date: 31 May 1995 01:22:05 +0200

>gateways just replace the old message-id with a new valid one.

As far as I know, the only two requirements for message id fields
are that:
1. They are unique.
2. To the right of the @-sign, there must be some text that should *look*
   like a domain name.

If Pine chooses to append just the hostname and not the FQDN, then
there is nothing wrong with the generated msgid, as long as (in its
entirity) it is unique (in time and space).
In fact, it doesn't even have to append the hostname, it could append
just any name, as long as it looks like a domain name and as long as
the entire msgid is unique.
-- 
Sincerely,                                                          [email-masked]
           Stephen R. van den Berg (AKA BuGless).

This sentance contains threee errors.

---

From: [email-masked] (John Stanley)
Date: 31 May 1995 19:10:06 GMT

In article <[email-masked]>,
>>gateways just replace the old message-id with a new valid one.

As the manager of a gateway, I have had to include code to massage
message id's received from mail into ones acceptable to news. Mostly 
removing spaces, but also removing illegal characters.

>2. To the right of the @-sign, there must be some text that should *look*

There is also a limitation on what characters they may contain.

>entirity) it is unique (in time and space).

There are two parts of the message id for a reason. There is the local
side, which a system CAN guarantee is unique locally but cannot
guarantee globally, and the FQDN, which can be guaranteed globally
unique but is not locally unique. Together, the whole is guaranteed
globally unique.

There is no guarantee of uniqueness if the host uses only its local
hostname. There are many sites named "skyking" for example, but only
one "skyking.oce.orst.edu". If both used just "skyking", and both used
the same algorithm for message id's (not uncommon, if they both run the
same news code), they can generate the same message id. Unlikely, but
the RFC doesn't say "probably unique".