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) `whoami`@`hostname`
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 whoami@hostname, 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.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers