Discussion:
_PATH_SENDMAIL in lots of places outside of lpd stuff also
Chris Bennett
2016-01-30 01:54:52 UTC
Permalink
I found a subroutine in printjob.c called sendmail with uses _PATH_SENDMAIL.

I found it all over the place:

blue src # ack _PATH_SENDMAIL
include/paths.h
63:#define _PATH_SENDMAIL "/usr/sbin/sendmail"

usr.bin/calendar/io.c
410: execl(_PATH_SENDMAIL, "sendmail", "-i", "-t", "-F",
412: warn(_PATH_SENDMAIL);

usr.bin/mail/send.c
422: cp = _PATH_SENDMAIL;

usr.bin/rdist/docmd.c
137: _PATH_SENDMAIL);
140: error("notify: \"%s\" failed\n", _PATH_SENDMAIL);

usr.bin/sendbug/sendbug.c
339: execl(_PATH_SENDMAIL, "sendmail",

usr.bin/skeyaudit/skeyaudit.c
215: execl(_PATH_SENDMAIL, "sendmail", "-t", (char *)NULL);
216: warn("cannot run \"%s -t\"", _PATH_SENDMAIL);

usr.bin/vacation/vacation.c
475: execl(_PATH_SENDMAIL, "sendmail", "-f", myname, "--",
477: syslog(LOG_ERR, "can't exec %s: %m", _PATH_SENDMAIL);

usr.bin/vi/common/recover.c
826: if (_PATH_SENDMAIL[0] != '/' || stat(_PATH_SENDMAIL, &sb))
828: _PATH_SENDMAIL, "not sending email: %s");
838: "%s -t < %s", _PATH_SENDMAIL, fname);

usr.sbin/cron/config.h
40:#define MAILARG _PATH_SENDMAIL /*-*/

usr.sbin/lpr/lpd/printjob.c
1079: if ((cp = strrchr(_PATH_SENDMAIL, '/')) != NULL)
1082: cp = _PATH_SENDMAIL;
1083: execl(_PATH_SENDMAIL, cp, "-t", (char *)NULL);

Chris
Michael McConville
2016-01-30 02:18:14 UTC
Permalink
Post by Chris Bennett
I found a subroutine in printjob.c called sendmail with uses
_PATH_SENDMAIL.
Are you implying that they should be replaced? IIUC, we create a
sendmail binary (or at least a link) even though we no longer
technically use sendmail. See usr.sbin/mailwrapper.

That said, _PATH_SENDMAIL could be deprecated for other reasons. I'm
just guessing at what you meant.
Post by Chris Bennett
blue src # ack _PATH_SENDMAIL
include/paths.h
63:#define _PATH_SENDMAIL "/usr/sbin/sendmail"
usr.bin/calendar/io.c
410: execl(_PATH_SENDMAIL, "sendmail", "-i", "-t", "-F",
412: warn(_PATH_SENDMAIL);
usr.bin/mail/send.c
422: cp = _PATH_SENDMAIL;
usr.bin/rdist/docmd.c
137: _PATH_SENDMAIL);
140: error("notify: \"%s\" failed\n", _PATH_SENDMAIL);
usr.bin/sendbug/sendbug.c
339: execl(_PATH_SENDMAIL, "sendmail",
usr.bin/skeyaudit/skeyaudit.c
215: execl(_PATH_SENDMAIL, "sendmail", "-t", (char *)NULL);
216: warn("cannot run \"%s -t\"", _PATH_SENDMAIL);
usr.bin/vacation/vacation.c
475: execl(_PATH_SENDMAIL, "sendmail", "-f", myname, "--",
477: syslog(LOG_ERR, "can't exec %s: %m", _PATH_SENDMAIL);
usr.bin/vi/common/recover.c
826: if (_PATH_SENDMAIL[0] != '/' || stat(_PATH_SENDMAIL, &sb))
828: _PATH_SENDMAIL, "not sending email: %s");
838: "%s -t < %s", _PATH_SENDMAIL, fname);
usr.sbin/cron/config.h
40:#define MAILARG _PATH_SENDMAIL /*-*/
usr.sbin/lpr/lpd/printjob.c
1079: if ((cp = strrchr(_PATH_SENDMAIL, '/')) != NULL)
1082: cp = _PATH_SENDMAIL;
1083: execl(_PATH_SENDMAIL, cp, "-t", (char *)NULL);
Chris
Chris Bennett
2016-01-30 02:46:56 UTC
Permalink
Post by Michael McConville
Post by Chris Bennett
I found a subroutine in printjob.c called sendmail with uses
_PATH_SENDMAIL.
Are you implying that they should be replaced? IIUC, we create a
sendmail binary (or at least a link) even though we no longer
technically use sendmail. See usr.sbin/mailwrapper.
That said, _PATH_SENDMAIL could be deprecated for other reasons. I'm
just guessing at what you meant.
Well, sendmail is no longer in base.
But sendmail is installable from ports.
There are also many programs out there that have modules written to use
actual sendmail. I use a forum software OO Perl that has a sendmail
module that is not playing nice with femail-chroot under Apache.

