Bug 25218 - mailwrapper(8) invokes sendmail when resources are tight
Summary: mailwrapper(8) invokes sendmail when resources are tight
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 4.2-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-02-20 01:20 UTC by peter
Modified: 2024-04-19 22:34 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description peter 2001-02-20 01:20:02 UTC
If mailwrapper can't open /etc/mail/mailer.conf (which may happen when
resources are tight) it defaults to starting sendmail instead of aborting.
This is a terrible bug. Mail administrators everywhere have chosen an MTA
*other* than sendmail. The sendmail configuration on a box might not be
setup correctly. These admins expect mailwrapper to start their MTA :)

Fix: 

Make mailwrapper abort if it can't read /etc/mail/mailer.conf, like it does
when it can't find a mapping.
How-To-Repeat: 
I have not reproduced the situation. It should be obvious from the code.
Comment 1 Kris Kennaway freebsd_committer freebsd_triage 2001-02-24 07:57:07 UTC
Responsible Changed
From-To: freebsd-bugs->peter

peter imported mailwrapper
Comment 2 Peter Pentchev 2001-04-06 13:09:09 UTC
On Tue, Feb 20, 2001 at 01:08:38AM -0000, peter@dataloss.net wrote:
> 
> >Number:         25218
> >Category:       misc
> >Synopsis:       mailwrapper invokes sendmail when resources are tight
> >Originator:     Peter van Dijk
> >Release:        FreeBSD 4.2-STABLE i386
> >Organization:
> Vuurwerk Internet
> >Environment:
> 
> FreeBSD 4.2-STABLE. This code hasn't changed for a while, I think :)
> 
> >Description:
> 
> If mailwrapper can't open /etc/mail/mailer.conf (which may happen when
> resources are tight) it defaults to starting sendmail instead of aborting.
> This is a terrible bug. Mail administrators everywhere have chosen an MTA
> *other* than sendmail. The sendmail configuration on a box might not be
> setup correctly. These admins expect mailwrapper to start their MTA :)
> 
> >How-To-Repeat:
> 
> I have not reproduced the situation. It should be obvious from the code.
> 
> >Fix:
> 
> Make mailwrapper abort if it can't read /etc/mail/mailer.conf, like it does
> when it can't find a mapping.

OK, how about the attached patch?  Made against -current, but applies
cleanly to -stable, too.  I wonder if this could make it into 4.3 :)
(running an unconfigured MTA when resources are tight, possibly to
deliver a critical 'help, I need help!' email, only to fail because
sendmail was not configured properly, does qualify as a serious bug
in my book; and this is not even mentioning the possibility that sendmail
does something wrong in an already messed-up situation..)

G'luck,
Peter

-- 
I had to translate this sentence into English because I could not read the original Sanskrit.

Index: src/usr.sbin/mailwrapper/mailwrapper.c
===================================================================
RCS file: /home/ncvs/src/usr.sbin/mailwrapper/mailwrapper.c,v
retrieving revision 1.5
diff -u -r1.5 mailwrapper.c
--- src/usr.sbin/mailwrapper/mailwrapper.c	2000/05/28 15:02:26	1.5
+++ src/usr.sbin/mailwrapper/mailwrapper.c	2001/04/06 12:04:13
@@ -123,15 +123,10 @@
 		addarg(&al, argv[len], 0);
 
 	if ((config = fopen(_PATH_MAILERCONF, "r")) == NULL) {
-		addarg(&al, NULL, 0);
 		openlog("mailwrapper", LOG_PID, LOG_MAIL);
-		syslog(LOG_INFO, "can't open %s, using %s as default MTA",
-		    _PATH_MAILERCONF, _PATH_DEFAULTMTA);
+		syslog(LOG_INFO, "can't open %s, aborting", _PATH_MAILERCONF);
 		closelog();
-		execve(_PATH_DEFAULTMTA, al.argv, envp);
-		freearg(&al, 0);
-		free(line);
-		err(1, "execing %s", _PATH_DEFAULTMTA);
+		err(1, "opening %s", _PATH_MAILERCONF);
 		/*NOTREACHED*/
 	}
Comment 3 Peter Pentchev 2001-04-06 13:20:46 UTC
On Fri, Apr 06, 2001 at 03:09:09PM +0300, Peter Pentchev wrote:
[snip]
> 
> OK, how about the attached patch?  Made against -current, but applies
> cleanly to -stable, too.  I wonder if this could make it into 4.3 :)

Mmmm here's an updated patch, which also removes the now-unused
default MTA define from pathnames.h (hint given by the submitter
in private e-mail).

G'luck,
Peter

-- 
Thit sentence is not self-referential because "thit" is not a word.

Index: src/usr.sbin/mailwrapper/mailwrapper.c
===================================================================
RCS file: /home/ncvs/src/usr.sbin/mailwrapper/mailwrapper.c,v
retrieving revision 1.5
diff -u -r1.5 mailwrapper.c
--- src/usr.sbin/mailwrapper/mailwrapper.c	2000/05/28 15:02:26	1.5
+++ src/usr.sbin/mailwrapper/mailwrapper.c	2001/04/06 12:19:18
@@ -123,15 +123,10 @@
 		addarg(&al, argv[len], 0);
 
 	if ((config = fopen(_PATH_MAILERCONF, "r")) == NULL) {
-		addarg(&al, NULL, 0);
 		openlog("mailwrapper", LOG_PID, LOG_MAIL);
-		syslog(LOG_INFO, "can't open %s, using %s as default MTA",
-		    _PATH_MAILERCONF, _PATH_DEFAULTMTA);
+		syslog(LOG_INFO, "can't open %s, aborting", _PATH_MAILERCONF);
 		closelog();
-		execve(_PATH_DEFAULTMTA, al.argv, envp);
-		freearg(&al, 0);
-		free(line);
-		err(1, "execing %s", _PATH_DEFAULTMTA);
+		err(1, "opening %s", _PATH_MAILERCONF);
 		/*NOTREACHED*/
 	}
 
