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



Reply via email to