xref: /csrg-svn/usr.sbin/sendmail/FAQ (revision 67898)
166282Seric			    Sendmail Version 8
266282Seric			Frequently Asked Questions
3*67898Seric		         Version 8.8 of 11/10/94
466282Seric
566282Seric
667021SericThis FAQ is specific to Version 8 of sendmail.  Other questions,
767021Sericparticularly regarding compilation and configuration, are answered
867892Sericin src/READ_ME and cf/README (found in the V8 sendmail distribution).
966282Seric
1066282Seric----------------------------------------------------------------------
1167892Seric  * What do you wish everyone would do before sending you mail?
1267892Seric
1367892Seric	Read this FAQ completely.  Read src/READ_ME and cf/README
1467892Seric	completely.  Ask themselves if their question hasn't already
1567892Seric	been answered.
1667892Seric----------------------------------------------------------------------
1767021Seric  * Where can I get Version 8?
1867021Seric
1967021Seric	Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail.
2067021Seric----------------------------------------------------------------------
2166282Seric  * What are the differences between Version 8 and other versions?
2266282Seric
2367021Seric	See doc/changes/changes.me in the sendmail distribution.
2466282Seric----------------------------------------------------------------------
2566282Seric  * What happened to sendmail 6.x and 7.x?
2666282Seric
2767892Seric	When I released a new (Alpha/Beta) version of sendmail, I changed
2867892Seric	it to Release 6.  Development continued in that tree until 4.4BSD
2966282Seric	was released, when everything on the 4.4 tape was set to be
3066282Seric	version 8.1.  Version 7.x never existed.
3166282Seric----------------------------------------------------------------------
3266282Seric  * Version 8 requires a new version of "make".  Where can I get this?
3366282Seric
3466282Seric	Actually, Version 8 does not require a new version of "make".
3566282Seric	It includes a collection of Makefiles for different architectures,
3667892Seric	only one or two of which require the new "make".  For a supported
3767892Seric	architecture, use ``sh makesendmail''.  If you are porting to a
3867892Seric	new architecture, start with Makefile.dist.
3966282Seric
4066282Seric	If you really do want the new make, it is available on any of
4167021Seric	the BSD Net2 or 4.4-Lite distribution sites.  These include:
4266282Seric
4366282Seric		ftp.uu.net		/systems/unix/bsd-sources
4466282Seric		gatekeeper.dec.com	/.0/BSD/net2
4566282Seric		ucquais.cba.uc.edu	/pub/net2
4666282Seric		ftp.luth.se		/pub/unix/4.3bsd/net2
4766282Seric
4866282Seric	Diffs and instructions for building this version of make under
4966282Seric	SunOS 4.1.x are available on ftp.css.itd.umich.edu in
5067556Seric	/pub/systems/sun/Net2-make.sun4.diff.Z.  A patchkit for Ultrix
5167556Seric 	is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z.  Patches
5267556Seric	for AIX 3.2.4 are available on ftp.uni-stuttgart.de in
5367556Seric	/sw/src/patches/bsd-make-rus-patches.
5467489Seric
5567489Seric	There is also a Linux version available on the main Linux
5667489Seric	distribution sites as pmake; this version is included as
5767489Seric	standard with the current Slackware distributions.
5866282Seric----------------------------------------------------------------------
5966282Seric  * What macro package do I use to format the V8 man pages?
6066282Seric
6166282Seric	The BSD group switched over the the ``mandoc'' macros for
6266282Seric	the 4.4 release.  These include more hooks designed for
6366282Seric	hypertext handling.  However, new man pages won't format
6466282Seric	under the old man macros.  Fortunately, old man pages will
6566282Seric	format under the new mandoc macros.
6666282Seric
6767892Seric	Get the new macros with the BSD Net2 or 4.4-Lite release
6867892Seric	(see above).
6966282Seric
7066282Seric	This macro set is also available with newer versions of groff.
7166282Seric----------------------------------------------------------------------
7266282Seric  * What books are available describing sendmail?
7366282Seric
7467021Seric	There is one book available devoted to sendmail:
7566282Seric
7667021Seric	    Costales, Allman, and Rickert, _Sendmail_.  O'Reilly &
7767021Seric		Associates.
7867021Seric
7967021Seric	Several books have sendmail chapters, for example:
8067021Seric
8167021Seric	    Nemeth, Snyder, and Seebass, _Unix System Administration
8266282Seric		Handbook_.  Prentice-Hall.
8367021Seric	    Carl-Mitchell and Quarterman, _Practical Internetworking with
8466282Seric		TCP/IP and UNIX_.  Addison-Wesley.
8567021Seric	    Hunt, _TCP/IP Network Administration_.  O'Reilly & Associates.
8666282Seric
8767021Seric	Another book about sendmail is due out "soon":
8866282Seric
8967021Seric	    Avolio & Vixie, _Sendmail Theory and Practice_.  Digital
9066282Seric		Press (release date unknown).
9166282Seric----------------------------------------------------------------------
9266282Seric  * How do I make all my addresses appear to be from a single host?
9366282Seric
9466282Seric	Using the V8 configuration macros, use:
9566282Seric
9666282Seric		MASQUERADE_AS(my.dom.ain)
9766282Seric
9866282Seric	This will cause all addresses to be sent out as being from
9966282Seric	the indicated domain.
10066282Seric----------------------------------------------------------------------
10166282Seric  * How do I rewrite my From: lines to read ``First_Last@My.Domain''?
10266282Seric
10366282Seric	There are a couple of ways of doing this.  This describes using
10466282Seric	the "user database" code.  This is still experimental, and was
10566282Seric	intended for a different purpose -- however, it does work
10666282Seric	with a bit of care.  It does require that you have the Berkeley
10766282Seric	"db" package installed (it won't work with DBM).
10866282Seric
10966282Seric	First, create your input file.  This should have lines like:
11066282Seric
11166282Seric		loginname:mailname	First_Last
11266282Seric		First_Last:maildrop	loginname
11366282Seric
11466282Seric	Install it in (say) /etc/userdb.  Create the database:
11566282Seric
11666282Seric		makemap btree /etc/userdb.db < /etc/userdb
11766282Seric
11866282Seric	You can then create a config file that uses this.  You will
11966282Seric	have to include the following in your .mc file:
12066282Seric
12166282Seric		define(confUSERDB_SPEC, /etc/userdb.db)
12266282Seric		FEATURE(notsticky)
12366282Seric----------------------------------------------------------------------
12466282Seric  * So what was the user database feature intended for?
12566282Seric
12666282Seric	The intent was to have all information for a given user (where
12766282Seric	the user is the unique login name, not an inherently non-unique
12866282Seric	full name) in one place.  This would include phone numbers,
12966282Seric	addresses, and so forth.  The "maildrop" feature is because
13066282Seric	Berkeley does not use a centralized mail server (there are a
13166282Seric	number of reasons for this that are mostly historic), and so
13266282Seric	we need to know where each user gets his or her mail delivered --
13366282Seric	i.e., the mail drop.
13466282Seric
13566282Seric	We are in the process of setting up our environment so that
13666282Seric	mail sent to an unqualified "name" goes to that person's
13766282Seric	preferred maildrop; mail sent to "name@host" goes to that
13866282Seric	host.  The purpose of "FEATURE(notsticky)" is to cause
13966282Seric	"name@host" to be looked up in the user database for delivery
14066282Seric	to the maildrop.
14166282Seric----------------------------------------------------------------------
14266282Seric  * Why are you so hostile to using full names for e-mail addresses?
14366282Seric
14466282Seric	Because full names are not unique.  For example, the computer
14566282Seric	community has two Andy Tannenbaums and two Peter Deutsches.
14666282Seric	At one time, Bell Labs had two Stephen R. Bournes with offices
14766282Seric	a few doors apart.  You can create alternative addresses
14866282Seric	(e.g., Stephen_R_Bourne_2), but that's even worse -- which
14966282Seric	one of them has to have their name desecrated in this way?
15067892Seric	And you can bet that one of them will get most of the other
15167892Seric	person's e-mail.
15266282Seric
15367892Seric	So called "full names" are just an attempt to create longer
15467892Seric	versions of unique names.  Rather that lulling people into a
15567892Seric	sense of security, I'd rather that it be clear that these
15667892Seric	handles are arbitrary.  People should use good user agents
15767892Seric	that have alias mappings so that they can attach arbitrary
15867892Seric	names for their personal use to those with whom they correspond
15967892Seric	(such as the MH alias file).
16066282Seric
16166282Seric	Even worse is fuzzy matching in e-mail -- this can make good
16266282Seric	addresses turn bad.  For example, I'm currently (to the best
16366282Seric	of my knowledge) the only ``Allman'' at Berkeley, so mail
16466282Seric	sent to "Allman@Berkeley.EDU" should get to me.  But if
16566282Seric	another Allman ever appears, this address could suddenly
16666282Seric	become ambiguous.  I've been the only Allman at Berkeley for
16766282Seric	over fifteen years -- to suddenly have this "good address"
16866282Seric	bounce mail because it is ambiguous would be a heinous wrong.
16966282Seric
17067892Seric	Finger services should be as fuzzy as possible (within
17167892Seric	reason, of course).  Mail services should be unique.
17266282Seric----------------------------------------------------------------------
17367892Seric  * I'm getting "Local configuration error" messages, such as:
17467892Seric
17567892Seric	553 relay.domain.net config error: mail loops back to myself
17667892Seric	554 <user@domain.net>... Local configuration error
17767892Seric
17867892Seric    How can I solve this problem?
17967892Seric
18067892Seric	You have asked mail to the domain (e.g., domain.net) to be
18167892Seric	forwarded to a specific host (in this case, relay.domain.net)
18267892Seric	by using an MX record, but the relay machine doesn't recognize
18367892Seric	itself as domain.net.  Add domain.net to /etc/sendmail.cw
18467892Seric	(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
18567892Seric	to your configuration file.
186*67898Seric
187*67898Seric	IMPORTANT:  Be sure you kill and restart the sendmail daemon
188*67898Seric	after you change the configuration file (for ANY change in
189*67898Seric	the configuration, not just this one):
190*67898Seric
191*67898Seric		kill `head -1 /etc/sendmail.pid`
192*67898Seric		sh -c "`tail -1 /etc/sendmail.pid`"
193*67898Seric
194*67898Seric	NOTA BENE:  kill -1 does not work!
19567892Seric----------------------------------------------------------------------
196*67898Seric  * OK, I did that, and the problem still occurs.
197*67898Seric
198*67898Seric	You probably forgot to to resta
199*67898Seric----------------------------------------------------------------------
20066282Seric  * When I use sendmail V8 with a Sun config file I get lines like:
20166282Seric
20266282Seric	/etc/sendmail.cf: line 273: replacement $3 out of bounds
20366282Seric
20466282Seric    the line in question reads:
20566282Seric
20666282Seric	R$*<@$%y>$*		$1<@$2.LOCAL>$3			user@ether
20766282Seric
20866282Seric    what does this mean?  How do I fix it?
20966282Seric
21066282Seric	V8 doesn't recognize the Sun "$%y" syntax, so as far as it
21166282Seric	is concerned, there is only a $1 and a $2 (but no $3) in this
21266282Seric	line.  Read Rick McCarty's paper on "Converting Standard Sun
21366282Seric	Config Files to Sendmail Version 8", in the contrib directory
21466282Seric	(file "converting.sun.configs") on the sendmail distribution
21566282Seric	for a full discussion of how to do this.
21666282Seric----------------------------------------------------------------------
21766282Seric  * Should I use a wildcard MX for my domain?
21866282Seric
21966282Seric	If at all possible, no.
22066282Seric
22166282Seric	Wildcard MX records have lots of semantic "gotcha"s.  For
22266282Seric	example, they will match a host "unknown.your.domain" -- if
22366282Seric	you don't explicitly test for unknown hosts in your domain,
22466282Seric	you will get "config error: mail loops back to myself"
22566282Seric	errors.
22666282Seric----------------------------------------------------------------------
22766282Seric  * I'm connected to the network via a SLIP link.  Sometimes my sendmail
22866282Seric    process hangs (although it looks like part of the message has been
22966282Seric    transfered).  Everything else works.  What's wrong?
23066282Seric
23166282Seric	Most likely, the problem isn't sendmail at all, but the low
23266282Seric	level network connection.  It's important that the MTU (Maximum
23366282Seric	Transfer Unit) for the SLIP connection be set properly at both
23466282Seric	ends.  If they disagree, large packets will be trashed and
23566282Seric	the connection will hang.
23666282Seric----------------------------------------------------------------------
23766282Seric  * I just upgraded to 8.x and suddenly I'm getting messages in my
23866282Seric    syslog of the form "collect: I/O error on connection".  What is
23966282Seric    going wrong?
24066282Seric
24166282Seric    	Nothing.  This is just a diagnosis of a condition that had
24266282Seric    	not been diagnosed before.  If you are getting a lot of these
24366282Seric    	from a single host, there is probably some incompatibility
24466282Seric    	between 8.x and that host.  If you get a lot of them in general,
24566282Seric    	you may have network problems that are causing connections to
24666282Seric    	get reset.
24766282Seric----------------------------------------------------------------------
24867892Seric  * I just upgraded to 8.x and suddenly connections to the SMTP port
24967892Seric    take a long time.  What is going wrong?
25067892Seric
25167892Seric	It's probably something wierd in your TCP implementation that
25267892Seric	makes the IDENT code act oddly.  On most systems V8 tries to
25367892Seric	do a ``callback'' to the connecting host to get a validated
25467892Seric	user name (see RFC 1413 for details).  If the connecting
25567892Seric	host does not support such a service it will normally fail
25667892Seric	quickly with "Connection refused", but certain kinds of
25767892Seric	packet filters and certain TCP implementations just time out.
25867892Seric
25967892Seric	To test this, set the IDENT timeout to zero using
26067892Seric	``OrIdent=0'' in the configuration file.  This will
26167892Seric	completely disable all use of the IDENT protocol.
26267892Seric
26367892Seric	Another possible problem is that you have your name server
26467892Seric	and/or resolver configured improperly.  Make sure that
26567892Seric	all "nameserver" entries in /etc/resolv.conf point to functional
26667892Seric	servers.  If you are running your own server make certain that
26767892Seric	all the servers listed in your root cache (usually called
26867892Seric	something like "/var/namedb/root.cache"; see your
26967892Seric	/etc/named.boot file to get your value) are up to date.
27067892Seric	Either of these can cause long delays.
27167892Seric----------------------------------------------------------------------
27267892Seric  * I just upgraded to 8.x and suddenly I get errors such as ``mail:
27367892Seric    options must follow recipients.''  What is going wrong?
27467892Seric
27567892Seric	You need OSTYPE(systype) in your .mc file -- otherwise the
27667892Seric	configurations use a default that probably disagrees with
27767892Seric	your local mail system.  See cf/README for details.
27867892Seric----------------------------------------------------------------------
27966282Seric  * How can I get sendmail to deliver local mail to $HOME/.mail
28066282Seric    instead of into /usr/spool/mail (or /usr/mail)?
28166282Seric
28266282Seric	This is a local mailer issue, not a sendmail issue.  Either
28366282Seric	modify your local mailer (source code will be required) or
28466282Seric	change the program called in the "local" mailer configuration
28566282Seric	description to be a new program that does this local delivery.
28666282Seric	I understand that "procmail" works well, although I haven't
28766282Seric	used it myself.
28866786Seric
28966786Seric	You might be interested in reading the paper ``HLFSD: Delivering
29066786Seric	Email to your $HOME'' available in the Proceedings of the
29166786Seric	USENIX System Administration (LISA VII) Conference (November
29266786Seric	1993).  This is also available via public FTP from
29366786Seric	ftp.cs.columbia.edu:/pub/hlfsd/{README.hlfsd,hlfsd.ps}.
29466282Seric----------------------------------------------------------------------
29566282Seric  * Under V8, the "From " header gets mysteriously munged when I send
29666282Seric    to an alias.
29766282Seric
29866282Seric	``It's not a bug, it's a feature.''  This happens when you have
29966282Seric	a "owner-list" alias and you send to "list".  V8 propogates the
30066282Seric	owner information into the envelope sender field (which appears
30166282Seric	as the "From " header on UNIX mail or as the Return-Path: header)
30266282Seric	so that downstream errors are properly returned to the mailing
30366282Seric	list owner instead of to the sender.  In order to make this
30466282Seric	appear as sensible as possible to end users, I recommend making
30566282Seric	the owner point to a "request" address -- for example:
30666282Seric
30766282Seric		list:		:include:/path/name/list.list
30866282Seric		owner-list:	list-request
30966282Seric		list-request:	eric
31066282Seric
31166282Seric	This will make message sent to "list" come out as being
31266282Seric	"From list-request" instead of "From eric".
31366282Seric----------------------------------------------------------------------
31466282Seric  * There are four UUCP mailers listed in the configuration files.
31566282Seric    Which one should I use?
31666282Seric
31766282Seric	The choice is partly a matter of local preferences and what is
31866282Seric	running at the other end of your UUCP connection.  Unlike good
31966282Seric	protocols that define what will go over the wire, UUCP uses
32066282Seric	the policy that you should do what is right for the other end;
32166282Seric	if they change, you have to change.  This makes it hard to
32266282Seric	do the right thing, and discourages people from updating their
32366282Seric	software.  In general, if you can avoid UUCP, please do.
32466282Seric
32566282Seric	If you can't avoid it, you'll have to find the version that is
32666282Seric	closest to what the other end accepts.  Following is a summary
32766282Seric	of the UUCP mailers available.
32866282Seric
32966282Seric	uucp-old (obsolete name: "uucp")
33066282Seric	  This is the oldest, the worst (but the closest to UUCP) way of
33166282Seric	  sending messages accros UUCP connections.  It does bangify
33266282Seric	  everything and prepends $U (your UUCP name) to the sender's
33366282Seric	  address (which can already be a bang path itself).  It can
33466282Seric	  only send to one address at a time, so it spends a lot of
33566282Seric	  time copying duplicates of messages.  Avoid this if at all
33666282Seric	  possible.
33766282Seric
33866282Seric	uucp-new (obsolete name: "suucp")
33966282Seric	  The same as above, except that it assumes that in one rmail
34066282Seric	  command you can specify several recipients.  It still has a
34166282Seric	  lot of other problems.
34266282Seric
34366282Seric	uucp-dom
34466282Seric	  This UUCP mailer keeps everything as domain addresses.
34566282Seric	  Basically, it uses the SMTP mailer rewriting rules.
34666282Seric
34766282Seric	  Unfortunately, a lot of UUCP mailer transport agents require
34866282Seric	  bangified addresses in the envelope, although you can use
34966282Seric	  domain-based addresses in the message header.  (The envelope
35066282Seric	  shows up as the From_ line on UNIX mail.)  So....
35166282Seric
35266282Seric	uucp-uudom
35366282Seric	  This is a cross between uucp-new (for the envelope addresses)
35466282Seric	  and uucp-dom (for the header addresses).  It bangifies the
35566282Seric	  envelope sender (From_ line in messages) without adding the
35666282Seric	  local hostname, unless there is no host name on the address
35766282Seric	  at all (e.g., "wolf") or the host component is a UUCP host name
35866282Seric	  instead of a domain name ("somehost!wolf" instead of
35966282Seric	  "some.dom.ain!wolf").
36066282Seric
36166282Seric	Examples:
36266282Seric
36366282Seric	We are on host grasp.insa-lyon.fr (UUCP host name "grasp").  The
36466282Seric	following summarizes the sender rewriting for various mailers.
36566282Seric
36666282Seric	Mailer          sender		rewriting in the envelope
36766282Seric	------		------		-------------------------
36866282Seric	uucp-{old,new}	wolf		grasp!wolf
36966282Seric	uucp-dom	wolf		wolf@grasp.insa-lyon.fr
37066282Seric	uucp-uudom	wolf		grasp.insa-lyon.fr!wolf
37166282Seric
37266282Seric	uucp-{old,new}	wolf@fr.net	grasp!fr.net!wolf
37366282Seric	uucp-dom	wolf@fr.net	wolf@fr.net
37466282Seric	uucp-uudom	wolf@fr.net	fr.net!wolf
37566282Seric
37666282Seric	uucp-{old,new}	somehost!wolf	grasp!somehost!wolf
37766282Seric	uucp-dom	somehost!wolf	somehost!wolf@grasp.insa-lyon.fr
37866282Seric	uucp-uudom	somehost!wolf	grasp.insa-lyon.fr!somehost!wolf
37966282Seric----------------------------------------------------------------------
38066282Seric  * I'm trying to to get my mail to go into queue only mode, and it
38166282Seric    delivers the mail interactively anyway.  (Or, I'm trying to use
38266282Seric    the "don't deliver to expensive mailer" flag, and it doesn't
38366282Seric    delivers the mail interactively anyway.)  I can see it does it:
38466282Seric    here's the output of "sendmail -v foo@somehost" (or Mail -v or
38566282Seric    equivalent).
38666282Seric
38766282Seric	The -v flag to sendmail (which is implied by the -v flag to
38866282Seric	Mail and other programs in that family) tells sendmail to
38966282Seric	watch the transaction.  Since you have explicitly asked to
39066282Seric	see what's going on, it assumes that you do not want to to
39166282Seric	auto-queue, and turns that feature off.  Remove the -v flag
39266282Seric	and use a "tail -f" of the log instead to see what's going on.
39366282Seric
39466282Seric	If you are trying to use the "don't deliver to expensive mailer"
39566282Seric	flag (mailer flag "e"), be sure you also turn on global option
39666282Seric	"c" -- otherwise it ignores the mailer flag.
39766282Seric----------------------------------------------------------------------
39866285Seric  * I want to run Sendmail version 8 on my DEC system, but you don't
39966285Seric    have MAIL11V3 support in sendmail.  How do I handle this?
40066285Seric
40166285Seric	Get Paul Vixie's reimplementation of the mail11 protocol
40266285Seric	from gatekeeper.dec.com in /pub/DEC/gwtools.
40366285Seric----------------------------------------------------------------------
404