"Todd C. Miller" <[email protected]> wrote: |On Wed, 07 Jan 2015 12:11:40 +0100, Steffen Nurpmeso wrote: |> I seem to recall that OpenBSD dropped -f in December (i don't know |> why), but clashing a POSIX argument doesn't seem to be a good |> idea. Heirloom mailx and S-nail use the -r option for the purpose |> in question, and i think it would be nice if the BSD Mails would |> agree in this respect. | |Mail still supports -f mboxname. The support for passing arbitrary |sendmail options at the end was dropped for security reasons. My
Ok, then i had a false impression back in December. I.e., it was a bit helter-skelter for me and i would have preferred the necessity to reverse the burden of proof for *expandaddr* (a completely braindead name for what happens by the way, aliases get expanded regardless of its setting), so that one could have used set noexpandaddr or set noexpandaddr=fail as a homogenous augmentation of check strictness. (And additionally =restrict and =restrict-fail for S-nail.) Without that reversal it is inhomogenous: not set means it is disallowed (changing a behaviour that existed for over two decades [what i think without really knowing]), but for further restrictions to be applicable one either had to invent yet another variable or add arguments to reverse the meaning of the set variable again: "expandaddr=fail" is odd. That is bad. I didn't implement command line argument suppression, since we require a separating "--" terminator and i still think that who passes through something like this 1:1 is on the completely false road regarding CGI programming. But i'm still learning and i see that it would be nice to be able to disallow such additional arguments on the command line. I think i have to implement an *expandargv* for that -- and again with that "reversed" meaning. Shit. |plan all along has been to use -r like nail when I get a chance. Great, real thanks for that. (S-nail passes the -r argument through the address "parser" and uses the result for sendmail(1)s -f, support for -F will require quite some work but can come from the same -r argument, just as given. But still.) |At this point I'm leaning towards using "sendmail -t -oi" and just |putting the From: line in directly instead of relying on sendmail/smtpctl |to add it for us. We do support message resending and i'm very unsure on how portable sendmail(1)s -t is in respect to resend messages, so i think that route is not possible for us. Thanks and ciao, --steffen
