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