xref: /csrg-svn/usr.sbin/sendmail/FAQ (revision 67489)
166282Seric			    Sendmail Version 8
266282Seric			Frequently Asked Questions
3*67489Seric		         Version 8.5 of 07/04/94
466282Seric
566282Seric
667021SericThis FAQ is specific to Version 8 of sendmail.  Other questions,
767021Sericparticularly regarding compilation and configuration, are answered
867021Sericin src/READ_ME and cf/README.
966282Seric
1066282Seric----------------------------------------------------------------------
1167021Seric  * Where can I get Version 8?
1267021Seric
1367021Seric	Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail.
1467021Seric----------------------------------------------------------------------
1566282Seric  * What are the differences between Version 8 and other versions?
1666282Seric
1767021Seric	See doc/changes/changes.me in the sendmail distribution.
1866282Seric----------------------------------------------------------------------
1966282Seric  * What happened to sendmail 6.x and 7.x?
2066282Seric
2166282Seric	When I released a new version of sendmail, I changed it to
2266282Seric	Release 6.  Development continued in that tree until 4.4BSD
2366282Seric	was released, when everything on the 4.4 tape was set to be
2466282Seric	version 8.1.  Version 7.x never existed.
2566282Seric----------------------------------------------------------------------
2666282Seric  * Version 8 requires a new version of "make".  Where can I get this?
2766282Seric
2866282Seric	Actually, Version 8 does not require a new version of "make".
2966282Seric	It includes a collection of Makefiles for different architectures,
3066282Seric	only one or two of which require the new "make".  If you are
3166282Seric	porting to a new architecture, start with Makefile.dist.
3266282Seric
3366282Seric	If you really do want the new make, it is available on any of
3467021Seric	the BSD Net2 or 4.4-Lite distribution sites.  These include:
3566282Seric
3666282Seric		ftp.uu.net		/systems/unix/bsd-sources
3766282Seric		gatekeeper.dec.com	/.0/BSD/net2
3866282Seric		ucquais.cba.uc.edu	/pub/net2
3966282Seric		ftp.luth.se		/pub/unix/4.3bsd/net2
4066282Seric
4166282Seric	Diffs and instructions for building this version of make under
4266282Seric	SunOS 4.1.x are available on ftp.css.itd.umich.edu in
4366282Seric	/pub/systems/sun/Net2-make.sun4.diff.Z.
44*67489Seric
45*67489Seric	There is also a Linux version available on the main Linux
46*67489Seric	distribution sites as pmake; this version is included as
47*67489Seric	standard with the current Slackware distributions.
4866282Seric----------------------------------------------------------------------
4966282Seric  * What macro package do I use to format the V8 man pages?
5066282Seric
5166282Seric	The BSD group switched over the the ``mandoc'' macros for
5266282Seric	the 4.4 release.  These include more hooks designed for
5366282Seric	hypertext handling.  However, new man pages won't format
5466282Seric	under the old man macros.  Fortunately, old man pages will
5566282Seric	format under the new mandoc macros.
5666282Seric
5767021Seric	Get the new macros with the BSD Net2 or 4.4-Lite release.
5866282Seric
5966282Seric	This macro set is also available with newer versions of groff.
6066282Seric----------------------------------------------------------------------
6166282Seric  * What books are available describing sendmail?
6266282Seric
6367021Seric	There is one book available devoted to sendmail:
6466282Seric
6567021Seric	    Costales, Allman, and Rickert, _Sendmail_.  O'Reilly &
6667021Seric		Associates.
6767021Seric
6867021Seric	Several books have sendmail chapters, for example:
6967021Seric
7067021Seric	    Nemeth, Snyder, and Seebass, _Unix System Administration
7166282Seric		Handbook_.  Prentice-Hall.
7267021Seric	    Carl-Mitchell and Quarterman, _Practical Internetworking with
7366282Seric		TCP/IP and UNIX_.  Addison-Wesley.
7467021Seric	    Hunt, _TCP/IP Network Administration_.  O'Reilly & Associates.
7566282Seric
7667021Seric	Another book about sendmail is due out "soon":
7766282Seric
7867021Seric	    Avolio & Vixie, _Sendmail Theory and Practice_.  Digital
7966282Seric		Press (release date unknown).
8066282Seric----------------------------------------------------------------------
8166282Seric  * How do I make all my addresses appear to be from a single host?
8266282Seric
8366282Seric	Using the V8 configuration macros, use:
8466282Seric
8566282Seric		MASQUERADE_AS(my.dom.ain)
8666282Seric
8766282Seric	This will cause all addresses to be sent out as being from
8866282Seric	the indicated domain.
8966282Seric----------------------------------------------------------------------
9066282Seric  * How do I rewrite my From: lines to read ``First_Last@My.Domain''?
9166282Seric
9266282Seric	There are a couple of ways of doing this.  This describes using
9366282Seric	the "user database" code.  This is still experimental, and was
9466282Seric	intended for a different purpose -- however, it does work
9566282Seric	with a bit of care.  It does require that you have the Berkeley
9666282Seric	"db" package installed (it won't work with DBM).
9766282Seric
9866282Seric	First, create your input file.  This should have lines like:
9966282Seric
10066282Seric		loginname:mailname	First_Last
10166282Seric		First_Last:maildrop	loginname
10266282Seric
10366282Seric	Install it in (say) /etc/userdb.  Create the database:
10466282Seric
10566282Seric		makemap btree /etc/userdb.db < /etc/userdb
10666282Seric
10766282Seric	You can then create a config file that uses this.  You will
10866282Seric	have to include the following in your .mc file:
10966282Seric
11066282Seric		define(confUSERDB_SPEC, /etc/userdb.db)
11166282Seric		FEATURE(notsticky)
11266282Seric----------------------------------------------------------------------
11366282Seric  * So what was the user database feature intended for?
11466282Seric
11566282Seric	The intent was to have all information for a given user (where
11666282Seric	the user is the unique login name, not an inherently non-unique
11766282Seric	full name) in one place.  This would include phone numbers,
11866282Seric	addresses, and so forth.  The "maildrop" feature is because
11966282Seric	Berkeley does not use a centralized mail server (there are a
12066282Seric	number of reasons for this that are mostly historic), and so
12166282Seric	we need to know where each user gets his or her mail delivered --
12266282Seric	i.e., the mail drop.
12366282Seric
12466282Seric	We are in the process of setting up our environment so that
12566282Seric	mail sent to an unqualified "name" goes to that person's
12666282Seric	preferred maildrop; mail sent to "name@host" goes to that
12766282Seric	host.  The purpose of "FEATURE(notsticky)" is to cause
12866282Seric	"name@host" to be looked up in the user database for delivery
12966282Seric	to the maildrop.
13066282Seric----------------------------------------------------------------------
13166282Seric  * Why are you so hostile to using full names for e-mail addresses?
13266282Seric
13366282Seric	Because full names are not unique.  For example, the computer
13466282Seric	community has two Andy Tannenbaums and two Peter Deutsches.
13566282Seric	At one time, Bell Labs had two Stephen R. Bournes with offices
13666282Seric	a few doors apart.  You can create alternative addresses
13766282Seric	(e.g., Stephen_R_Bourne_2), but that's even worse -- which
13866282Seric	one of them has to have their name desecrated in this way?
13966282Seric	And you can bet that they will get most of the other person's
14066282Seric	email.
14166282Seric
14266282Seric	So called "full names" are just longer versions of unique
14366282Seric	names.  Rather that lulling people into a sense of security,
14466282Seric	I'd rather that it be clear that these handles are arbitrary.
14566282Seric	People should use good user agents that have alias mappings
14666282Seric	so that they can attach arbitrary names for their personal
14766282Seric	use to those with whom they correspond.
14866282Seric
14966282Seric	Even worse is fuzzy matching in e-mail -- this can make good
15066282Seric	addresses turn bad.  For example, I'm currently (to the best
15166282Seric	of my knowledge) the only ``Allman'' at Berkeley, so mail
15266282Seric	sent to "Allman@Berkeley.EDU" should get to me.  But if
15366282Seric	another Allman ever appears, this address could suddenly
15466282Seric	become ambiguous.  I've been the only Allman at Berkeley for
15566282Seric	over fifteen years -- to suddenly have this "good address"
15666282Seric	bounce mail because it is ambiguous would be a heinous wrong.
15766282Seric
15866282Seric	Finger services should be as fuzzy as possible.  Mail services
15966282Seric	should be unique.
16066282Seric----------------------------------------------------------------------
16166282Seric  * When I use sendmail V8 with a Sun config file I get lines like:
16266282Seric
16366282Seric	/etc/sendmail.cf: line 273: replacement $3 out of bounds
16466282Seric
16566282Seric    the line in question reads:
16666282Seric
16766282Seric	R$*<@$%y>$*		$1<@$2.LOCAL>$3			user@ether
16866282Seric
16966282Seric    what does this mean?  How do I fix it?
17066282Seric
17166282Seric	V8 doesn't recognize the Sun "$%y" syntax, so as far as it
17266282Seric	is concerned, there is only a $1 and a $2 (but no $3) in this
17366282Seric	line.  Read Rick McCarty's paper on "Converting Standard Sun
17466282Seric	Config Files to Sendmail Version 8", in the contrib directory
17566282Seric	(file "converting.sun.configs") on the sendmail distribution
17666282Seric	for a full discussion of how to do this.
17766282Seric----------------------------------------------------------------------
17866282Seric  * Should I use a wildcard MX for my domain?
17966282Seric
18066282Seric	If at all possible, no.
18166282Seric
18266282Seric	Wildcard MX records have lots of semantic "gotcha"s.  For
18366282Seric	example, they will match a host "unknown.your.domain" -- if
18466282Seric	you don't explicitly test for unknown hosts in your domain,
18566282Seric	you will get "config error: mail loops back to myself"
18666282Seric	errors.
18766282Seric----------------------------------------------------------------------
18866282Seric  * I'm connected to the network via a SLIP link.  Sometimes my sendmail
18966282Seric    process hangs (although it looks like part of the message has been
19066282Seric    transfered).  Everything else works.  What's wrong?
19166282Seric
19266282Seric	Most likely, the problem isn't sendmail at all, but the low
19366282Seric	level network connection.  It's important that the MTU (Maximum
19466282Seric	Transfer Unit) for the SLIP connection be set properly at both
19566282Seric	ends.  If they disagree, large packets will be trashed and
19666282Seric	the connection will hang.
19766282Seric----------------------------------------------------------------------
19866282Seric  * I just upgraded to 8.x and suddenly I'm getting messages in my
19966282Seric    syslog of the form "collect: I/O error on connection".  What is
20066282Seric    going wrong?
20166282Seric
20266282Seric    	Nothing.  This is just a diagnosis of a condition that had
20366282Seric    	not been diagnosed before.  If you are getting a lot of these
20466282Seric    	from a single host, there is probably some incompatibility
20566282Seric    	between 8.x and that host.  If you get a lot of them in general,
20666282Seric    	you may have network problems that are causing connections to
20766282Seric    	get reset.
20866282Seric----------------------------------------------------------------------
20966282Seric  * How can I get sendmail to deliver local mail to $HOME/.mail
21066282Seric    instead of into /usr/spool/mail (or /usr/mail)?
21166282Seric
21266282Seric	This is a local mailer issue, not a sendmail issue.  Either
21366282Seric	modify your local mailer (source code will be required) or
21466282Seric	change the program called in the "local" mailer configuration
21566282Seric	description to be a new program that does this local delivery.
21666282Seric	I understand that "procmail" works well, although I haven't
21766282Seric	used it myself.
21866786Seric
21966786Seric	You might be interested in reading the paper ``HLFSD: Delivering
22066786Seric	Email to your $HOME'' available in the Proceedings of the
22166786Seric	USENIX System Administration (LISA VII) Conference (November
22266786Seric	1993).  This is also available via public FTP from
22366786Seric	ftp.cs.columbia.edu:/pub/hlfsd/{README.hlfsd,hlfsd.ps}.
22466282Seric----------------------------------------------------------------------
22566282Seric  * Under V8, the "From " header gets mysteriously munged when I send
22666282Seric    to an alias.
22766282Seric
22866282Seric	``It's not a bug, it's a feature.''  This happens when you have
22966282Seric	a "owner-list" alias and you send to "list".  V8 propogates the
23066282Seric	owner information into the envelope sender field (which appears
23166282Seric	as the "From " header on UNIX mail or as the Return-Path: header)
23266282Seric	so that downstream errors are properly returned to the mailing
23366282Seric	list owner instead of to the sender.  In order to make this
23466282Seric	appear as sensible as possible to end users, I recommend making
23566282Seric	the owner point to a "request" address -- for example:
23666282Seric
23766282Seric		list:		:include:/path/name/list.list
23866282Seric		owner-list:	list-request
23966282Seric		list-request:	eric
24066282Seric
24166282Seric	This will make message sent to "list" come out as being
24266282Seric	"From list-request" instead of "From eric".
24366282Seric----------------------------------------------------------------------
24466282Seric  * There are four UUCP mailers listed in the configuration files.
24566282Seric    Which one should I use?
24666282Seric
24766282Seric	The choice is partly a matter of local preferences and what is
24866282Seric	running at the other end of your UUCP connection.  Unlike good
24966282Seric	protocols that define what will go over the wire, UUCP uses
25066282Seric	the policy that you should do what is right for the other end;
25166282Seric	if they change, you have to change.  This makes it hard to
25266282Seric	do the right thing, and discourages people from updating their
25366282Seric	software.  In general, if you can avoid UUCP, please do.
25466282Seric
25566282Seric	If you can't avoid it, you'll have to find the version that is
25666282Seric	closest to what the other end accepts.  Following is a summary
25766282Seric	of the UUCP mailers available.
25866282Seric
25966282Seric	uucp-old (obsolete name: "uucp")
26066282Seric	  This is the oldest, the worst (but the closest to UUCP) way of
26166282Seric	  sending messages accros UUCP connections.  It does bangify
26266282Seric	  everything and prepends $U (your UUCP name) to the sender's
26366282Seric	  address (which can already be a bang path itself).  It can
26466282Seric	  only send to one address at a time, so it spends a lot of
26566282Seric	  time copying duplicates of messages.  Avoid this if at all
26666282Seric	  possible.
26766282Seric
26866282Seric	uucp-new (obsolete name: "suucp")
26966282Seric	  The same as above, except that it assumes that in one rmail
27066282Seric	  command you can specify several recipients.  It still has a
27166282Seric	  lot of other problems.
27266282Seric
27366282Seric	uucp-dom
27466282Seric	  This UUCP mailer keeps everything as domain addresses.
27566282Seric	  Basically, it uses the SMTP mailer rewriting rules.
27666282Seric
27766282Seric	  Unfortunately, a lot of UUCP mailer transport agents require
27866282Seric	  bangified addresses in the envelope, although you can use
27966282Seric	  domain-based addresses in the message header.  (The envelope
28066282Seric	  shows up as the From_ line on UNIX mail.)  So....
28166282Seric
28266282Seric	uucp-uudom
28366282Seric	  This is a cross between uucp-new (for the envelope addresses)
28466282Seric	  and uucp-dom (for the header addresses).  It bangifies the
28566282Seric	  envelope sender (From_ line in messages) without adding the
28666282Seric	  local hostname, unless there is no host name on the address
28766282Seric	  at all (e.g., "wolf") or the host component is a UUCP host name
28866282Seric	  instead of a domain name ("somehost!wolf" instead of
28966282Seric	  "some.dom.ain!wolf").
29066282Seric
29166282Seric	Examples:
29266282Seric
29366282Seric	We are on host grasp.insa-lyon.fr (UUCP host name "grasp").  The
29466282Seric	following summarizes the sender rewriting for various mailers.
29566282Seric
29666282Seric	Mailer          sender		rewriting in the envelope
29766282Seric	------		------		-------------------------
29866282Seric	uucp-{old,new}	wolf		grasp!wolf
29966282Seric	uucp-dom	wolf		wolf@grasp.insa-lyon.fr
30066282Seric	uucp-uudom	wolf		grasp.insa-lyon.fr!wolf
30166282Seric
30266282Seric	uucp-{old,new}	wolf@fr.net	grasp!fr.net!wolf
30366282Seric	uucp-dom	wolf@fr.net	wolf@fr.net
30466282Seric	uucp-uudom	wolf@fr.net	fr.net!wolf
30566282Seric
30666282Seric	uucp-{old,new}	somehost!wolf	grasp!somehost!wolf
30766282Seric	uucp-dom	somehost!wolf	somehost!wolf@grasp.insa-lyon.fr
30866282Seric	uucp-uudom	somehost!wolf	grasp.insa-lyon.fr!somehost!wolf
30966282Seric----------------------------------------------------------------------
31066282Seric  * I'm trying to to get my mail to go into queue only mode, and it
31166282Seric    delivers the mail interactively anyway.  (Or, I'm trying to use
31266282Seric    the "don't deliver to expensive mailer" flag, and it doesn't
31366282Seric    delivers the mail interactively anyway.)  I can see it does it:
31466282Seric    here's the output of "sendmail -v foo@somehost" (or Mail -v or
31566282Seric    equivalent).
31666282Seric
31766282Seric	The -v flag to sendmail (which is implied by the -v flag to
31866282Seric	Mail and other programs in that family) tells sendmail to
31966282Seric	watch the transaction.  Since you have explicitly asked to
32066282Seric	see what's going on, it assumes that you do not want to to
32166282Seric	auto-queue, and turns that feature off.  Remove the -v flag
32266282Seric	and use a "tail -f" of the log instead to see what's going on.
32366282Seric
32466282Seric	If you are trying to use the "don't deliver to expensive mailer"
32566282Seric	flag (mailer flag "e"), be sure you also turn on global option
32666282Seric	"c" -- otherwise it ignores the mailer flag.
32766282Seric----------------------------------------------------------------------
32866285Seric  * I'm getting "Local configuration error" messages, such as:
32966285Seric
33066285Seric	553 relay.domain.net config error: mail loops back to myself
33166285Seric	554 <user@domain.net>... Local configuration error
33266285Seric
33366285Seric    How can I solve this problem?
33466285Seric
33566285Seric	You have asked mail to the domain (e.g., domain.net) to be
33666285Seric	forwarded to a specific host (in this case, relay.domain.net)
33766285Seric	by using an MX record, but the relay machine doesn't recognize
33866285Seric	itself as domain.net.  Add domain.net to /etc/sendmail.cw
33966285Seric	(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
34066285Seric	to your configuration file.
34166282Seric----------------------------------------------------------------------
34266285Seric  * I want to run Sendmail version 8 on my DEC system, but you don't
34366285Seric    have MAIL11V3 support in sendmail.  How do I handle this?
34466285Seric
34566285Seric	Get Paul Vixie's reimplementation of the mail11 protocol
34666285Seric	from gatekeeper.dec.com in /pub/DEC/gwtools.
34766285Seric----------------------------------------------------------------------
348