1.\" $OpenBSD: mailwrapper.8,v 1.10 2009/02/07 16:58:23 martynas Exp $ 2.\" $NetBSD: mailwrapper.8,v 1.11 2002/02/08 01:38:50 ross 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.Dd August 27, 2014 35.Dt MAILWRAPPER 8 36.Os 37.Sh NAME 38.Nm mailwrapper 39.Nd invoke appropriate MTA software based on configuration file 40.Sh SYNOPSIS 41Special. 42See below. 43.Sh DESCRIPTION 44At one time, the only Mail Transfer Agent (MTA) software easily available 45was 46.Xr sendmail 8 . 47As a result of this, most Mail User Agents (MUAs) such as 48.Xr mail 1 49had the path and calling conventions expected by 50.Xr sendmail 8 51compiled in. 52.Pp 53Times have changed, however. 54On a modern 55.Ux 56system, the administrator may wish to use one of several 57available MTAs. 58.Pp 59It would be difficult to modify all MUA software typically available 60on a system, so most of the authors of alternative MTAs have written 61their front end message submission programs so that they use the same 62calling conventions as 63.Xr sendmail 8 64and may be put into place instead of 65.Xr sendmail 8 66in 67.Pa /usr/sbin/sendmail . 68.Pp 69.Xr sendmail 8 70also typically has aliases named 71.Xr mailq 1 72and 73.Xr newaliases 1 74linked to it. 75The program knows to behave differently when its 76.Va argv[0] 77is 78.Dq mailq 79or 80.Dq newaliases 81and behaves appropriately. 82Typically, replacement MTAs provide similar 83functionality, either through a program that also switches behavior 84based on calling name, or through a set of programs that provide 85similar functionality. 86.Pp 87Although having drop-in replacements for 88.Xr sendmail 8 89helps in installing alternative MTAs, it essentially makes the 90configuration of the system depend on hand installing new programs in 91.Pa /usr . 92This leads to configuration problems for many administrators, since 93they may wish to install a new MTA without altering the system 94provided 95.Pa /usr . 96(This may be, for example, to avoid having upgrade problems when a new 97version of the system is installed over the old.) 98They may also have a shared 99.Pa /usr 100among several 101machines, and may wish to avoid placing implicit configuration 102information in a read-only 103.Pa /usr . 104.Pp 105The 106.Nm 107utility is designed to replace 108.Pa /usr/sbin/sendmail 109and to invoke an appropriate MTA instead of 110.Xr sendmail 8 111based on configuration information placed in 112.Pa ${LOCALBASE}/etc/mail/mailer.conf 113falling back on 114.Pa /etc/mail/mailer.conf . 115This permits the administrator to configure which MTA is to be invoked on 116the system at run time. 117.Pp 118Other configuration files may need to be altered when replacing 119.Xr sendmail 8 . 120For example, if the replacement MTA does not support the 121.Fl A 122option with 123.Xr mailq 1 , 124.Va daily_status_include_submit_mailq 125should be turned off in 126.Pa /etc/periodic.conf . 127.Sh FILES 128Configuration for 129.Nm 130is kept in 131.Pa ${LOCALBASE}/etc/mail/mailer.conf 132or 133.Pa /etc/mail/mailer.conf . 134.Pa /usr/sbin/sendmail 135is typically set up as a symbolic link to 136.Nm 137which is not usually invoked on its own. 138.Sh EXIT STATUS 139.Ex -std 140.Sh DIAGNOSTICS 141The 142.Nm 143will print a diagnostic if its configuration file is missing or malformed, 144or does not contain a mapping for the name under which it was invoked. 145.Sh SEE ALSO 146.Xr mail 1 , 147.Xr mailq 1 , 148.Xr newaliases 1 , 149.Xr mailer.conf 5 , 150.Xr periodic.conf 5 , 151.Xr sendmail 8 152.Sh HISTORY 153The 154.Nm 155utility first appeared in 156.Nx 1.4 157and then 158.Fx 4.0 . 159.Sh AUTHORS 160.An Perry E. Metzger Aq Mt perry@piermont.com 161.Sh BUGS 162The entire reason this program exists is a crock. 163Instead, a command 164for how to submit mail should be standardized, and all the "behave 165differently if invoked with a different name" behavior of things like 166.Xr mailq 1 167should go away. 168