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

[Tom Lane]

Ken Hornstein <address@hidden> writes:
> Hrm.  I guess I hadn't completely thought about the implications
> of how localdomain was implemented; I didn't really think about the
> issue of LocalName(0) versus LocalName(1).  But your point is well
> taken; it doesn't really make sense to apply localdomain to both,
> does it?  I think that if you're using localname you would be
> expected to supply a FQDN, and localdomain should only apply in the
> LocalName(1) case.

> My gut feeling is that localdomain is so rarely used nowadays that
> it's not worth fixing it for 1.5.  Thoughts from anyone else?  For
> post-1.5 I'd be fine with either using localdomain for only the
> LocalName(1) case or junking support for it completely.  Or perhaps
> doing something else altogether.  Thoughts?

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.  On the other
hand, it's not clear to me what the use-case is for specifying an
unqualified localname and then filling it out with localdomain; why not
just write localname as the FQDN to start with?  It seems like the first
method could possibly be useful if there are any places where localname
is used without appending localdomain, but I don't see any such places
in the current code.  (Not that I know the code well enough to know
whether there are any non-obvious access paths.)

So AFAICS it makes sense to redefine localdomain as only being used
with the getaddrinfo result.  Furthermore, if the LocalName(0) versus
LocalName(1) business is new in 1.5, I'd argue for making the change
now, so that people only have to cope with one behavioral change
not two successive ones.

                        regards, tom lane