[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Hornstein
Subject: Re: [Nmh-workers] 1.5RC3 no longer honors mts.conf localname setting for Message-ID?
Date: Wed, 06 Jun 2012 02:16:50 -0400

>It seems like the cleanest solution would be to have a parameter
>analogous to clientname, that overrides the normal default (ie, the host
>name returned by getaddrinfo) for the specific usage of generating the
>message-ID host part.  This is analogous to clientname in that
>clientname overrides the default for the specific usage of sending the
>HELO message.  If that seems sensible, and we can agree on a name for
>the thing (any suggestions?), I'd be willing to draft a patch.

Seems sensible to me.  So, let's break it down a bit.  LocalName(1) is
used for:

- Message-ID generation
- Content-ID generation
- The SMTP HELO/EHLO message if clientname isn't set.

It sounds like this only applies for the first two (since as you
note the clientname knob already exists); I'm also assuming you
don't want to leak internal hostnames if you're generating a MIME
message.  So maybe ... identname?  idname?  I'm not in love with
either one.

>BTW, thinking about clientname, I wonder why that wasn't folded in as
>another responsibility of LocalName().  I'd certainly be inclined to
>implement localname, clientname, and this new parameter as facets of a
>single mechanism.

Remember that LocalName() taking an argument is new code I wrote for
1.5.  As for the clientname knob ... that's been around forever.  I don't
know if you want to implement command-line switches for this new
thing as well, as there are for clientname (yes, they do exist, but
they aren't documented and I have no idea why anyone would use them).

Actually ... looking in the original mh sources ... that code was added
by John Romine in 1993.  He's still around although I don't know how
often he reads this list, but he'd be the one to ask about it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]