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

[Ken Hornstein]

>ISTM there is a fairly clear use-case for using localdomain to fill out
>an unqualified hostname returned by getaddrinfo().  I have no idea
>whether there are still any platforms on which getaddrinfo() would act
>that way, but if there are, they would want this feature.

Yeah, that kinda dates back to the days where people would put
unqualified hostnames in NIS to make netgroups shorter, so
gethostbyname() would canonicalize to the unqualified name.  I'm
starting to think that localdomain should simply disappear for
1.6/2.0 unless someone can come up with a convincing argument
otherwise.  So ... does anyone use it?  Time to speak up!

>Yeah, mine is the same situation: sss.pgh.pa.us is a domain name, not
>the whole FQDN of any one machine in my house network.  The reason
>I was griping about Message-ID usage is that I prefer the message IDs
>to not expose internal machine names, either.

I guess my thinking at the time was that the Message-ID should be
unique, but other than that you wouldn't care about it.  I never even
look at them unless something weird is going on.  Never even occured to
me that people would even care what they are.

>(BTW, after some experimentation I realized that there is a good reason
>to have post assign Message-IDs rather than let the MTA do it: if post
>does it then the Message-ID gets included in the Fcc-filed copy, which
>at least for me is a significant advantage.  So I don't plan to take
>Ken's advice of dropping the -msgid switch, and will persist with
>hacking the source code to make the message IDs be generated the way
>I want.)

To be fair ... I wasn't suggesting that's what you do; my point
only was that the last time people talked about that, the majority
of responses (actually, all of them) indicated that they didn't use
-msgid.  If people think there's justification for a knob that controls
the hostname used for message-id generation (among other things)
then I'm fine with that.  Contributed code would be welcome.

This whole thing illustrates one common problem with nmh development;
many things inside of the code are serving multiple functions, and
breaking out things that logically should be seperate can have unintended
consequences.

--Ken