Right now I am working on bringing the lpd system out of the 1970's and
add features (at some point) to make it worthy of not needing to install
something like CUPS (Have you read the license on that! Ugly!).
So I am having to make big changes.

Since I'm working at clearing off the dust and throwing out the old junk
right now, I might be overly biased. Perhaps it is worth the effort to
replace yet more "historic" bits once and for all.
Maybe not.

Maybe someone who wrote our nice new OpenSMPTD would have a more
valuable opinion.

In any case, my email was just meant to show I found a similar problem
outside of my current work. Nothing more. Just trying to be helpful.

Chris
Michael McConville
2016-01-30 03:04:13 UTC
Permalink
Post by Chris Bennett
Post by Michael McConville
Post by Chris Bennett
I found a subroutine in printjob.c called sendmail with uses _PATH_SENDMAIL.
Are you implying that they should be replaced? IIUC, we create a
sendmail binary (or at least a link) even though we no longer
technically use sendmail. See usr.sbin/mailwrapper.
That said, _PATH_SENDMAIL could be deprecated for other reasons. I'm
just guessing at what you meant.
Well, sendmail is no longer in base.
But sendmail is installable from ports.
Right, but we emulate it by using the same binary name. I'm not sure
whether there's a suggested alternative. It seems if there were an easy
replacement, the existing _PATH_SENDMAIL uses would have been removed.
Chris Bennett
2016-01-30 03:42:46 UTC
Permalink
Post by Chris Bennett
Post by Michael McConville
Post by Chris Bennett
I found a subroutine in printjob.c called sendmail with uses _PATH_SENDMAIL.
Are you implying that they should be replaced? IIUC, we create a
sendmail binary (or at least a link) even though we no longer
technically use sendmail. See usr.sbin/mailwrapper.
That said, _PATH_SENDMAIL could be deprecated for other reasons. I'm
just guessing at what you meant.
Well, sendmail is no longer in base.
But sendmail is installable from ports.
There are also many programs out there that have modules written to use
actual sendmail. I use a forum software OO Perl that has a sendmail
module that is not playing nice with femail-chroot under Apache.
Right now I am working on bringing the lpd system out of the 1970's and
add features (at some point) to make it worthy of not needing to install
something like CUPS (Have you read the license on that! Ugly!).
So I am having to make big changes.
Since I'm working at clearing off the dust and throwing out the old junk
right now, I might be overly biased. Perhaps it is worth the effort to
replace yet more "historic" bits once and for all.
Maybe not.
Maybe someone who wrote our nice new OpenSMPTD would have a more
valuable opinion.
In any case, my email was just meant to show I found a similar problem
outside of my current work. Nothing more. Just trying to be helpful.
Chris
Sorry, I know better than to whine without sending a patch or looking
things over better. I have seen enough of these stupid emails to make me
sick. Hopefully no hard feelings caused. I'll shut up now and get my
head back into what I'm actually working on.

Chris
Philip Guenther
2016-01-30 05:14:32 UTC
Permalink
On Fri, Jan 29, 2016 at 6:46 PM, Chris Bennett
Post by Chris Bennett
Post by Michael McConville
Post by Chris Bennett
I found a subroutine in printjob.c called sendmail with uses _PATH_SENDMAIL.
Are you implying that they should be replaced? IIUC, we create a
sendmail binary (or at least a link) even though we no longer
technically use sendmail. See usr.sbin/mailwrapper.
That said, _PATH_SENDMAIL could be deprecated for other reasons. I'm
just guessing at what you meant.
Well, sendmail is no longer in base.
But sendmail is installable from ports.
As are exim and postfix, and the de facto standard CLI interface for
submitting an email message to any of the MTAs that run on OpenBSD is
to invoke "sendmail" with a standard set of options and arguments.
Post by Chris Bennett
There are also many programs out there that have modules written to use
actual sendmail.
I think the vast majority are written not to the full CLI of "sendmail
by Eric Allman", but rather a subset CLI which all the MTAs now
provide their own version of, with -f, -t, maybe a couple others, and
a bunch of options which are ignored. All those random program aren't
trying to specifically run "sendmail by Eric Allman" but rather
"whatever the locally configured mail submission agent is".

Perhaps it's confusing, but it was the solution that basically all the
OS distributions settled on when alternative MTAs first started being
developed. At least the name actually reflects what the API does!


...
Post by Chris Bennett
Since I'm working at clearing off the dust and throwing out the old junk
right now, I might be overly biased. Perhaps it is worth the effort to
replace yet more "historic" bits once and for all.
Maybe not.
Hmm, do you know of a CLI API for mail submission which is *more*
common than "invoke sendmail with -f/-t/addresses"?

We wouldn't want to hard code "smtpd" or "smtpctl" there, as then it
would stop working on systems where exim or postfix was the configured
MTA.


Philip Guenther

Loading...