Index: src/usr.sbin/mailwrapper/pathnames.h
===================================================================
RCS file: /home/ncvs/src/usr.sbin/mailwrapper/pathnames.h,v
retrieving revision 1.3
diff -u -r1.3 pathnames.h
--- src/usr.sbin/mailwrapper/pathnames.h	2000/01/10 03:20:13	1.3
+++ src/usr.sbin/mailwrapper/pathnames.h	2001/04/06 12:19:18
@@ -32,4 +32,3 @@
  */
 
 #define _PATH_MAILERCONF	"/etc/mail/mailer.conf"
-#define _PATH_DEFAULTMTA	"/usr/libexec/sendmail/sendmail"
Comment 4 peter 2001-04-06 13:24:15 UTC
On Fri, Apr 06, 2001 at 03:20:46PM +0300, Peter Pentchev wrote:
> On Fri, Apr 06, 2001 at 03:09:09PM +0300, Peter Pentchev wrote:
> [snip]
> > 
> > OK, how about the attached patch?  Made against -current, but applies
> > cleanly to -stable, too.  I wonder if this could make it into 4.3 :)
> 
> Mmmm here's an updated patch, which also removes the now-unused
> default MTA define from pathnames.h (hint given by the submitter
> in private e-mail).

Looks good to me :)

Greetz, Peter [submitter]
-- 
dataloss networks
'/ignore-ance is bliss' - me
'Het leven is een stuiterbal, maar de mijne plakt aan t plafond!' - me
Comment 5 Peter Wemm freebsd_committer freebsd_triage 2004-03-29 20:21:09 UTC
Responsible Changed
From-To: peter->freebsd-bugs

Return neglected PR to the pool.  BTW; I strongly object to the 
patches enclosed.  Making a last ditch effort is no worse than 
discarding email without trying.
Comment 6 Peter Pentchev 2004-06-04 07:41:11 UTC
On Mon, Mar 29, 2004 at 11:23:55AM -0800, Peter Wemm wrote:
> Synopsis: mailwrapper invokes sendmail when resources are tight
> 
> Responsible-Changed-From-To: peter->freebsd-bugs
> Responsible-Changed-By: peter
> Responsible-Changed-When: Mon Mar 29 11:21:09 PST 2004
> Responsible-Changed-Why: 
> Return neglected PR to the pool.  BTW; I strongly object to the
> patches enclosed.  Making a last ditch effort is no worse than
> discarding email without trying.


FWIW (as the author of the enclosed patches), with time I've come round
to agree with this point of view.  Even if the default MTA does not
actually succeed in delivering the e-mail, there is a good chance that
it will at least attempt to queue it somewhere so that it is at least
available to be rescued later on.  Peter (submitter), what do you think?

G'luck,
Peter

-- 
Peter Pentchev	roam@ringlet.net    roam@sbnd.net    roam@FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
What would this sentence be like if pi were 3?
Comment 7 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:22 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 8 Warner Losh freebsd_committer freebsd_triage 2024-01-16 04:46:28 UTC
Both Peter and Peter don't like it. We've moved on to DMA. And the inability to open mailer.conf on today's systems is rare. Closing this to reduce the clutter.
Comment 9 commit-hook freebsd_committer freebsd_triage 2024-04-19 22:34:39 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=961bcbeef251b87463446860fca9910a461a3909

commit 961bcbeef251b87463446860fca9910a461a3909
Author:     Lexi Winter <lexi@le-Fay.ORG>
AuthorDate: 2023-12-30 15:09:15 +0000
Commit:     Warner Losh <imp@FreeBSD.org>
CommitDate: 2024-04-19 22:20:44 +0000

    mailwrapper(8): change behaviour if mailer.conf cannot be opened

    Previously, mailwrapper(8) would default to invoking _PATH_DEFAULTMTA
    (i.e., dma) if mailer.conf couldn't be opened for any reason, including
    transient errors like ENFILE.  This behaviour is undesirable, because if
    the administrator has configured a different MTA in mailer.conf, they
    almost certainly don't want mailwrapper to unpredictably fall back to
    the compiled-in default; and in any case, the default MTA is probably
    not running, meaning the mail may be queued and then never delivered,
    which is worse than not accepting it to begin with.

    Change this behaviour depending on why mailer.conf can't be opened:

    - If it doesn't exist, keep the existing behaviour of falling back to
      the default MTA, on the assumption that this is a reasonable default
      if mailer.conf hasn't been configured at all.

    - If it cannot be opened for any other reason, do not invoke an MTA and
      instead return an error to the caller.

    PR: 25218
    Reviewed by: imp, emaste, markj
    Pull Request: https://github.com/freebsd/freebsd-src/pull/969

 usr.sbin/mailwrapper/mailwrapper.c | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)