>> 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