nmh-workers
[Top] [All Lists]

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

2012-06-05 22:16:21
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

_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>