1.\" $NetBSD: mailwrapper.8,v 1.11 2002/02/08 01:38:50 ross Exp $ 2.\" $OpenBSD: mailwrapper.8,v 1.8 2003/06/12 12:59:51 jmc Exp $ 3.\" $FreeBSD$ 4.\" 5.\" Copyright (c) 1998 6.\" Perry E. Metzger. All rights reserved. 7.\" 8.\" Redistribution and use in source and binary forms, with or without 9.\" modification, are permitted provided that the following conditions 10.\" are met: 11.\" 1. Redistributions of source code must retain the above copyright 12.\" notice, this list of conditions and the following disclaimer. 13.\" 2. Redistributions in binary form must reproduce the above copyright 14.\" notice, this list of conditions and the following disclaimer in the 15.\" documentation and/or other materials provided with the distribution. 16.\" 3. All advertising materials mentioning features or use of this software 17.\" must display the following acknowledgment: 18.\" This product includes software developed for the NetBSD Project 19.\" by Perry E. Metzger. 20.\" 4. The name of the author may not be used to endorse or promote products 21.\" derived from this software without specific prior written permission. 22.\" 23.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR 24.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES 25.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 26.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, 27.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 28.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 29.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 30.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 31.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 32.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 33.\" 34.\" The following requests are required for all man pages. 35.Dd August 7, 2006 36.Dt MAILWRAPPER 8 37.Os 38.Sh NAME 39.Nm mailwrapper 40.Nd invoke appropriate MTA software based on configuration file 41.Sh SYNOPSIS 42Special. 43See below. 44.Sh DESCRIPTION 45At one time, the only Mail Transfer Agent (MTA) software easily available 46was 47.Xr sendmail 8 . 48As a result of this, most Mail User Agents (MUAs) such as 49.Xr mail 1 50had the path and calling conventions expected by 51.Xr sendmail 8 52compiled in. 53.Pp 54Times have changed, however. 55On a modern 56.Ux 57system, the administrator may wish to use one of several 58available MTAs. 59.Pp 60It would be difficult to modify all MUA software typically available 61on a system, so most of the authors of alternative MTAs have written 62their front end message submission programs so that they use the same 63calling conventions as 64.Xr sendmail 8 65and may be put into place instead of 66.Xr sendmail 8 67in 68.Pa /usr/sbin/sendmail . 69.Pp 70.Xr sendmail 8 71also typically has aliases named 72.Xr mailq 1 73and 74.Xr newaliases 1 75linked to it. 76The program knows to behave differently when its 77.Va argv[0] 78is 79.Dq mailq 80or 81.Dq newaliases 82and behaves appropriately. 83Typically, replacement MTAs provide similar 84functionality, either through a program that also switches behavior 85based on calling name, or through a set of programs that provide 86similar functionality. 87.Pp 88Although having drop-in replacements for 89.Xr sendmail 8 90helps in installing alternative MTAs, it essentially makes the 91configuration of the system depend on hand installing new programs in 92.Pa /usr . 93This leads to configuration problems for many administrators, since 94they may wish to install a new MTA without altering the system 95provided 96.Pa /usr . 97(This may be, for example, to avoid having upgrade problems when a new 98version of the system is installed over the old.) 99They may also have a shared 100.Pa /usr 101among several 102machines, and may wish to avoid placing implicit configuration 103information in a read-only 104.Pa /usr . 105.Pp 106The 107.Nm 108utility is designed to replace 109.Pa /usr/sbin/sendmail 110and to invoke an appropriate MTA instead of 111.Xr sendmail 8 112based on configuration information placed in 113.Pa /etc/mail/mailer.conf . 114This permits the administrator to configure which MTA is to be invoked on 115the system at run time. 116.Pp 117Other configuration files may need to be altered when replacing 118.Xr sendmail 8 . 119For example, if the replacement MTA does not support the 120.Fl A 121option with 122.Xr mailq 1 , 123.Va daily_status_include_submit_mailq 124should be turned off in 125.Pa /etc/periodic.conf . 126.Sh FILES 127Configuration for 128.Nm 129is kept in 130.Pa /etc/mail/mailer.conf . 131.Pa /usr/sbin/sendmail 132is typically set up as a symbolic link to 133.Nm 134which is not usually invoked on its own. 135.Sh EXIT STATUS 136.Ex -std 137.Sh DIAGNOSTICS 138The 139.Nm 140will print a diagnostic if its configuration file is missing or malformed, 141or does not contain a mapping for the name under which it was invoked. 142.Sh SEE ALSO 143.Xr mail 1 , 144.Xr mailq 1 , 145.Xr newaliases 1 , 146.Xr mailer.conf 5 , 147.Xr periodic.conf 5 , 148.Xr sendmail 8 149.Sh HISTORY 150The 151.Nm 152utility first appeared in 153.Nx 1.4 154and then 155.Fx 4.0 . 156.Sh AUTHORS 157.An Perry E. Metzger Aq perry@piermont.com 158.Sh BUGS 159The entire reason this program exists is a crock. 160Instead, a command 161for how to submit mail should be standardized, and all the "behave 162differently if invoked with a different name" behavior of things like 163.Xr mailq 1 164should go away. 165