If you have a profile entry under "post", it really isn't for the
program post(8); they're for a program who's argv[0] is "post".
OK. Would this always be through a postproc entry? See below for
why I ask.
A user could replace the installed post with their own program, but
I'd argue that they should use postproc.
I was actually thinking of the inverse; they could call another program
"post" and expect the profile to work for that. Which like I said is
strange, but permitted.
But ... if you're not convinced, how about a compromise? send(1) is
the normal front-end to post(8); how about have it check and issue a
warning, rather than all programs?
Well, that would miss mhmail, whom, rcvdist, and viamail. And
whatnow push, though I don't think there's a need to help diagnose
use of a post profile entry with that.
Well, out of those, I don't think we'd want a warning to be issued by
rcvdist no matter what, right? That's not a program a user normally
runs on the terminal; it's usually run by slocal or something similar.
And I do wonder how many people use viamail, since there's not even
a man page for it.
Here's my take: I am of the opinion that we shouldn't issue a warning
at all (for the reasons in my previous email). I proposed a compromise
with send, because I think that would accomplish the goal of letting
the user know there is a possible misconfiguration when sending email,
and it would be easy to add a flag to send to suppress the override.
Yes, it would miss things like mhmail and whom, but I have to believe
that the vast majority of uses of post are via send; that just seems a
logical place to put it. Having OTHER programs which aren't sending
email warn about a possible problem with a post entry in the profile
seems wrong.
--Ken
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers