xref: /csrg-svn/usr.sbin/sendmail/FAQ (revision 68070)

			    Sendmail Version 8
			Frequently Asked Questions
		         Version 8.10 of 12/09/94


This FAQ is specific to Version 8 of sendmail.  Other questions,
particularly regarding compilation and configuration, are answered
in src/READ_ME and cf/README (found in the V8 sendmail distribution).

======================================================================
GENERAL QUESTIONS
======================================================================

  * What do you wish everyone would do before sending you mail?

	Read this FAQ completely.  Read src/READ_ME and cf/README
	completely.  Ask themselves if their question hasn't already
	been answered.
----------------------------------------------------------------------
  * Where can I get Version 8?

	Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail.
----------------------------------------------------------------------
  * What are the differences between Version 8 and other versions?

	See doc/changes/changes.me in the sendmail distribution.
----------------------------------------------------------------------
  * What happened to sendmail 6.x and 7.x?

	When I released a new (Alpha/Beta) version of sendmail, I changed
	it to Release 6.  Development continued in that tree until 4.4BSD
	was released, when everything on the 4.4 tape was set to be
	version 8.1.  Version 7.x never existed.
----------------------------------------------------------------------
  * What books are available describing sendmail?

	There is one book available devoted to sendmail:

	    Costales, Allman, and Rickert, _Sendmail_.  O'Reilly &
		Associates.

	Several books have sendmail chapters, for example:

	    Nemeth, Snyder, and Seebass, _Unix System Administration
		Handbook_.  Prentice-Hall.
	    Carl-Mitchell and Quarterman, _Practical Internetworking with
		TCP/IP and UNIX_.  Addison-Wesley.
	    Hunt, _TCP/IP Network Administration_.  O'Reilly & Associates.

	Another book about sendmail is due out "soon":

	    Avolio & Vixie, _Sendmail Theory and Practice_.  Digital
		Press (release date unknown).

======================================================================
COMPILING AND INSTALLING SENDMAIL 8
======================================================================

  * Version 8 requires a new version of "make".  Where can I get this?

	Actually, Version 8 does not require a new version of "make".
	It includes a collection of Makefiles for different architectures,
	only one or two of which require the new "make".  For a supported
	architecture, use ``sh makesendmail''.  If you are porting to a
	new architecture, start with Makefile.dist.

	If you really do want the new make, it is available on any of
	the BSD Net2 or 4.4-Lite distribution sites.  These include:

		ftp.uu.net		/systems/unix/bsd-sources
		gatekeeper.dec.com	/.0/BSD/net2
		ucquais.cba.uc.edu	/pub/net2
		ftp.luth.se		/pub/unix/4.3bsd/net2

	Diffs and instructions for building this version of make under
	SunOS 4.1.x are available on ftp.css.itd.umich.edu in
	/pub/systems/sun/Net2-make.sun4.diff.Z.  A patchkit for Ultrix
 	is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z.  Patches
	for AIX 3.2.4 are available on ftp.uni-stuttgart.de in
	/sw/src/patches/bsd-make-rus-patches.

	There is also a Linux version available on the main Linux
	distribution sites as pmake; this version is included as
	standard with the current Slackware distributions.
----------------------------------------------------------------------
  * What macro package do I use to format the V8 man pages?

	The BSD group switched over the the ``mandoc'' macros for
	the 4.4 release.  These include more hooks designed for
	hypertext handling.  However, new man pages won't format
	under the old man macros.  Fortunately, old man pages will
	format under the new mandoc macros.

	Get the new macros with the BSD Net2 or 4.4-Lite release
	(see above).

	This macro set is also available with newer versions of groff.
----------------------------------------------------------------------
  * What modes should be used when installing sendmail?

	The sendmail binary should be owned by root, mode 4755.
	The queue directory should be owned by root, with a mode
		between 700 and 755.  Under no circumstances
		should it be group or other writable!
	The sendmail config file should be owned by root, mode 644.
	The aliases file should generally be owned by one trusted
		user and writable only by that user, although it
		is not unreasonable to have it group writable by
		a "sysadmin" group.  It should not be world writable.
	The aliases database files (aliases.db or aliases.{pag,dir}
		depending on what database format you compile with)
		should be owned by root, mode 644.

======================================================================
CONFIGURATION QUESTIONS
======================================================================

  * How do I make all my addresses appear to be from a single host?

	Using the V8 configuration macros, use:

		MASQUERADE_AS(my.dom.ain)

	This will cause all addresses to be sent out as being from
	the indicated domain.
----------------------------------------------------------------------
  * How do I rewrite my From: lines to read ``First_Last@My.Domain''?

	There are a couple of ways of doing this.  This describes using
	the "user database" code.  This is still experimental, and was
	intended for a different purpose -- however, it does work
	with a bit of care.  It does require that you have the Berkeley
	"db" package installed (it won't work with DBM).

	First, create your input file.  This should have lines like:

		loginname:mailname	First_Last
		First_Last:maildrop	loginname

	Install it in (say) /etc/userdb.  Create the database:

		makemap btree /etc/userdb.db < /etc/userdb

	You can then create a config file that uses this.  You will
	have to include the following in your .mc file:

		define(confUSERDB_SPEC, /etc/userdb.db)
		FEATURE(notsticky)
----------------------------------------------------------------------
  * So what was the user database feature intended for?

	The intent was to have all information for a given user (where
	the user is the unique login name, not an inherently non-unique
	full name) in one place.  This would include phone numbers,
	addresses, and so forth.  The "maildrop" feature is because
	Berkeley does not use a centralized mail server (there are a
	number of reasons for this that are mostly historic), and so
	we need to know where each user gets his or her mail delivered --
	i.e., the mail drop.

	We are in the process of setting up our environment so that
	mail sent to an unqualified "name" goes to that person's
	preferred maildrop; mail sent to "name@host" goes to that
	host.  The purpose of "FEATURE(notsticky)" is to cause
	"name@host" to be looked up in the user database for delivery
	to the maildrop.
----------------------------------------------------------------------
  * Why are you so hostile to using full names for e-mail addresses?

	Because full names are not unique.  For example, the computer
	community has two Andy Tannenbaums and two Peter Deutsches.
	At one time, Bell Labs had two Stephen R. Bournes with offices
	a few doors apart.  You can create alternative addresses
	(e.g., Stephen_R_Bourne_2), but that's even worse -- which
	one of them has to have their name desecrated in this way?
	And you can bet that one of them will get most of the other
	person's e-mail.

	So called "full names" are just an attempt to create longer
	versions of unique names.  Rather that lulling people into a
	sense of security, I'd rather that it be clear that these
	handles are arbitrary.  People should use good user agents
	that have alias mappings so that they can attach arbitrary
	names for their personal use to those with whom they correspond
	(such as the MH alias file).

	Even worse is fuzzy matching in e-mail -- this can make good
	addresses turn bad.  For example, I'm currently (to the best
	of my knowledge) the only ``Allman'' at Berkeley, so mail
	sent to "Allman@Berkeley.EDU" should get to me.  But if
	another Allman ever appears, this address could suddenly
	become ambiguous.  I've been the only Allman at Berkeley for
	over fifteen years -- to suddenly have this "good address"
	bounce mail because it is ambiguous would be a heinous wrong.

	Finger services should be as fuzzy as possible (within
	reason, of course).  Mail services should be unique.
----------------------------------------------------------------------
  * Should I use a wildcard MX for my domain?

	If at all possible, no.

	Wildcard MX records have lots of semantic "gotcha"s.  For
	example, they will match a host "unknown.your.domain" -- if
	you don't explicitly test for unknown hosts in your domain,
	you will get "config error: mail loops back to myself"
	errors.
----------------------------------------------------------------------
  * How can I get sendmail to deliver local mail to $HOME/.mail
    instead of into /usr/spool/mail (or /usr/mail)?

	This is a local mailer issue, not a sendmail issue.  Either
	modify your local mailer (source code will be required) or
	change the program called in the "local" mailer configuration
	description to be a new program that does this local delivery.
	I understand that "procmail" works well, although I haven't
	used it myself.

	You might be interested in reading the paper ``HLFSD: Delivering
	Email to your $HOME'' available in the Proceedings of the
	USENIX System Administration (LISA VII) Conference (November
	1993).  This is also available via public FTP from
	ftp.cs.columbia.edu:/pub/hlfsd/{README.hlfsd,hlfsd.ps}.
----------------------------------------------------------------------
  * I'm trying to to get my mail to go into queue only mode, and it
    delivers the mail interactively anyway.  (Or, I'm trying to use
    the "don't deliver to expensive mailer" flag, and it doesn't
    delivers the mail interactively anyway.)  I can see it does it:
    here's the output of "sendmail -v foo@somehost" (or Mail -v or
    equivalent).

	The -v flag to sendmail (which is implied by the -v flag to
	Mail and other programs in that family) tells sendmail to
	watch the transaction.  Since you have explicitly asked to
	see what's going on, it assumes that you do not want to to
	auto-queue, and turns that feature off.  Remove the -v flag
	and use a "tail -f" of the log instead to see what's going on.

	If you are trying to use the "don't deliver to expensive mailer"
	flag (mailer flag "e"), be sure you also turn on global option
	"c" -- otherwise it ignores the mailer flag.
----------------------------------------------------------------------
  * There are four UUCP mailers listed in the configuration files.
    Which one should I use?

	The choice is partly a matter of local preferences and what is
	running at the other end of your UUCP connection.  Unlike good
	protocols that define what will go over the wire, UUCP uses
	the policy that you should do what is right for the other end;
	if they change, you have to change.  This makes it hard to
	do the right thing, and discourages people from updating their
	software.  In general, if you can avoid UUCP, please do.

	If you can't avoid it, you'll have to find the version that is
	closest to what the other end accepts.  Following is a summary
	of the UUCP mailers available.

	uucp-old (obsolete name: "uucp")
	  This is the oldest, the worst (but the closest to UUCP) way of
	  sending messages accros UUCP connections.  It does bangify
	  everything and prepends $U (your UUCP name) to the sender's
	  address (which can already be a bang path itself).  It can
	  only send to one address at a time, so it spends a lot of
	  time copying duplicates of messages.  Avoid this if at all
	  possible.

	uucp-new (obsolete name: "suucp")
	  The same as above, except that it assumes that in one rmail
	  command you can specify several recipients.  It still has a
	  lot of other problems.

	uucp-dom
	  This UUCP mailer keeps everything as domain addresses.
	  Basically, it uses the SMTP mailer rewriting rules.

	  Unfortunately, a lot of UUCP mailer transport agents require
	  bangified addresses in the envelope, although you can use
	  domain-based addresses in the message header.  (The envelope
	  shows up as the From_ line on UNIX mail.)  So....

	uucp-uudom
	  This is a cross between uucp-new (for the envelope addresses)
	  and uucp-dom (for the header addresses).  It bangifies the
	  envelope sender (From_ line in messages) without adding the
	  local hostname, unless there is no host name on the address
	  at all (e.g., "wolf") or the host component is a UUCP host name
	  instead of a domain name ("somehost!wolf" instead of
	  "some.dom.ain!wolf").

	Examples:

	We are on host grasp.insa-lyon.fr (UUCP host name "grasp").  The
	following summarizes the sender rewriting for various mailers.

	Mailer          sender		rewriting in the envelope
	------		------		-------------------------
	uucp-{old,new}	wolf		grasp!wolf
	uucp-dom	wolf		wolf@grasp.insa-lyon.fr
	uucp-uudom	wolf		grasp.insa-lyon.fr!wolf

	uucp-{old,new}	wolf@fr.net	grasp!fr.net!wolf
	uucp-dom	wolf@fr.net	wolf@fr.net
	uucp-uudom	wolf@fr.net	fr.net!wolf

	uucp-{old,new}	somehost!wolf	grasp!somehost!wolf
	uucp-dom	somehost!wolf	somehost!wolf@grasp.insa-lyon.fr
	uucp-uudom	somehost!wolf	grasp.insa-lyon.fr!somehost!wolf

======================================================================
RESOLVING PROBLEMS
======================================================================

  * When I compile, I get "undefined symbol inet_aton" messages.

	You've probably replaced your resolver with the version from
	BIND 4.9.3.  You need to cmpile with -l44bsd in order to get
	the additional routines.
----------------------------------------------------------------------
  * I'm getting "Local configuration error" messages, such as:

	553 relay.domain.net config error: mail loops back to myself
	554 <user@domain.net>... Local configuration error

    How can I solve this problem?

	You have asked mail to the domain (e.g., domain.net) to be
	forwarded to a specific host (in this case, relay.domain.net)
	by using an MX record, but the relay machine doesn't recognize
	itself as domain.net.  Add domain.net to /etc/sendmail.cw
	(if you are using FEATURE(use_cw_file)) or add "Cw domain.net"
	to your configuration file.

	IMPORTANT:  Be sure you kill and restart the sendmail daemon
	after you change the configuration file (for ANY change in
	the configuration, not just this one):

		kill `head -1 /etc/sendmail.pid`
		sh -c "`tail -1 /etc/sendmail.pid`"

	NOTA BENE:  kill -1 does not work!
----------------------------------------------------------------------
  * When I use sendmail V8 with a Sun config file I get lines like:

	/etc/sendmail.cf: line 273: replacement $3 out of bounds

    the line in question reads:

	R$*<@$%y>$*		$1<@$2.LOCAL>$3			user@ether

    what does this mean?  How do I fix it?

	V8 doesn't recognize the Sun "$%y" syntax, so as far as it
	is concerned, there is only a $1 and a $2 (but no $3) in this
	line.  Read Rick McCarty's paper on "Converting Standard Sun
	Config Files to Sendmail Version 8", in the contrib directory
	(file "converting.sun.configs") on the sendmail distribution
	for a full discussion of how to do this.
----------------------------------------------------------------------
  * I'm connected to the network via a SLIP link.  Sometimes my sendmail
    process hangs (although it looks like part of the message has been
    transfered).  Everything else works.  What's wrong?

	Most likely, the problem isn't sendmail at all, but the low
	level network connection.  It's important that the MTU (Maximum
	Transfer Unit) for the SLIP connection be set properly at both
	ends.  If they disagree, large packets will be trashed and
	the connection will hang.
----------------------------------------------------------------------
  * I just upgraded to 8.x and suddenly I'm getting messages in my
    syslog of the form "collect: I/O error on connection".  What is
    going wrong?

    	Nothing.  This is just a diagnosis of a condition that had
    	not been diagnosed before.  If you are getting a lot of these
    	from a single host, there is probably some incompatibility
    	between 8.x and that host.  If you get a lot of them in general,
    	you may have network problems that are causing connections to
    	get reset.
----------------------------------------------------------------------
  * I just upgraded to 8.x and suddenly connections to the SMTP port
    take a long time.  What is going wrong?

	It's probably something wierd in your TCP implementation that
	makes the IDENT code act oddly.  On most systems V8 tries to
	do a ``callback'' to the connecting host to get a validated
	user name (see RFC 1413 for details).  If the connecting
	host does not support such a service it will normally fail
	quickly with "Connection refused", but certain kinds of
	packet filters and certain TCP implementations just time out.

	To test this, set the IDENT timeout to zero using
	``OrIdent=0'' in the configuration file.  This will
	completely disable all use of the IDENT protocol.

	Another possible problem is that you have your name server
	and/or resolver configured improperly.  Make sure that
	all "nameserver" entries in /etc/resolv.conf point to functional
	servers.  If you are running your own server make certain that
	all the servers listed in your root cache (usually called
	something like "/var/namedb/root.cache"; see your
	/etc/named.boot file to get your value) are up to date.
	Either of these can cause long delays.
----------------------------------------------------------------------
  * I just upgraded to 8.x and suddenly I get errors such as ``mail:
    options must follow recipients.''  What is going wrong?

	You need OSTYPE(systype) in your .mc file -- otherwise the
	configurations use a default that probably disagrees with
	your local mail system.  See cf/README for details.
----------------------------------------------------------------------
  * Under V8, the "From " header gets mysteriously munged when I send
    to an alias.

	``It's not a bug, it's a feature.''  This happens when you have
	a "owner-list" alias and you send to "list".  V8 propogates the
	owner information into the envelope sender field (which appears
	as the "From " header on UNIX mail or as the Return-Path: header)
	so that downstream errors are properly returned to the mailing
	list owner instead of to the sender.  In order to make this
	appear as sensible as possible to end users, I recommend making
	the owner point to a "request" address -- for example:

		list:		:include:/path/name/list.list
		owner-list:	list-request
		list-request:	eric

	This will make message sent to "list" come out as being
	"From list-request" instead of "From eric".
----------------------------------------------------------------------
  * I want to run Sendmail version 8 on my DEC system, but you don't
    have MAIL11V3 support in sendmail.  How do I handle this?

	Get Paul Vixie's reimplementation of the mail11 protocol
	from gatekeeper.dec.com in /pub/DEC/gwtools.
----------------------------------------------------------------------
  * Messages seem to disappear from my queue unsent.  When I look in
    the queue directory I see that they have been renamed from qf*
    to Qf*, and sendmail doesn't see these.

	If you look closely you should find that the Qf files are
	owned by users other than root.  Since sendmail runs as root
	it refuses to believe information in non-root-owned qf files,
	and it renames them to Qf to get them out of the way and
	make it easy for you to find.  The usual cause of this is
	twofold:  first, you have the queue directory world writable
	(which is probably a mistake -- this opens up other security
	problems) and someone is calling sendmail with an "unsafe"
	flag, usually a -o flag that sets an option that could
	compromise security.  When sendmail sees this it gives up
	setuid root permissions.

	The usual solution is to not use the problematic flags.
	If you must use them, you have to write a special queue
	directory and have them processed by the same uid that
	submitted the job in the first place.
----------------------------------------------------------------------