Re: [Nmh-workers] 1.5 release, minor nits, and an open call to Jerry Peek

[Paul Vixie]

On 2/3/2012 7:19 PM, Ken Hornstein wrote:
> Now that I've thought about it some more and used the current code,
> I think the precedence should be (in order of higher precedence to
> lower precedence):
>
> 1) From: line in draft
> 2) Setting in .mh_profile
> 3) address@hidden
>
> The alternative was to only do (1).  I've been thinking about this, and
> the problem here is: How do we handle this in a reasonable way?
>
> I think the "better" solution might be this:
>
> - Have all components run through mh-format(5).
> - Install default components files that have the right magic in them to
>   set up a proper From: line.

this sounds right. we can release-note the fact that components files
have to have a From: in them now. most users are installing this as a
package, and the system level components files will be reinstalled to
match new code.

> But if you do THAT then you'll still need to decide what is the "default"
> email address you use.  It seems obvious here that the only place to put
> that is in the .mh_profile.

for users who have their own components files, we can put pretty much
anything in the draft, including address@hidden, since users who don't
like it will read the doco and remove or modify their own components
files. the set of users with this problem has high overlap with the set
of users who reads the doco.

>   So now you've implemented (2) above ((1) has
> already been implemented).  But if you're concerned about bloat, this
> is obviously more code than just having post DTRT.  But I do like the idea
> of the draft having the From: header in it; that makes it clear what
> the user's From: header will be.  I will also confess that I'm starting
> to run short on time I can use to work on nmh, so the idea of writing
> something larger doesn't have a huge amount of appeal to me.

in many sites there are sendmail.cf rules for locally injected e-mail to
fix up From: lines. users can fix any From: problem by editing or
removing their own components files; or, sysadmins can fix any From:
problems by tweaking their MTA settings. i don't see "DTRT" as something
nmh needs to know or can ever know. we have to emit something that's
protocol-compliant, but it doesn't have to be replyable, it just has to
be fixable by the user or the sysadmin.