Subject: READ ME! If you don't your sendmail will stop working!
To: None <current-users@netbsd.org>
From: Perry E. Metzger <perry@piermont.com>
List: current-users
Date: 02/05/1999 14:18:18
*******************************************************************
*******************************************************************
SUMMARY: After tonight's sup, IF YOU WANT YOUR SENDMAIL SETUP TO
CONTINUE FUNCTIONING, you will have to copy src/etc/mailer.conf to
/etc or sendmail will stop working for you!!!!
*******************************************************************
*******************************************************************
[If you rebuild without doing a "make build", please make sure you run
mtree to build the new libexec/sendmail subdirectory, or your build
will fail.]
LONG FORM: Some long brewing changes to permit alternative mailers to
be used in place of sendmail are going to be in the tree after
tonight. The actual sendmail program is being moved to
/usr/libexec/sendmail/sendmail, and /usr/sbin/sendmail is now going to
be a link to "mailwrapper", a program which will let you actually
execute the original sendmail, postfix's "sendmail" replacement,
Zmailer's "sendmail" replacement, or whatever other program named
sendmail you like. This will mean we can have multiple mail transport
agent programs in the tree and in pkgsrc that do not step on each
other. (Note that technically, this program wraps not only sendmail
but mailq and newaliases as well.)
The "mailwrapper" program needs an /etc/mailer.conf file to know what
it is supposed to execute. Without it, it gets unhappy. See the man
page for details -- the syntax is extremely simple.
Why not have mailwrapper do the right thing when mailer.conf is absent,
you ask? Why not have it automatically execute
/usr/libexec/sendmail/sendmail if the file isn't there? Why put people
through this pain? I'll explain.
I debated having the program automatically execute the "real" sendmail
when the /etc/mailer.conf file was absent, but I realized that this
might cause extremely painful silent mail loss on hosts where the file
got accidently blown away. Users get very mad when mail is lost. It is
better to have a noisy failure than a silent one in this case so that
users will not lose mail, and so I decided against having the
automatic behavior. This way, people will know something is wrong
immediately.
Perry