xref: /csrg-svn/usr.sbin/sendmail/FAQ (revision 68445)
168330SericNewsgroups: comp.mail.sendmail,comp.mail.misc,comp.mail.smail,comp.answers,news.answers
268330SericSubject: comp.mail.sendmail Frequently Asked Questions (FAQ)
368330SericFrom: brad@birch.ims.disa.mil (Brad Knowles)
468330SericFollowup-to: comp.mail.sendmail
568330SericSummary: This posting contains a list of Frequently Asked Questions
668330Seric    (and their answers) about the program "sendmail", distributed
768330Seric    with many versions of Unix (and available for some other
868330Seric    operating systems).  This FAQ is shared between
968330Seric    comp.mail.sendmail and the Sendmail V8 distribution.  It should
1068330Seric    be read by anyone who wishes to post to comp.mail.sendmail, or
1168330Seric    anyone having questions about the newsgroup itself.
1268330Seric
1368330SericArchive-name: mail/sendmail-faq
1468330SericPosting-Frequency: monthly (first Monday)
1568330Seric
1668330Seric
1768330Seric[The most recent copy of this document can be obtained via anonymous
18*68445SericFTP from rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
19*68445SericIf you do not have access to anonymous FTP, you can retrieve it by
2068330Sericsending email to mail-server@rtfm.mit.edu with the command "send
2168330Sericusenet/news.answers/mail/sendmail-faq" in the message.]
2268330Seric
2368330Seric
2468330Seric
2566282Seric			    Sendmail Version 8
2666282Seric			Frequently Asked Questions
27*68445Seric		         Last updated 02/24/95
2866282Seric
2966282Seric
30*68445SericThis FAQ is specific to Version 8.6.10 of sendmail.  Other questions,
3168330Sericparticularly regarding compilation and configuration, are answered in
3268330Sericsrc/READ_ME and cf/README (found in the V8 sendmail distribution).
3366282Seric
3468330SericThis is also the official FAQ for the Usenet newsgroup
3568330Sericcomp.mail.sendmail.
3668330Seric
3768069Seric======================================================================
3868330SericBEFORE YOU GO ANY FURTHER
3968069Seric======================================================================
4068069Seric
4168330Seric  * What do you wish everyone would do before sending you mail or
4268330Seric    posting to comp.mail.sendmail?
4367892Seric
4467892Seric	Read this FAQ completely.  Read src/READ_ME and cf/README
4568330Seric	completely.  Read the books written to help with common
4668330Seric	problems such as compilation and installation, configuration,
4768330Seric	security issues, etc....  Ask themselves if their question
4868330Seric	hasn't already been answered.
4967892Seric----------------------------------------------------------------------
5068330Seric  * How can I be sure if this is the right place to look for answers
5168330Seric    to my questions?
5268330Seric
5368330Seric	1. Do you know, for a fact, that the question is related to
5468334Seric	   sendmail V8?
5568330Seric
5668330Seric	2. Do you know, for a fact, that the question is related to an
5768330Seric	   older version of sendmail?
5868330Seric
5968330Seric	3. Is the question about a sendmail-like program (e.g., Smail,
6068330Seric	   Zmailer, MMDF, etc...)?
6168330Seric
62*68445Seric	4. Is the question about an SMTP Gateway product for a LAN
63*68445Seric	   mail package (e.g., cc:Mail, MS-Mail, WordPerfect
64*68445Seric	   Office/GroupWise, etc...)?
6568330Seric
6668330Seric	If you answered "yes" to the question #1, then this is the
6768330Seric	right place.
6868330Seric
6968330Seric	If you answered "yes" to questions #2 or #3, then you should
7068330Seric	seriously consider upgrading to the most recent version of
7168330Seric	sendmail V8.
7268330Seric
73*68445Seric	For question #2, If you're going to continue using an older
7468330Seric	version of sendmail, you may not find much help and will
7568330Seric	probably get some responses that amount to "Get V8".
7668330Seric	Otherwise, this is probably the best place to look for
7768330Seric	answers.
7868330Seric
7968330Seric	If you answered "yes" to question #3 and are not going to
8068330Seric	upgrade to sendmail V8, then this is probably not the right
8168330Seric	place to look.
8268330Seric
8368330Seric	If you answered "yes" to question #4, then this is almost
8468330Seric	certainly not the right place to look.
8568330Seric
8668330Seric	For questions #3 and #4, try looking around elsewhere in the
8768330Seric	"comp.mail.*" hierarchy for a more appropriate newsgroup.
8868330Seric	For example, you might want to try posting to comp.mail.misc
8968330Seric	or comp.mail.smail.
9068330Seric
9168330Seric	If you couldn't answer "yes" to any of the above questions,
92*68445Seric	then you're DEFINITELY in the wrong place.  For the sake of
93*68445Seric	your sanity and ego, not to mention avoiding the waste of
94*68445Seric	your time and ours, try asking your System or E-Mail
9568330Seric	Administrator(s) before you post any questions publicly.
9668330Seric----------------------------------------------------------------------
9768330Seric  * Where can I find the latest version of this FAQ?
9868330Seric
9968330Seric	It is included in the most recent Version 8 distribution of
10068330Seric	sendmail (described below), as well as via anonymous FTP from
10168330Seric	rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
10268330Seric	If you do not have access to anonymous FTP, you can retrieve
10368330Seric	it by sending email to mail-server@rtfm.mit.edu with the
10468330Seric	command "send usenet/news.answers/mail/sendmail-faq" in the
10568330Seric	message.
10668330Seric----------------------------------------------------------------------
10768330Seric  * I don't have access to Usenet news.  Can I still get access to
10868330Seric    comp.mail.sendmail?
10968330Seric
11068330Seric	Yes.  Send email to mxt@dl.ac.uk with the command "sub
11168330Seric	comp-news.comp.mail.sendmail <full-US-ordered-email-address>"
11268330Seric	in the message.
11368330Seric
11468330Seric	E-mail you want posted on comp.mail.sendmail should be sent
11568330Seric	to comp-mail-sendmail@dl.ac.uk
11668330Seric----------------------------------------------------------------------
11768330Seric  * I have sendmail-related DNS questions.  Where should I ask them?
11868330Seric
11968330Seric	Depending on how deeply they get into the DNS, they can be
12068330Seric	asked here.  However, you'll probably be told that you should
12168330Seric	send them to the Info-BIND mailing list (if the question is
12268330Seric	specific to that program) or to the Usenet newsgroup
12368330Seric	comp.protocols.tcp-ip.domains (DNS in general).
12468330Seric----------------------------------------------------------------------
12568330Seric  * How do I subscribe to either of these?
12668330Seric
12768330Seric	For comp.protocols.tcp-ip.domains, you have to be on Usenet.
12868330Seric	They don't have a news-to-mail gateway yet.
12968330Seric
13068330Seric	For the Info-BIND mailing list, send email to
13168330Seric	bind-request@uunet.uu.net with the command "subscribe" in the
13268330Seric	message.  Submissions should be sent to bind@uunet.uu.net
13368330Seric
13468330Seric======================================================================
13568330SericGENERAL QUESTIONS
13668330Seric======================================================================
13768330Seric
13867021Seric  * Where can I get Version 8?
13967021Seric
14067021Seric	Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail.
14167021Seric----------------------------------------------------------------------
14266282Seric  * What are the differences between Version 8 and other versions?
14366282Seric
14467021Seric	See doc/changes/changes.me in the sendmail distribution.
14566282Seric----------------------------------------------------------------------
14666282Seric  * What happened to sendmail 6.x and 7.x?
14766282Seric
14868330Seric	When a new (Alpha/Beta) version of sendmail was released, it
14968330Seric	was changed to Release 6.  Development continued in that tree
15068330Seric	until 4.4BSD was released, when everything on the 4.4 tape
15168330Seric	was set to be version 8.1.  Version 7.x never existed.
15266282Seric----------------------------------------------------------------------
15368069Seric  * What books are available describing sendmail?
15468069Seric
15568069Seric	There is one book available devoted to sendmail:
15668069Seric
15768069Seric	    Costales, Allman, and Rickert, _Sendmail_.  O'Reilly &
15868069Seric		Associates.
15968069Seric
16068069Seric	Several books have sendmail chapters, for example:
16168069Seric
16268069Seric	    Nemeth, Snyder, and Seebass, _Unix System Administration
16368069Seric		Handbook_.  Prentice-Hall.
16468069Seric	    Carl-Mitchell and Quarterman, _Practical Internetworking with
16568069Seric		TCP/IP and UNIX_.  Addison-Wesley.
16668069Seric	    Hunt, _TCP/IP Network Administration_.  O'Reilly & Associates.
16768069Seric
16868069Seric	Another book about sendmail is due out "soon":
16968069Seric
17068069Seric	    Avolio & Vixie, _Sendmail Theory and Practice_.  Digital
17168069Seric		Press (release date unknown).
17268069Seric
17368330Seric	For details on sendmail-related DNS issues, consult:
17468330Seric
17568330Seric	    Liu and Albitz, _DNS and BIND_.  O'Reilly & Associates.
17668330Seric
17768330Seric	For details on UUCP, see:
17868330Seric
17968330Seric	    O'Reilly and Todino, _Managing UUCP and Usenet_.
18068330Seric		O'Reilly & Associates.
18168330Seric
18268069Seric======================================================================
18368069SericCOMPILING AND INSTALLING SENDMAIL 8
18468069Seric======================================================================
18568069Seric
18666282Seric  * Version 8 requires a new version of "make".  Where can I get this?
18766282Seric
18866282Seric	Actually, Version 8 does not require a new version of "make".
18966282Seric	It includes a collection of Makefiles for different architectures,
19067892Seric	only one or two of which require the new "make".  For a supported
19167892Seric	architecture, use ``sh makesendmail''.  If you are porting to a
19267892Seric	new architecture, start with Makefile.dist.
19366282Seric
19466282Seric	If you really do want the new make, it is available on any of
19567021Seric	the BSD Net2 or 4.4-Lite distribution sites.  These include:
19666282Seric
19766282Seric		ftp.uu.net		/systems/unix/bsd-sources
19866282Seric		gatekeeper.dec.com	/.0/BSD/net2
19966282Seric		ucquais.cba.uc.edu	/pub/net2
20066282Seric		ftp.luth.se		/pub/unix/4.3bsd/net2
20166282Seric
20268330Seric	Diffs and instructions for building this version of make
20368330Seric	under SunOS 4.1.x are available on ftp.css.itd.umich.edu in
20468330Seric	/pub/systems/sun/Net2-make.sun4.diff.Z.  A patchkit for
20568330Seric	Ultrix is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z.
20668330Seric	Patches for AIX 3.2.4 are available on ftp.uni-stuttgart.de
20768330Seric	in /sw/src/patches/bsd-make-rus-patches.
20867489Seric
20967489Seric	There is also a Linux version available on the main Linux
21067489Seric	distribution sites as pmake; this version is included as
21167489Seric	standard with the current Slackware distributions.
21266282Seric----------------------------------------------------------------------
21366282Seric  * What macro package do I use to format the V8 man pages?
21466282Seric
21568330Seric	The BSD group switched over the the ``mandoc'' macros for the
21668330Seric	4.4 release.  These include more hooks designed for hypertext
21768330Seric	handling.  However, new man pages won't format under the old
21868330Seric	man macros.  Fortunately, old man pages will format under the
21968330Seric	new mandoc macros.
22066282Seric
22168330Seric	Get the new macros with the BSD Net2 or 4.4-Lite release (see
22268330Seric	above for locations; for example, on FTP.UU.NET the files
22368330Seric	/system/unix/bsd-sources/share/tmac/me/strip/sed and
22468330Seric	/system/unix/bsd-sources/share/tmac/* are what you need).
22566282Seric
22668330Seric	This macro set is also included with newer versions of groff.
22768070Seric----------------------------------------------------------------------
22868070Seric  * What modes should be used when installing sendmail?
22966282Seric
23068070Seric	The sendmail binary should be owned by root, mode 4755.
23168070Seric	The queue directory should be owned by root, with a mode
23268330Seric		between 700 and 755.  Under no circumstances should
23368330Seric		it be group or other writable!
23468070Seric	The sendmail config file should be owned by root, mode 644.
23568070Seric	The aliases file should generally be owned by one trusted
23668330Seric		user and writable only by that user, although it is
23768330Seric		not unreasonable to have it group writable by a
23868330Seric		"sysadmin" group.  It should not be world writable.
23968070Seric	The aliases database files (aliases.db or aliases.{pag,dir}
24068070Seric		depending on what database format you compile with)
24168070Seric		should be owned by root, mode 644.
24268070Seric
24368069Seric======================================================================
24468069SericCONFIGURATION QUESTIONS
24568069Seric======================================================================
24666282Seric
24766282Seric  * How do I make all my addresses appear to be from a single host?
24866282Seric
24966282Seric	Using the V8 configuration macros, use:
25066282Seric
25166282Seric		MASQUERADE_AS(my.dom.ain)
25266282Seric
25366282Seric	This will cause all addresses to be sent out as being from
25466282Seric	the indicated domain.
25566282Seric----------------------------------------------------------------------
25666282Seric  * How do I rewrite my From: lines to read ``First_Last@My.Domain''?
25766282Seric
25868330Seric	There are a couple of ways of doing this.  This describes
25968330Seric	using the "user database" code.  This is still experimental,
26068330Seric	and was intended for a different purpose -- however, it does
26168330Seric	work with a bit of care.  It does require that you have the
26268330Seric	Berkeley "db" package installed (it won't work with DBM).
26366282Seric
26466282Seric	First, create your input file.  This should have lines like:
26566282Seric
26666282Seric		loginname:mailname	First_Last
26766282Seric		First_Last:maildrop	loginname
26866282Seric
26966282Seric	Install it in (say) /etc/userdb.  Create the database:
27066282Seric
27166282Seric		makemap btree /etc/userdb.db < /etc/userdb
27266282Seric
27366282Seric	You can then create a config file that uses this.  You will
27466282Seric	have to include the following in your .mc file:
27566282Seric
27666282Seric		define(confUSERDB_SPEC, /etc/userdb.db)
27766282Seric		FEATURE(notsticky)
27866282Seric----------------------------------------------------------------------
27966282Seric  * So what was the user database feature intended for?
28066282Seric
28168330Seric	The intent was to have all information for a given user
28268330Seric	(where the user is the unique login name, not an inherently
28368330Seric	non-unique full name) in one place.  This would include phone
28468330Seric	numbers, addresses, and so forth.  The "maildrop" feature is
28568330Seric	because Berkeley does not use a centralized mail server
28668330Seric	(there are a number of reasons for this that are mostly
28768330Seric	historic), and so we need to know where each user gets his or
28868330Seric	her mail delivered -- i.e., the mail drop.
28966282Seric
29066282Seric	We are in the process of setting up our environment so that
29166282Seric	mail sent to an unqualified "name" goes to that person's
29266282Seric	preferred maildrop; mail sent to "name@host" goes to that
29366282Seric	host.  The purpose of "FEATURE(notsticky)" is to cause
29466282Seric	"name@host" to be looked up in the user database for delivery
29566282Seric	to the maildrop.
29666282Seric----------------------------------------------------------------------
29766282Seric  * Why are you so hostile to using full names for e-mail addresses?
29866282Seric
29966282Seric	Because full names are not unique.  For example, the computer
30066282Seric	community has two Andy Tannenbaums and two Peter Deutsches.
30168330Seric	At one time, Bell Labs had two Stephen R. Bournes with
30268330Seric	offices a few doors apart.  You can create alternative
30368330Seric	addresses (e.g., Stephen_R_Bourne_2), but that's even worse
30468330Seric	-- which one of them has to have their name desecrated in
30568330Seric	this way?  And you can bet that one of them will get most of
30668330Seric	the other person's e-mail.
30766282Seric
30867892Seric	So called "full names" are just an attempt to create longer
30967892Seric	versions of unique names.  Rather that lulling people into a
31067892Seric	sense of security, I'd rather that it be clear that these
31167892Seric	handles are arbitrary.  People should use good user agents
31267892Seric	that have alias mappings so that they can attach arbitrary
31368330Seric	names for their personal use to those with whom they
31468330Seric	correspond (such as the MH alias file).
31566282Seric
31666282Seric	Even worse is fuzzy matching in e-mail -- this can make good
31768330Seric	addresses turn bad.  For example, Eric Allman is currently
31868330Seric	(to the best of our knowledge) the only ``Allman'' at
31968330Seric	Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to
32068330Seric	him.  But if another Allman ever appears, this address could
32168330Seric	suddenly become ambiguous.  He's been the only Allman at
32268330Seric	Berkeley for over fifteen years -- to suddenly have this
32368330Seric	"good address" bounce mail because it is ambiguous would be a
32468330Seric	heinous wrong.
32566282Seric
32667892Seric	Finger services should be as fuzzy as possible (within
32767892Seric	reason, of course).  Mail services should be unique.
32866282Seric----------------------------------------------------------------------
32968069Seric  * Should I use a wildcard MX for my domain?
33068069Seric
33168069Seric	If at all possible, no.
33268069Seric
33368069Seric	Wildcard MX records have lots of semantic "gotcha"s.  For
33468069Seric	example, they will match a host "unknown.your.domain" -- if
33568069Seric	you don't explicitly test for unknown hosts in your domain,
33668069Seric	you will get "config error: mail loops back to myself"
33768069Seric	errors.
338*68445Seric
339*68445Seric	See RFCs 1535-1537 for more detail and other related (or
340*68445Seric	common) problems.
34168069Seric----------------------------------------------------------------------
34268330Seric  * How can I get sendmail to process messages sent to an account and
34368330Seric    send the results back to the originator?
34468330Seric
34568330Seric	This is a local mailer issue, not a sendmail issue.
34668330Seric	Depending on what you're doing, look at procmail (mentioned
34768330Seric	again below), ftpmail, or Majordomo.
34868330Seric
34968330Seric	Check your local archie server to see what machine(s) nearest
35068330Seric	you have the most recent versions of these programs.
35168330Seric----------------------------------------------------------------------
35268069Seric  * How can I get sendmail to deliver local mail to $HOME/.mail
35368069Seric    instead of into /usr/spool/mail (or /usr/mail)?
35468069Seric
35568330Seric	Again, this is a local mailer issue, not a sendmail issue.
35668330Seric	Either modify your local mailer (source code will be
35768330Seric	required) or change the program called in the "local" mailer
35868330Seric	configuration description to be a new program that does this
359*68445Seric	local delivery.  One program that is capable of doing this is
360*68445Seric	"procmail", although there are probably many others as well.
36168069Seric
36268330Seric	You might be interested in reading the paper ``HLFSD:
36368330Seric	Delivering Email to your $HOME'' available in the Proceedings
36468330Seric	of the USENIX System Administration (LISA VII) Conference
36568330Seric	(November 1993).  This is also available via public FTP from
36668330Seric	ftp.cs.columbia.edu in /pub/hlfsd/{README.hlfsd,hlfsd.ps}.
36768069Seric----------------------------------------------------------------------
36868069Seric  * I'm trying to to get my mail to go into queue only mode, and it
36968069Seric    delivers the mail interactively anyway.  (Or, I'm trying to use
37068330Seric    the "don't deliver to expensive mailer" flag, and it delivers the
37168330Seric    mail interactively anyway.)  I can see it does it:  here's the
37268330Seric    output of "sendmail -v foo@somehost" (or Mail -v or equivalent).
37368069Seric
37468069Seric	The -v flag to sendmail (which is implied by the -v flag to
37568069Seric	Mail and other programs in that family) tells sendmail to
37668069Seric	watch the transaction.  Since you have explicitly asked to
37768069Seric	see what's going on, it assumes that you do not want to to
37868069Seric	auto-queue, and turns that feature off.  Remove the -v flag
37968330Seric	and use a "tail -f" of the log instead to see what's going
38068330Seric	on.
38168069Seric
38268330Seric	If you are trying to use the "don't deliver to expensive
38368330Seric	mailer" flag (mailer flag "e"), be sure you also turn on
38468330Seric	global option "c" -- otherwise it ignores the mailer flag.
38568069Seric----------------------------------------------------------------------
38668069Seric  * There are four UUCP mailers listed in the configuration files.
38768069Seric    Which one should I use?
38868069Seric
38968330Seric	The choice is partly a matter of local preferences and what
39068330Seric	is running at the other end of your UUCP connection.  Unlike
39168330Seric	good protocols that define what will go over the wire, UUCP
39268330Seric	uses the policy that you should do what is right for the
39368330Seric	other end; if they change, you have to change.  This makes it
39468330Seric	hard to do the right thing, and discourages people from
39568330Seric	updating their software.  In general, if you can avoid UUCP,
39668330Seric	please do.
39768069Seric
39868330Seric	If you can't avoid it, you'll have to find the version that
39968330Seric	is closest to what the other end accepts.  Following is a
40068330Seric	summary of the UUCP mailers available.
40168069Seric
40268069Seric	uucp-old (obsolete name: "uucp")
40368330Seric	  This is the oldest, the worst (but the closest to UUCP) way
40468330Seric	  of sending messages across UUCP connections.  It does
40568330Seric	  bangify everything and prepends $U (your UUCP name) to the
40668330Seric	  sender's address (which can already be a bang path
40768330Seric	  itself).  It can only send to one address at a time, so it
40868330Seric	  spends a lot of time copying duplicates of messages.  Avoid
40968330Seric	  this if at all possible.
41068069Seric
41168069Seric	uucp-new (obsolete name: "suucp")
41268069Seric	  The same as above, except that it assumes that in one rmail
41368069Seric	  command you can specify several recipients.  It still has a
41468069Seric	  lot of other problems.
41568069Seric
41668069Seric	uucp-dom
41768069Seric	  This UUCP mailer keeps everything as domain addresses.
41868069Seric	  Basically, it uses the SMTP mailer rewriting rules.
41968069Seric
42068330Seric	  Unfortunately, a lot of UUCP mailer transport agents
42168330Seric	  require bangified addresses in the envelope, although you
42268330Seric	  can use domain-based addresses in the message header.  (The
42368330Seric	  envelope shows up as the From_ line on UNIX mail.)  So....
42468069Seric
42568069Seric	uucp-uudom
42668330Seric	  This is a cross between uucp-new (for the envelope
42768330Seric	  addresses) and uucp-dom (for the header addresses).  It
42868330Seric	  bangifies the envelope sender (From_ line in messages)
42968330Seric	  without adding the local hostname, unless there is no host
43068330Seric	  name on the address at all (e.g., "wolf") or the host
43168330Seric	  component is a UUCP host name instead of a domain name
43268330Seric	  ("somehost!wolf" instead of "some.dom.ain!wolf").
43368069Seric
43468069Seric	Examples:
43568069Seric
43668330Seric	We are on host grasp.insa-lyon.fr (UUCP host name "grasp").
43768330Seric	The following summarizes the sender rewriting for various
43868330Seric	mailers.
43968069Seric
44068069Seric	Mailer          sender		rewriting in the envelope
44168069Seric	------		------		-------------------------
44268069Seric	uucp-{old,new}	wolf		grasp!wolf
44368069Seric	uucp-dom	wolf		wolf@grasp.insa-lyon.fr
44468069Seric	uucp-uudom	wolf		grasp.insa-lyon.fr!wolf
44568069Seric
44668069Seric	uucp-{old,new}	wolf@fr.net	grasp!fr.net!wolf
44768069Seric	uucp-dom	wolf@fr.net	wolf@fr.net
44868069Seric	uucp-uudom	wolf@fr.net	fr.net!wolf
44968069Seric
45068069Seric	uucp-{old,new}	somehost!wolf	grasp!somehost!wolf
45168069Seric	uucp-dom	somehost!wolf	somehost!wolf@grasp.insa-lyon.fr
45268069Seric	uucp-uudom	somehost!wolf	grasp.insa-lyon.fr!somehost!wolf
45368069Seric
45468069Seric======================================================================
45568069SericRESOLVING PROBLEMS
45668069Seric======================================================================
45768069Seric
45868069Seric  * When I compile, I get "undefined symbol inet_aton" messages.
45968069Seric
46068069Seric	You've probably replaced your resolver with the version from
46168330Seric	BIND 4.9.3.  You need to compile with -l44bsd in order to get
46268069Seric	the additional routines.
46368069Seric----------------------------------------------------------------------
46467892Seric  * I'm getting "Local configuration error" messages, such as:
46567892Seric
46667892Seric	553 relay.domain.net config error: mail loops back to myself
46767892Seric	554 <user@domain.net>... Local configuration error
46867892Seric
46967892Seric    How can I solve this problem?
47067892Seric
47167892Seric	You have asked mail to the domain (e.g., domain.net) to be
47267892Seric	forwarded to a specific host (in this case, relay.domain.net)
47368330Seric	by using an MX record, but the relay machine doesn't
47468330Seric	recognize itself as domain.net.  Add domain.net to
47568330Seric	/etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or
47668330Seric	add "Cw domain.net" to your configuration file.
47767898Seric
47867898Seric	IMPORTANT:  Be sure you kill and restart the sendmail daemon
47967898Seric	after you change the configuration file (for ANY change in
48067898Seric	the configuration, not just this one):
48167898Seric
48267898Seric		kill `head -1 /etc/sendmail.pid`
48367898Seric		sh -c "`tail -1 /etc/sendmail.pid`"
48467898Seric
48567898Seric	NOTA BENE:  kill -1 does not work!
48667892Seric----------------------------------------------------------------------
48766282Seric  * When I use sendmail V8 with a Sun config file I get lines like:
48866282Seric
48966282Seric	/etc/sendmail.cf: line 273: replacement $3 out of bounds
49066282Seric
49166282Seric    the line in question reads:
49266282Seric
49366282Seric	R$*<@$%y>$*		$1<@$2.LOCAL>$3			user@ether
49466282Seric
49566282Seric    what does this mean?  How do I fix it?
49666282Seric
49768330Seric	V8 doesn't recognize the Sun "$%y" syntax, so as far as it is
49868330Seric	concerned, there is only a $1 and a $2 (but no $3) in this
49966282Seric	line.  Read Rick McCarty's paper on "Converting Standard Sun
50066282Seric	Config Files to Sendmail Version 8", in the contrib directory
50166282Seric	(file "converting.sun.configs") on the sendmail distribution
50266282Seric	for a full discussion of how to do this.
50366282Seric----------------------------------------------------------------------
50468330Seric  * When I use sendmail V8 on a Sun, I sometimes get lines like:
50566282Seric
50668330Seric	/etc/sendmail.cf: line 445: bad ruleset 96 (50 max)
50768330Seric
50868330Seric    what does this mean?  How do I fix it?
50968330Seric
51068330Seric	You're somehow trying to start up the old Sun sendmail (or
51168330Seric	sendmail.mx) with a sendmail V8 config file, which Sun's
51268330Seric	sendmail doesn't like.  Check your /etc/rc.local, any
51368330Seric	procedures that have been created to stop and re-start the
51468330Seric	sendmail processes, etc....  Make sure that you've switched
51568330Seric	everything over to using the new sendmail.  To keep this
51668330Seric	problem from ever happening again, try the following:
51768330Seric
51868330Seric	    mv /usr/lib/sendmail /usr/lib/sendmail.old
51968330Seric	    ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail
52068330Seric	    mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old
52168330Seric	    ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx
52268330Seric	    chmod 0000 /usr/lib/sendmail.old
52368330Seric	    chmod 0000 /usr/lib/sendmail.mx.old
52468330Seric
52568330Seric	Assuming you have installed sendmail V8 in /usr/local/lib.
52668330Seric----------------------------------------------------------------------
52768330Seric  * When I use sendmail V8 on an IBM RS/6000 running AIX, the system
52868330Seric    resource controller always reports sendmail as "inoperative" even
52968330Seric    though it is running.  What's wrong?
53068330Seric
53168330Seric	IBM's system resource controller is one of their "value
53268330Seric	added" features to AIX -- it's not a Unix standard.  You'll
53368330Seric	need to either redefine the subsystem to use signals (see
53468330Seric	chssys(1)) or dump the entire subsystem and invoke sendmail
53568330Seric	in /etc/rc.tcpip or some other boot script.
53668330Seric----------------------------------------------------------------------
53768330Seric  * When I use sendmail V8 on an Intel x86 machine running Linux, I
53868330Seric    have some problems.  Specifically, I have....
53968330Seric
54068330Seric	The current versions of Linux are generally considered to be
54168334Seric	great for hobbyists and anyone else who wants to learn Unix
54268330Seric	inside and out, or wants to always have something to do, or
54368334Seric	wants a machine for light-duty mostly personal use and not
54468334Seric	high-volume multi-user purposes.
54568330Seric
54668330Seric	However, for those who want a system that will just sit in
54768330Seric	the background and work without a fuss handling thousands of
54868330Seric	mail messages a day for lots of different users, it's not
54968330Seric	(yet) stable enough to fit the bill.
55068330Seric
55168330Seric	Unfortunately, there are no known shareware/freeware
55268330Seric	implementations of any operating system that provides the
55368334Seric	level of stability necessary to handle that kind of load
55468334Seric	(i.e., there are no free lunches).
55568334Seric
55668334Seric	If you're wedded to the Intel x86 platform and want to run
55768334Seric	sendmail, we suggest you look at commercial implementations
558*68445Seric	of Unix such as Interactive, UnixWare, Solaris, or BSD/386
55968334Seric	(just a sample of the dozens of different versions of Unix
56068334Seric	for Intel x86).
56168334Seric
56268334Seric	Of all known vendor supported versions of Unix for Intel x86,
56368334Seric	BSDI's BSD/386 is least expensive and the only one known to
56468334Seric	currently ship with sendmail V8 pre-installed.  Since sendmail
56568334Seric	V8 is continuing to be developed at UC Berkeley, and BSD/386
56668334Seric	is a full BSD 4.4 implementation, this is obviously be the most
56768334Seric	"native" sendmail V8 environment.
56868330Seric----------------------------------------------------------------------
56968330Seric  * When I use sendmail on an Intel x86 machine running OS/2, I have
57068330Seric    some problems.  Specifically, I have....
57168330Seric
57268330Seric	The OS/2 port of sendmail is known to have left out huge
57368330Seric	chunks of the code and functionality of even much older
57468330Seric	versions of sendmail, in large part because the underlying OS
57568330Seric	just doesn't have the necessary hooks to make it happen.
57668330Seric	This port is so broken that we make no attempt to provide any
577*68445Seric	kind of support for it.  Try BSDI's BSD/386 instead.
57868330Seric----------------------------------------------------------------------
57968330Seric  * I'm connected to the network via a SLIP/PPP link.  Sometimes my
58068330Seric    sendmail process hangs (although it looks like part of the
58168330Seric    message has been transfered).  Everything else works.  What's
58268330Seric    wrong?
58368330Seric
58466282Seric	Most likely, the problem isn't sendmail at all, but the low
58568330Seric	level network connection.  It's important that the MTU
58668330Seric	(Maximum Transfer Unit) for the SLIP connection be set
58768330Seric	properly at both ends.  If they disagree, large packets will
58868330Seric	be trashed and the connection will hang.
58966282Seric----------------------------------------------------------------------
59066282Seric  * I just upgraded to 8.x and suddenly I'm getting messages in my
59166282Seric    syslog of the form "collect: I/O error on connection".  What is
59266282Seric    going wrong?
59366282Seric
59468330Seric	Nothing.  This is just a diagnosis of a condition that had
59568330Seric	not been diagnosed before.  If you are getting a lot of these
59668330Seric	from a single host, there is probably some incompatibility
59768330Seric	between 8.x and that host.  If you get a lot of them in
59868330Seric	general, you may have network problems that are causing
59968330Seric	connections to get reset.
60066282Seric----------------------------------------------------------------------
60168338Seric  * I just upgraded to 8.x and now when my users try to forward their
60268338Seric    mail to a program they get an "illegal shell" message and their
60368338Seric    mail is not delivered.  What's wrong?
60468338Seric
60568338Seric	In order for people to be able to run a program from their
60668338Seric	.forward file, 8.x insists that their shell (that is, the
60768338Seric	shell listed for that user in the passwd entry) be a "valid"
60868338Seric	shell, meaning a shell listed in /etc/shells.  If /etc/shells
60968338Seric	does not exist, a default list is used, typically consisting
61068338Seric	of /bin/sh and /bin/csh.
61168338Seric
61268338Seric	This is to support environments that may have NFS-shared
61368338Seric	directories mounted on machines on which users do not have
61468338Seric	login permission.  For example, many people make their
61568338Seric	file server inaccessible for performance or security
61668338Seric	reasons; although users have directories, their shell on
61768338Seric	the server is /usr/local/etc/nologin or some such.  If you
61868338Seric	allowed them to run programs anyway you might as well let
61968338Seric	them log in.
62068338Seric
62168338Seric	If you are willing to let users run programs from their
62268338Seric	.forward file even though they cannot telnet or rsh in (as
62368338Seric	might be reasonable if you run smrsh to control the list of
62468338Seric	programs they can run) then add the line
62568338Seric
62668338Seric		/SENDMAIL/ANY/SHELL/
62768338Seric
62868338Seric	to /etc/shells.  This must be typed exactly as indicated,
62968338Seric	in caps, with the trailing slash.  NOTA BENE:  DO NOT
63068338Seric	list /usr/local/etc/nologin in /etc/shells -- this will
63168338Seric	open up other security problems.
63268338Seric----------------------------------------------------------------------
63367892Seric  * I just upgraded to 8.x and suddenly connections to the SMTP port
63467892Seric    take a long time.  What is going wrong?
63567892Seric
63668330Seric	It's probably something weird in your TCP implementation that
63767892Seric	makes the IDENT code act oddly.  On most systems V8 tries to
63867892Seric	do a ``callback'' to the connecting host to get a validated
63968330Seric	user name (see RFC 1413 for detail).  If the connecting host
64068330Seric	does not support such a service it will normally fail quickly
64168330Seric	with "Connection refused", but certain kinds of packet
64268330Seric	filters and certain TCP implementations just time out.
64367892Seric
64467892Seric	To test this, set the IDENT timeout to zero using
64567892Seric	``OrIdent=0'' in the configuration file.  This will
64667892Seric	completely disable all use of the IDENT protocol.
64767892Seric
64867892Seric	Another possible problem is that you have your name server
64968330Seric	and/or resolver configured improperly.  Make sure that all
65068330Seric	"nameserver" entries in /etc/resolv.conf point to functional
65168330Seric	servers.  If you are running your own server make certain
65268330Seric	that all the servers listed in your root cache (usually
65368330Seric	called something like "/var/namedb/root.cache"; see your
65467892Seric	/etc/named.boot file to get your value) are up to date.
65567892Seric	Either of these can cause long delays.
65667892Seric----------------------------------------------------------------------
65768338Seric  * I just upgraded to 8.x and suddenly I get errors such as ``unknown
65868338Seric    mailer error 5 -- mail: options MUST PRECEDE recipients.''  What is
65968338Seric    going wrong?
66067892Seric
66167892Seric	You need OSTYPE(systype) in your .mc file -- otherwise the
66267892Seric	configurations use a default that probably disagrees with
66367892Seric	your local mail system.  See cf/README for details.
66467892Seric----------------------------------------------------------------------
66566282Seric  * Under V8, the "From " header gets mysteriously munged when I send
66666282Seric    to an alias.
66766282Seric
66868330Seric	``It's not a bug, it's a feature.''  This happens when you
66968330Seric	have a "owner-list" alias and you send to "list".  V8
67068330Seric	propagates the owner information into the envelope sender
67168330Seric	field (which appears as the "From " header on UNIX mail or as
67268330Seric	the Return-Path: header) so that downstream errors are
67368330Seric	properly returned to the mailing list owner instead of to the
67468330Seric	sender.  In order to make this appear as sensible as possible
67568330Seric	to end users, I recommend making the owner point to a
67668330Seric	"request" address -- for example:
67766282Seric
67866282Seric		list:		:include:/path/name/list.list
67966282Seric		owner-list:	list-request
68066282Seric		list-request:	eric
68166282Seric
68268330Seric	This will make message sent to "list" come out as being "From
68368330Seric	list-request" instead of "From eric".
68466282Seric----------------------------------------------------------------------
68568330Seric  * I am trying to use MASQUERADE_AS (or the user database) to
68668330Seric    rewrite from addresses, and although it works in the From: header
68768330Seric    line, it doesn't work in the envelope (e.g., the "From " line).
68868330Seric
68968330Seric	Believe it or not, this is intentional.  The interpretation
69068330Seric	of the standards by the V8 development group was that this
69168330Seric	was an inappropriate rewriting, and that if the rewriting
69268330Seric	were incorrect at least the envelope would contain a valid
69368330Seric	return address.  Other people have since described scenarios
69468330Seric	where the envelope cannot be correct without this rewriting,
69568330Seric	so 8.7 will have an option to rewrite both header and
69668330Seric	envelope.
69768330Seric----------------------------------------------------------------------
69866285Seric  * I want to run Sendmail version 8 on my DEC system, but you don't
69966285Seric    have MAIL11V3 support in sendmail.  How do I handle this?
70066285Seric
70168330Seric	Get Paul Vixie's reimplementation of the mail11 protocol from
70268330Seric	gatekeeper.dec.com in /pub/DEC/gwtools.
70368330Seric
70468330Seric	Rumour has it that he will be fully integrating into sendmail
70568330Seric	V8 what little is left of IDA sendmail that is not handled
70668330Seric	(or handled as well) by V8.  No additional information on
70768330Seric	this project is currently available.
70866285Seric----------------------------------------------------------------------
70968069Seric  * Messages seem to disappear from my queue unsent.  When I look in
71068330Seric    the queue directory I see that they have been renamed from qf* to
71168330Seric    Qf*, and sendmail doesn't see these.
71268069Seric
71368069Seric	If you look closely you should find that the Qf files are
71468069Seric	owned by users other than root.  Since sendmail runs as root
71568069Seric	it refuses to believe information in non-root-owned qf files,
71668330Seric	and it renames them to Qf to get them out of the way and make
71768330Seric	it easy for you to find.  The usual cause of this is
71868069Seric	twofold:  first, you have the queue directory world writable
71968069Seric	(which is probably a mistake -- this opens up other security
72068069Seric	problems) and someone is calling sendmail with an "unsafe"
72168069Seric	flag, usually a -o flag that sets an option that could
72268069Seric	compromise security.  When sendmail sees this it gives up
72368069Seric	setuid root permissions.
72468069Seric
72568330Seric	The usual solution is to not use the problematic flags.  If
72668330Seric	you must use them, you have to write a special queue
72768069Seric	directory and have them processed by the same uid that
72868069Seric	submitted the job in the first place.
72968069Seric----------------------------------------------------------------------
730*68445Seric@(#)FAQ	8.15	(Berkeley)	02/24/95
73168330SericSend updates to sendmail@CS.Berkeley.EDU.
732