Re: [Nmh-workers] 1.5RC3 no longer honors mts.conf localname setting for Message-ID?

[Ken Hornstein]

>I notice that Message-IDs are now generated using LocalName(1),
>ie, it ignores any "localname" setting from mts.conf.  This seems
>bizarre and unfortunate, as surely forcing the Message-ID host part
>is one of the main use-cases for setting localname in the first place.

... really?  Last time this came up, the vast majority of people do not
use nmh to generate Message-IDs; they let the MTA do it.  The main
use of the localname setting (in my experience) was in the address parser
and generator routines.

>For the moment I intend to carry a local patch to s/1/0/ at those call
>sites, but I wonder if this decision could be revisited.  (I failed to
>find any discussion of it in the archives, though quite likely I didn't
>know what to search for.)

So ... that happened in commit f931795fd8973c1edb40a26ecf87dbe27f7a6148,
February 3rd.  It was part of the Great From Header cleanup.  Let me
expand on that a bit more.

LocalName() serves two purposes.  Purpose 0 is to serve as part of
the address parsing routines; it's the default local hostname, gets
used to build your From: header, etc etc.  This doesn't necessarily
correspond to your "true" hostname.

Purpose 1 is to serve as a generator for various unique-things that
are required by the RFCs (there is one other purpose, but it doesn't
really matter for this discussion).  Example: if I set my localname
to pobox.com (I don't) and I made your suggested change then I'd
generate Message-IDs that would be under pobox.com, and given the
amount of email that goes through pobox.com there would be no way I
could guarantee it's uniqueness.  There isn't a wonderful answer in
this case, but I would argue that a better answer is to use your
local hostname.  Hence the reason for the split; I tried to make
reasonable choices about where LocalName() was being used for email
and where it was being used as a unique identifier.

>BTW, while I am looking at this, it seems even more bizarre that
>LocaleName will apply "localdomain" even when it's ignoring "localname".

Not at all; if localname is unqualified, then it makes perfect sense
to append localdomain.

--Ken