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