David Levine <levinedl(_at_)acm(_dot_)org> writes:
Ken wrote:
I'm wondering ... do you really think these gyrations are appropriate
for mhmail?
Back in "the day", needing to change the server used by post and
friends was very rare, so putting it all in mts.conf was reasonable.
But now we have alternate ports and changing servers is more common
(it occurs to me that there's no way of specifying an alternate port
via mts.conf for email submission). We also have options for SASL
and TLS, which are also not configurable via mts.conf (although
maybe they should be?).
So I'm actually thinking that maybe it makes sense to have mhmail
pass through various post options (kinda like what "send" does now).
I noticed that last night when I tried to write a test for
it and saw that it needs a port option.
Should we consider putting an end to the current mhmail?
mhmail's man page says that it is "compatible with nmh", but
it looks like that just means it reads mts.conf. With the
shortcomings you noted.
Can we make send look like mhmail (mhmail with arguments, when
sending)? Then mhmail could be a simple wrapper around it.
The only thing we'd lose is that it would read the profile and
aliases, but I don't see those as a drawback these days. If
it is important, we could add an option to send to not read
them.
mhmail when invoked without arguments is inc, but without
any command line overrides of inc's profile settings.
mhmail, when sending, is busted in 1.5: try it without -from.
So now's our chance.
mhmail has some features, that are relevant to writing quick and dirty scripts
and that send does not have: the -body, -subject and -from switches, specifying
recipients on the command line, and taking the draft from the stdin.
Norman Shapiro
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers