xref: /csrg-svn/usr.sbin/sendmail/FAQ (revision 68330)
1*68330SericNewsgroups: comp.mail.sendmail,comp.mail.misc,comp.mail.smail,comp.answers,news.answers
2*68330SericSubject: comp.mail.sendmail Frequently Asked Questions (FAQ)
3*68330SericFrom: brad@birch.ims.disa.mil (Brad Knowles)
4*68330SericFollowup-to: comp.mail.sendmail
5*68330SericSummary: This posting contains a list of Frequently Asked Questions
6*68330Seric    (and their answers) about the program "sendmail", distributed
7*68330Seric    with many versions of Unix (and available for some other
8*68330Seric    operating systems).  This FAQ is shared between
9*68330Seric    comp.mail.sendmail and the Sendmail V8 distribution.  It should
10*68330Seric    be read by anyone who wishes to post to comp.mail.sendmail, or
11*68330Seric    anyone having questions about the newsgroup itself.
12*68330Seric
13*68330SericArchive-name: mail/sendmail-faq
14*68330SericPosting-Frequency: monthly (first Monday)
15*68330SericLast-modified: Sat Feb 11 03:26:18 EST 1995
16*68330Seric
17*68330Seric
18*68330Seric[The most recent copy of this document can be obtained via anonymous
19*68330SericFTP as rtfm.mit.edu:/pub/usenet/news.answers/mail/sendmail-faq.  If
20*68330Sericyou do not have access to anonymous FTP, you can retrieve it by
21*68330Sericsending email to mail-server@rtfm.mit.edu with the command "send
22*68330Sericusenet/news.answers/mail/sendmail-faq" in the message.]
23*68330Seric
24*68330Seric
25*68330Seric
2666282Seric			    Sendmail Version 8
2766282Seric			Frequently Asked Questions
28*68330Seric		         Last updated 02/14/95
2966282Seric
3066282Seric
31*68330SericThis FAQ is specific to Version 8.6.9 of sendmail.  Other questions,
32*68330Sericparticularly regarding compilation and configuration, are answered in
33*68330Sericsrc/READ_ME and cf/README (found in the V8 sendmail distribution).
3466282Seric
35*68330SericThis is also the official FAQ for the Usenet newsgroup
36*68330Sericcomp.mail.sendmail.
37*68330Seric
3868069Seric======================================================================
39*68330SericBEFORE YOU GO ANY FURTHER
4068069Seric======================================================================
4168069Seric
42*68330Seric  * What do you wish everyone would do before sending you mail or
43*68330Seric    posting to comp.mail.sendmail?
4467892Seric
4567892Seric	Read this FAQ completely.  Read src/READ_ME and cf/README
46*68330Seric	completely.  Read the books written to help with common
47*68330Seric	problems such as compilation and installation, configuration,
48*68330Seric	security issues, etc....  Ask themselves if their question
49*68330Seric	hasn't already been answered.
5067892Seric----------------------------------------------------------------------
51*68330Seric  * How can I be sure if this is the right place to look for answers
52*68330Seric    to my questions?
53*68330Seric
54*68330Seric	1. Do you know, for a fact, that the question is related to
55*68330Seric	   sendmail V8 or IDA sendmail?
56*68330Seric
57*68330Seric	2. Do you know, for a fact, that the question is related to an
58*68330Seric	   older version of sendmail?
59*68330Seric
60*68330Seric	3. Is the question about a sendmail-like program (e.g., Smail,
61*68330Seric	   Zmailer, MMDF, etc...)?
62*68330Seric
63*68330Seric	4. Is the question about an SMTP Gateway product for a LAN mail
64*68330Seric	   package (e.g., cc:Mail, MS-Mail WordPerfect Office/GroupWise,
65*68330Seric	   etc...)?
66*68330Seric
67*68330Seric	If you answered "yes" to the question #1, then this is the
68*68330Seric	right place.
69*68330Seric
70*68330Seric	If you answered "yes" to questions #2 or #3, then you should
71*68330Seric	seriously consider upgrading to the most recent version of
72*68330Seric	sendmail V8.
73*68330Seric
74*68330Seric	For question #2, If you're going to contiue using an older
75*68330Seric	version of sendmail, you may not find much help and will
76*68330Seric	probably get some responses that amount to "Get V8".
77*68330Seric	Otherwise, this is probably the best place to look for
78*68330Seric	answers.
79*68330Seric
80*68330Seric	If you answered "yes" to question #3 and are not going to
81*68330Seric	upgrade to sendmail V8, then this is probably not the right
82*68330Seric	place to look.
83*68330Seric
84*68330Seric	If you answered "yes" to question #4, then this is almost
85*68330Seric	certainly not the right place to look.
86*68330Seric
87*68330Seric	For questions #3 and #4, try looking around elsewhere in the
88*68330Seric	"comp.mail.*" hierarchy for a more appropriate newsgroup.
89*68330Seric	For example, you might want to try posting to comp.mail.misc
90*68330Seric	or comp.mail.smail.
91*68330Seric
92*68330Seric	If you couldn't answer "yes" to any of the above questions,
93*68330Seric	then you're DEFINITELY asking in the wrong place.  For the
94*68330Seric	sake of your sanity and ego, not to mention avoiding the
95*68330Seric	waste of your time and ours, try asking your System or E-Mail
96*68330Seric	Administrator(s) before you post any questions publicly.
97*68330Seric----------------------------------------------------------------------
98*68330Seric  * Where can I find the latest version of this FAQ?
99*68330Seric
100*68330Seric	It is included in the most recent Version 8 distribution of
101*68330Seric	sendmail (described below), as well as via anonymous FTP from
102*68330Seric	rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
103*68330Seric	If you do not have access to anonymous FTP, you can retrieve
104*68330Seric	it by sending email to mail-server@rtfm.mit.edu with the
105*68330Seric	command "send usenet/news.answers/mail/sendmail-faq" in the
106*68330Seric	message.
107*68330Seric----------------------------------------------------------------------
108*68330Seric  * I don't have access to Usenet news.  Can I still get access to
109*68330Seric    comp.mail.sendmail?
110*68330Seric
111*68330Seric	Yes.  Send email to mxt@dl.ac.uk with the command "sub
112*68330Seric	comp-news.comp.mail.sendmail <full-US-ordered-email-address>"
113*68330Seric	in the message.
114*68330Seric
115*68330Seric	E-mail you want posted on comp.mail.sendmail should be sent
116*68330Seric	to comp-mail-sendmail@dl.ac.uk
117*68330Seric----------------------------------------------------------------------
118*68330Seric  * I have sendmail-related DNS questions.  Where should I ask them?
119*68330Seric
120*68330Seric	Depending on how deeply they get into the DNS, they can be
121*68330Seric	asked here.  However, you'll probably be told that you should
122*68330Seric	send them to the Info-BIND mailing list (if the question is
123*68330Seric	specific to that program) or to the Usenet newsgroup
124*68330Seric	comp.protocols.tcp-ip.domains (DNS in general).
125*68330Seric----------------------------------------------------------------------
126*68330Seric  * How do I subscribe to either of these?
127*68330Seric
128*68330Seric	For comp.protocols.tcp-ip.domains, you have to be on Usenet.
129*68330Seric	They don't have a news-to-mail gateway yet.
130*68330Seric
131*68330Seric	For the Info-BIND mailing list, send email to
132*68330Seric	bind-request@uunet.uu.net with the command "subscribe" in the
133*68330Seric	message.  Submissions should be sent to bind@uunet.uu.net
134*68330Seric
135*68330Seric======================================================================
136*68330SericGENERAL QUESTIONS
137*68330Seric======================================================================
138*68330Seric
13967021Seric  * Where can I get Version 8?
14067021Seric
14167021Seric	Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail.
14267021Seric----------------------------------------------------------------------
14366282Seric  * What are the differences between Version 8 and other versions?
14466282Seric
14567021Seric	See doc/changes/changes.me in the sendmail distribution.
14666282Seric----------------------------------------------------------------------
14766282Seric  * What happened to sendmail 6.x and 7.x?
14866282Seric
149*68330Seric	When a new (Alpha/Beta) version of sendmail was released, it
150*68330Seric	was changed to Release 6.  Development continued in that tree
151*68330Seric	until 4.4BSD was released, when everything on the 4.4 tape
152*68330Seric	was set to be version 8.1.  Version 7.x never existed.
15366282Seric----------------------------------------------------------------------
15468069Seric  * What books are available describing sendmail?
15568069Seric
15668069Seric	There is one book available devoted to sendmail:
15768069Seric
15868069Seric	    Costales, Allman, and Rickert, _Sendmail_.  O'Reilly &
15968069Seric		Associates.
16068069Seric
16168069Seric	Several books have sendmail chapters, for example:
16268069Seric
16368069Seric	    Nemeth, Snyder, and Seebass, _Unix System Administration
16468069Seric		Handbook_.  Prentice-Hall.
16568069Seric	    Carl-Mitchell and Quarterman, _Practical Internetworking with
16668069Seric		TCP/IP and UNIX_.  Addison-Wesley.
16768069Seric	    Hunt, _TCP/IP Network Administration_.  O'Reilly & Associates.
16868069Seric
16968069Seric	Another book about sendmail is due out "soon":
17068069Seric
17168069Seric	    Avolio & Vixie, _Sendmail Theory and Practice_.  Digital
17268069Seric		Press (release date unknown).
17368069Seric
174*68330Seric	For details on sendmail-related DNS issues, consult:
175*68330Seric
176*68330Seric	    Liu and Albitz, _DNS and BIND_.  O'Reilly & Associates.
177*68330Seric
178*68330Seric	For details on UUCP, see:
179*68330Seric
180*68330Seric	    O'Reilly and Todino, _Managing UUCP and Usenet_.
181*68330Seric		O'Reilly & Associates.
182*68330Seric
18368069Seric======================================================================
18468069SericCOMPILING AND INSTALLING SENDMAIL 8
18568069Seric======================================================================
18668069Seric
18766282Seric  * Version 8 requires a new version of "make".  Where can I get this?
18866282Seric
18966282Seric	Actually, Version 8 does not require a new version of "make".
19066282Seric	It includes a collection of Makefiles for different architectures,
19167892Seric	only one or two of which require the new "make".  For a supported
19267892Seric	architecture, use ``sh makesendmail''.  If you are porting to a
19367892Seric	new architecture, start with Makefile.dist.
19466282Seric
19566282Seric	If you really do want the new make, it is available on any of
19667021Seric	the BSD Net2 or 4.4-Lite distribution sites.  These include:
19766282Seric
19866282Seric		ftp.uu.net		/systems/unix/bsd-sources
19966282Seric		gatekeeper.dec.com	/.0/BSD/net2
20066282Seric		ucquais.cba.uc.edu	/pub/net2
20166282Seric		ftp.luth.se		/pub/unix/4.3bsd/net2
20266282Seric
203*68330Seric	Diffs and instructions for building this version of make
204*68330Seric	under SunOS 4.1.x are available on ftp.css.itd.umich.edu in
205*68330Seric	/pub/systems/sun/Net2-make.sun4.diff.Z.  A patchkit for
206*68330Seric	Ultrix is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z.
207*68330Seric	Patches for AIX 3.2.4 are available on ftp.uni-stuttgart.de
208*68330Seric	in /sw/src/patches/bsd-make-rus-patches.
20967489Seric
21067489Seric	There is also a Linux version available on the main Linux
21167489Seric	distribution sites as pmake; this version is included as
21267489Seric	standard with the current Slackware distributions.
21366282Seric----------------------------------------------------------------------
21466282Seric  * What macro package do I use to format the V8 man pages?
21566282Seric
216*68330Seric	The BSD group switched over the the ``mandoc'' macros for the
217*68330Seric	4.4 release.  These include more hooks designed for hypertext
218*68330Seric	handling.  However, new man pages won't format under the old
219*68330Seric	man macros.  Fortunately, old man pages will format under the
220*68330Seric	new mandoc macros.
22166282Seric
222*68330Seric	Get the new macros with the BSD Net2 or 4.4-Lite release (see
223*68330Seric	above for locations; for example, on FTP.UU.NET the files
224*68330Seric	/system/unix/bsd-sources/share/tmac/me/strip/sed and
225*68330Seric	/system/unix/bsd-sources/share/tmac/* are what you need).
22666282Seric
227*68330Seric	This macro set is also included with newer versions of groff.
22868070Seric----------------------------------------------------------------------
22968070Seric  * What modes should be used when installing sendmail?
23066282Seric
23168070Seric	The sendmail binary should be owned by root, mode 4755.
23268070Seric	The queue directory should be owned by root, with a mode
233*68330Seric		between 700 and 755.  Under no circumstances should
234*68330Seric		it be group or other writable!
23568070Seric	The sendmail config file should be owned by root, mode 644.
23668070Seric	The aliases file should generally be owned by one trusted
237*68330Seric		user and writable only by that user, although it is
238*68330Seric		not unreasonable to have it group writable by a
239*68330Seric		"sysadmin" group.  It should not be world writable.
24068070Seric	The aliases database files (aliases.db or aliases.{pag,dir}
24168070Seric		depending on what database format you compile with)
24268070Seric		should be owned by root, mode 644.
24368070Seric
24468069Seric======================================================================
24568069SericCONFIGURATION QUESTIONS
24668069Seric======================================================================
24766282Seric
24866282Seric  * How do I make all my addresses appear to be from a single host?
24966282Seric
25066282Seric	Using the V8 configuration macros, use:
25166282Seric
25266282Seric		MASQUERADE_AS(my.dom.ain)
25366282Seric
25466282Seric	This will cause all addresses to be sent out as being from
25566282Seric	the indicated domain.
25666282Seric----------------------------------------------------------------------
25766282Seric  * How do I rewrite my From: lines to read ``First_Last@My.Domain''?
25866282Seric
259*68330Seric	There are a couple of ways of doing this.  This describes
260*68330Seric	using the "user database" code.  This is still experimental,
261*68330Seric	and was intended for a different purpose -- however, it does
262*68330Seric	work with a bit of care.  It does require that you have the
263*68330Seric	Berkeley "db" package installed (it won't work with DBM).
26466282Seric
26566282Seric	First, create your input file.  This should have lines like:
26666282Seric
26766282Seric		loginname:mailname	First_Last
26866282Seric		First_Last:maildrop	loginname
26966282Seric
27066282Seric	Install it in (say) /etc/userdb.  Create the database:
27166282Seric
27266282Seric		makemap btree /etc/userdb.db < /etc/userdb
27366282Seric
27466282Seric	You can then create a config file that uses this.  You will
27566282Seric	have to include the following in your .mc file:
27666282Seric
27766282Seric		define(confUSERDB_SPEC, /etc/userdb.db)
27866282Seric		FEATURE(notsticky)
27966282Seric----------------------------------------------------------------------
28066282Seric  * So what was the user database feature intended for?
28166282Seric
282*68330Seric	The intent was to have all information for a given user
283*68330Seric	(where the user is the unique login name, not an inherently
284*68330Seric	non-unique full name) in one place.  This would include phone
285*68330Seric	numbers, addresses, and so forth.  The "maildrop" feature is
286*68330Seric	because Berkeley does not use a centralized mail server
287*68330Seric	(there are a number of reasons for this that are mostly
288*68330Seric	historic), and so we need to know where each user gets his or
289*68330Seric	her mail delivered -- i.e., the mail drop.
29066282Seric
29166282Seric	We are in the process of setting up our environment so that
29266282Seric	mail sent to an unqualified "name" goes to that person's
29366282Seric	preferred maildrop; mail sent to "name@host" goes to that
29466282Seric	host.  The purpose of "FEATURE(notsticky)" is to cause
29566282Seric	"name@host" to be looked up in the user database for delivery
29666282Seric	to the maildrop.
29766282Seric----------------------------------------------------------------------
29866282Seric  * Why are you so hostile to using full names for e-mail addresses?
29966282Seric
30066282Seric	Because full names are not unique.  For example, the computer
30166282Seric	community has two Andy Tannenbaums and two Peter Deutsches.
302*68330Seric	At one time, Bell Labs had two Stephen R. Bournes with
303*68330Seric	offices a few doors apart.  You can create alternative
304*68330Seric	addresses (e.g., Stephen_R_Bourne_2), but that's even worse
305*68330Seric	-- which one of them has to have their name desecrated in
306*68330Seric	this way?  And you can bet that one of them will get most of
307*68330Seric	the other person's e-mail.
30866282Seric
30967892Seric	So called "full names" are just an attempt to create longer
31067892Seric	versions of unique names.  Rather that lulling people into a
31167892Seric	sense of security, I'd rather that it be clear that these
31267892Seric	handles are arbitrary.  People should use good user agents
31367892Seric	that have alias mappings so that they can attach arbitrary
314*68330Seric	names for their personal use to those with whom they
315*68330Seric	correspond (such as the MH alias file).
31666282Seric
31766282Seric	Even worse is fuzzy matching in e-mail -- this can make good
318*68330Seric	addresses turn bad.  For example, Eric Allman is currently
319*68330Seric	(to the best of our knowledge) the only ``Allman'' at
320*68330Seric	Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to
321*68330Seric	him.  But if another Allman ever appears, this address could
322*68330Seric	suddenly become ambiguous.  He's been the only Allman at
323*68330Seric	Berkeley for over fifteen years -- to suddenly have this
324*68330Seric	"good address" bounce mail because it is ambiguous would be a
325*68330Seric	heinous wrong.
32666282Seric
32767892Seric	Finger services should be as fuzzy as possible (within
32867892Seric	reason, of course).  Mail services should be unique.
32966282Seric----------------------------------------------------------------------
33068069Seric  * Should I use a wildcard MX for my domain?
33168069Seric
33268069Seric	If at all possible, no.
33368069Seric
33468069Seric	Wildcard MX records have lots of semantic "gotcha"s.  For
33568069Seric	example, they will match a host "unknown.your.domain" -- if
33668069Seric	you don't explicitly test for unknown hosts in your domain,
33768069Seric	you will get "config error: mail loops back to myself"
33868069Seric	errors.
33968069Seric----------------------------------------------------------------------
340*68330Seric  * How can I get sendmail to process messages sent to an account and
341*68330Seric    send the results back to the originator?
342*68330Seric
343*68330Seric	This is a local mailer issue, not a sendmail issue.
344*68330Seric	Depending on what you're doing, look at procmail (mentioned
345*68330Seric	again below), ftpmail, or Majordomo.
346*68330Seric
347*68330Seric	Check your local archie server to see what machine(s) nearest
348*68330Seric	you have the most recent versions of these programs.
349*68330Seric----------------------------------------------------------------------
35068069Seric  * How can I get sendmail to deliver local mail to $HOME/.mail
35168069Seric    instead of into /usr/spool/mail (or /usr/mail)?
35268069Seric
353*68330Seric	Again, this is a local mailer issue, not a sendmail issue.
354*68330Seric	Either modify your local mailer (source code will be
355*68330Seric	required) or change the program called in the "local" mailer
356*68330Seric	configuration description to be a new program that does this
357*68330Seric	local delivery.  I understand that "procmail" works well,
358*68330Seric	although I haven't used it myself.
35968069Seric
360*68330Seric	You might be interested in reading the paper ``HLFSD:
361*68330Seric	Delivering Email to your $HOME'' available in the Proceedings
362*68330Seric	of the USENIX System Administration (LISA VII) Conference
363*68330Seric	(November 1993).  This is also available via public FTP from
364*68330Seric	ftp.cs.columbia.edu in /pub/hlfsd/{README.hlfsd,hlfsd.ps}.
36568069Seric----------------------------------------------------------------------
36668069Seric  * I'm trying to to get my mail to go into queue only mode, and it
36768069Seric    delivers the mail interactively anyway.  (Or, I'm trying to use
368*68330Seric    the "don't deliver to expensive mailer" flag, and it delivers the
369*68330Seric    mail interactively anyway.)  I can see it does it:  here's the
370*68330Seric    output of "sendmail -v foo@somehost" (or Mail -v or equivalent).
37168069Seric
37268069Seric	The -v flag to sendmail (which is implied by the -v flag to
37368069Seric	Mail and other programs in that family) tells sendmail to
37468069Seric	watch the transaction.  Since you have explicitly asked to
37568069Seric	see what's going on, it assumes that you do not want to to
37668069Seric	auto-queue, and turns that feature off.  Remove the -v flag
377*68330Seric	and use a "tail -f" of the log instead to see what's going
378*68330Seric	on.
37968069Seric
380*68330Seric	If you are trying to use the "don't deliver to expensive
381*68330Seric	mailer" flag (mailer flag "e"), be sure you also turn on
382*68330Seric	global option "c" -- otherwise it ignores the mailer flag.
38368069Seric----------------------------------------------------------------------
38468069Seric  * There are four UUCP mailers listed in the configuration files.
38568069Seric    Which one should I use?
38668069Seric
387*68330Seric	The choice is partly a matter of local preferences and what
388*68330Seric	is running at the other end of your UUCP connection.  Unlike
389*68330Seric	good protocols that define what will go over the wire, UUCP
390*68330Seric	uses the policy that you should do what is right for the
391*68330Seric	other end; if they change, you have to change.  This makes it
392*68330Seric	hard to do the right thing, and discourages people from
393*68330Seric	updating their software.  In general, if you can avoid UUCP,
394*68330Seric	please do.
39568069Seric
396*68330Seric	If you can't avoid it, you'll have to find the version that
397*68330Seric	is closest to what the other end accepts.  Following is a
398*68330Seric	summary of the UUCP mailers available.
39968069Seric
40068069Seric	uucp-old (obsolete name: "uucp")
401*68330Seric	  This is the oldest, the worst (but the closest to UUCP) way
402*68330Seric	  of sending messages across UUCP connections.  It does
403*68330Seric	  bangify everything and prepends $U (your UUCP name) to the
404*68330Seric	  sender's address (which can already be a bang path
405*68330Seric	  itself).  It can only send to one address at a time, so it
406*68330Seric	  spends a lot of time copying duplicates of messages.  Avoid
407*68330Seric	  this if at all possible.
40868069Seric
40968069Seric	uucp-new (obsolete name: "suucp")
41068069Seric	  The same as above, except that it assumes that in one rmail
41168069Seric	  command you can specify several recipients.  It still has a
41268069Seric	  lot of other problems.
41368069Seric
41468069Seric	uucp-dom
41568069Seric	  This UUCP mailer keeps everything as domain addresses.
41668069Seric	  Basically, it uses the SMTP mailer rewriting rules.
41768069Seric
418*68330Seric	  Unfortunately, a lot of UUCP mailer transport agents
419*68330Seric	  require bangified addresses in the envelope, although you
420*68330Seric	  can use domain-based addresses in the message header.  (The
421*68330Seric	  envelope shows up as the From_ line on UNIX mail.)  So....
42268069Seric
42368069Seric	uucp-uudom
424*68330Seric	  This is a cross between uucp-new (for the envelope
425*68330Seric	  addresses) and uucp-dom (for the header addresses).  It
426*68330Seric	  bangifies the envelope sender (From_ line in messages)
427*68330Seric	  without adding the local hostname, unless there is no host
428*68330Seric	  name on the address at all (e.g., "wolf") or the host
429*68330Seric	  component is a UUCP host name instead of a domain name
430*68330Seric	  ("somehost!wolf" instead of "some.dom.ain!wolf").
43168069Seric
43268069Seric	Examples:
43368069Seric
434*68330Seric	We are on host grasp.insa-lyon.fr (UUCP host name "grasp").
435*68330Seric	The following summarizes the sender rewriting for various
436*68330Seric	mailers.
43768069Seric
43868069Seric	Mailer          sender		rewriting in the envelope
43968069Seric	------		------		-------------------------
44068069Seric	uucp-{old,new}	wolf		grasp!wolf
44168069Seric	uucp-dom	wolf		wolf@grasp.insa-lyon.fr
44268069Seric	uucp-uudom	wolf		grasp.insa-lyon.fr!wolf
44368069Seric
44468069Seric	uucp-{old,new}	wolf@fr.net	grasp!fr.net!wolf
44568069Seric	uucp-dom	wolf@fr.net	wolf@fr.net
44668069Seric	uucp-uudom	wolf@fr.net	fr.net!wolf
44768069Seric
44868069Seric	uucp-{old,new}	somehost!wolf	grasp!somehost!wolf
44968069Seric	uucp-dom	somehost!wolf	somehost!wolf@grasp.insa-lyon.fr
45068069Seric	uucp-uudom	somehost!wolf	grasp.insa-lyon.fr!somehost!wolf
45168069Seric
45268069Seric======================================================================
45368069SericRESOLVING PROBLEMS
45468069Seric======================================================================
45568069Seric
45668069Seric  * When I compile, I get "undefined symbol inet_aton" messages.
45768069Seric
45868069Seric	You've probably replaced your resolver with the version from
459*68330Seric	BIND 4.9.3.  You need to compile with -l44bsd in order to get
46068069Seric	the additional routines.
46168069Seric----------------------------------------------------------------------
46267892Seric  * I'm getting "Local configuration error" messages, such as:
46367892Seric
46467892Seric	553 relay.domain.net config error: mail loops back to myself
46567892Seric	554 <user@domain.net>... Local configuration error
46667892Seric
46767892Seric    How can I solve this problem?
46867892Seric
46967892Seric	You have asked mail to the domain (e.g., domain.net) to be
47067892Seric	forwarded to a specific host (in this case, relay.domain.net)
471*68330Seric	by using an MX record, but the relay machine doesn't
472*68330Seric	recognize itself as domain.net.  Add domain.net to
473*68330Seric	/etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or
474*68330Seric	add "Cw domain.net" to your configuration file.
47567898Seric
47667898Seric	IMPORTANT:  Be sure you kill and restart the sendmail daemon
47767898Seric	after you change the configuration file (for ANY change in
47867898Seric	the configuration, not just this one):
47967898Seric
48067898Seric		kill `head -1 /etc/sendmail.pid`
48167898Seric		sh -c "`tail -1 /etc/sendmail.pid`"
48267898Seric
48367898Seric	NOTA BENE:  kill -1 does not work!
48467892Seric----------------------------------------------------------------------
48566282Seric  * When I use sendmail V8 with a Sun config file I get lines like:
48666282Seric
48766282Seric	/etc/sendmail.cf: line 273: replacement $3 out of bounds
48866282Seric
48966282Seric    the line in question reads:
49066282Seric
49166282Seric	R$*<@$%y>$*		$1<@$2.LOCAL>$3			user@ether
49266282Seric
49366282Seric    what does this mean?  How do I fix it?
49466282Seric
495*68330Seric	V8 doesn't recognize the Sun "$%y" syntax, so as far as it is
496*68330Seric	concerned, there is only a $1 and a $2 (but no $3) in this
49766282Seric	line.  Read Rick McCarty's paper on "Converting Standard Sun
49866282Seric	Config Files to Sendmail Version 8", in the contrib directory
49966282Seric	(file "converting.sun.configs") on the sendmail distribution
50066282Seric	for a full discussion of how to do this.
50166282Seric----------------------------------------------------------------------
502*68330Seric  * When I use sendmail V8 on a Sun, I sometimes get lines like:
50366282Seric
504*68330Seric	/etc/sendmail.cf: line 445: bad ruleset 96 (50 max)
505*68330Seric
506*68330Seric    what does this mean?  How do I fix it?
507*68330Seric
508*68330Seric	You're somehow trying to start up the old Sun sendmail (or
509*68330Seric	sendmail.mx) with a sendmail V8 config file, which Sun's
510*68330Seric	sendmail doesn't like.  Check your /etc/rc.local, any
511*68330Seric	procedures that have been created to stop and re-start the
512*68330Seric	sendmail processes, etc....  Make sure that you've switched
513*68330Seric	everything over to using the new sendmail.  To keep this
514*68330Seric	problem from ever happening again, try the following:
515*68330Seric
516*68330Seric	    mv /usr/lib/sendmail /usr/lib/sendmail.old
517*68330Seric	    ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail
518*68330Seric	    mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old
519*68330Seric	    ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx
520*68330Seric	    chmod 0000 /usr/lib/sendmail.old
521*68330Seric	    chmod 0000 /usr/lib/sendmail.mx.old
522*68330Seric
523*68330Seric	Assuming you have installed sendmail V8 in /usr/local/lib.
524*68330Seric----------------------------------------------------------------------
525*68330Seric  * When I use sendmail V8 on an IBM RS/6000 running AIX, the system
526*68330Seric    resource controller always reports sendmail as "inoperative" even
527*68330Seric    though it is running.  What's wrong?
528*68330Seric
529*68330Seric	IBM's system resource controller is one of their "value
530*68330Seric	added" features to AIX -- it's not a Unix standard.  You'll
531*68330Seric	need to either redefine the subsystem to use signals (see
532*68330Seric	chssys(1)) or dump the entire subsystem and invoke sendmail
533*68330Seric	in /etc/rc.tcpip or some other boot script.
534*68330Seric----------------------------------------------------------------------
535*68330Seric  * When I use sendmail V8 on an Intel x86 machine running Linux, I
536*68330Seric    have some problems.  Specifically, I have....
537*68330Seric
538*68330Seric	The current versions of Linux are generally considered to be
539*68330Seric	great for hobbiests and anyone else who wants to learn Unix
540*68330Seric	inside and out, or wants to always have something to do, or
541*68330Seric	just wants a machine for themselves and not a whole bunch of
542*68330Seric	other users.
543*68330Seric
544*68330Seric	However, for those who want a system that will just sit in
545*68330Seric	the background and work without a fuss handling thousands of
546*68330Seric	mail messages a day for lots of different users, it's not
547*68330Seric	(yet) stable enough to fit the bill.
548*68330Seric
549*68330Seric	Unfortunately, there are no known shareware/freeware
550*68330Seric	implementations of any operating system that provides the
551*68330Seric	level of stability necessary to handle that kind of load.  If
552*68330Seric	you're wedded to the Intel x86 platform, you need to look at
553*68330Seric	commercial implementations of Unix such as Interactive,
554*68330Seric	UnixWare, Solaris, or BSDI's 386BSD.  Of the commercial
555*68330Seric	implementations, BSDI's 386BSD is the only one known to
556*68330Seric	currently ship with sendmail V8 and a recent version of BIND
557*68330Seric	pre-installed.  It is also the least expensive.
558*68330Seric----------------------------------------------------------------------
559*68330Seric  * When I use sendmail on an Intel x86 machine running OS/2, I have
560*68330Seric    some problems.  Specifically, I have....
561*68330Seric
562*68330Seric	The OS/2 port of sendmail is known to have left out huge
563*68330Seric	chunks of the code and functionality of even much older
564*68330Seric	versions of sendmail, in large part because the underlying OS
565*68330Seric	just doesn't have the necessary hooks to make it happen.
566*68330Seric	This port is so broken that we make no attempt to provide any
567*68330Seric	kind of support for it.  Try BSDI's 386BSD instead.
568*68330Seric----------------------------------------------------------------------
569*68330Seric  * I'm connected to the network via a SLIP/PPP link.  Sometimes my
570*68330Seric    sendmail process hangs (although it looks like part of the
571*68330Seric    message has been transfered).  Everything else works.  What's
572*68330Seric    wrong?
573*68330Seric
57466282Seric	Most likely, the problem isn't sendmail at all, but the low
575*68330Seric	level network connection.  It's important that the MTU
576*68330Seric	(Maximum Transfer Unit) for the SLIP connection be set
577*68330Seric	properly at both ends.  If they disagree, large packets will
578*68330Seric	be trashed and the connection will hang.
57966282Seric----------------------------------------------------------------------
58066282Seric  * I just upgraded to 8.x and suddenly I'm getting messages in my
58166282Seric    syslog of the form "collect: I/O error on connection".  What is
58266282Seric    going wrong?
58366282Seric
584*68330Seric	Nothing.  This is just a diagnosis of a condition that had
585*68330Seric	not been diagnosed before.  If you are getting a lot of these
586*68330Seric	from a single host, there is probably some incompatibility
587*68330Seric	between 8.x and that host.  If you get a lot of them in
588*68330Seric	general, you may have network problems that are causing
589*68330Seric	connections to get reset.
59066282Seric----------------------------------------------------------------------
59167892Seric  * I just upgraded to 8.x and suddenly connections to the SMTP port
59267892Seric    take a long time.  What is going wrong?
59367892Seric
594*68330Seric	It's probably something weird in your TCP implementation that
59567892Seric	makes the IDENT code act oddly.  On most systems V8 tries to
59667892Seric	do a ``callback'' to the connecting host to get a validated
597*68330Seric	user name (see RFC 1413 for detail).  If the connecting host
598*68330Seric	does not support such a service it will normally fail quickly
599*68330Seric	with "Connection refused", but certain kinds of packet
600*68330Seric	filters and certain TCP implementations just time out.
60167892Seric
60267892Seric	To test this, set the IDENT timeout to zero using
60367892Seric	``OrIdent=0'' in the configuration file.  This will
60467892Seric	completely disable all use of the IDENT protocol.
60567892Seric
60667892Seric	Another possible problem is that you have your name server
607*68330Seric	and/or resolver configured improperly.  Make sure that all
608*68330Seric	"nameserver" entries in /etc/resolv.conf point to functional
609*68330Seric	servers.  If you are running your own server make certain
610*68330Seric	that all the servers listed in your root cache (usually
611*68330Seric	called something like "/var/namedb/root.cache"; see your
61267892Seric	/etc/named.boot file to get your value) are up to date.
61367892Seric	Either of these can cause long delays.
61467892Seric----------------------------------------------------------------------
61567892Seric  * I just upgraded to 8.x and suddenly I get errors such as ``mail:
61667892Seric    options must follow recipients.''  What is going wrong?
61767892Seric
61867892Seric	You need OSTYPE(systype) in your .mc file -- otherwise the
61967892Seric	configurations use a default that probably disagrees with
62067892Seric	your local mail system.  See cf/README for details.
62167892Seric----------------------------------------------------------------------
62266282Seric  * Under V8, the "From " header gets mysteriously munged when I send
62366282Seric    to an alias.
62466282Seric
625*68330Seric	``It's not a bug, it's a feature.''  This happens when you
626*68330Seric	have a "owner-list" alias and you send to "list".  V8
627*68330Seric	propagates the owner information into the envelope sender
628*68330Seric	field (which appears as the "From " header on UNIX mail or as
629*68330Seric	the Return-Path: header) so that downstream errors are
630*68330Seric	properly returned to the mailing list owner instead of to the
631*68330Seric	sender.  In order to make this appear as sensible as possible
632*68330Seric	to end users, I recommend making the owner point to a
633*68330Seric	"request" address -- for example:
63466282Seric
63566282Seric		list:		:include:/path/name/list.list
63666282Seric		owner-list:	list-request
63766282Seric		list-request:	eric
63866282Seric
639*68330Seric	This will make message sent to "list" come out as being "From
640*68330Seric	list-request" instead of "From eric".
64166282Seric----------------------------------------------------------------------
642*68330Seric  * I am trying to use MASQUERADE_AS (or the user database) to
643*68330Seric    rewrite from addresses, and although it works in the From: header
644*68330Seric    line, it doesn't work in the envelope (e.g., the "From " line).
645*68330Seric
646*68330Seric	Believe it or not, this is intentional.  The interpretation
647*68330Seric	of the standards by the V8 development group was that this
648*68330Seric	was an inappropriate rewriting, and that if the rewriting
649*68330Seric	were incorrect at least the envelope would contain a valid
650*68330Seric	return address.  Other people have since described scenarios
651*68330Seric	where the envelope cannot be correct without this rewriting,
652*68330Seric	so 8.7 will have an option to rewrite both header and
653*68330Seric	envelope.
654*68330Seric----------------------------------------------------------------------
65566285Seric  * I want to run Sendmail version 8 on my DEC system, but you don't
65666285Seric    have MAIL11V3 support in sendmail.  How do I handle this?
65766285Seric
658*68330Seric	Get Paul Vixie's reimplementation of the mail11 protocol from
659*68330Seric	gatekeeper.dec.com in /pub/DEC/gwtools.
660*68330Seric
661*68330Seric	Rumour has it that he will be fully integrating into sendmail
662*68330Seric	V8 what little is left of IDA sendmail that is not handled
663*68330Seric	(or handled as well) by V8.  No additional information on
664*68330Seric	this project is currently available.
66566285Seric----------------------------------------------------------------------
66668069Seric  * Messages seem to disappear from my queue unsent.  When I look in
667*68330Seric    the queue directory I see that they have been renamed from qf* to
668*68330Seric    Qf*, and sendmail doesn't see these.
66968069Seric
67068069Seric	If you look closely you should find that the Qf files are
67168069Seric	owned by users other than root.  Since sendmail runs as root
67268069Seric	it refuses to believe information in non-root-owned qf files,
673*68330Seric	and it renames them to Qf to get them out of the way and make
674*68330Seric	it easy for you to find.  The usual cause of this is
67568069Seric	twofold:  first, you have the queue directory world writable
67668069Seric	(which is probably a mistake -- this opens up other security
67768069Seric	problems) and someone is calling sendmail with an "unsafe"
67868069Seric	flag, usually a -o flag that sets an option that could
67968069Seric	compromise security.  When sendmail sees this it gives up
68068069Seric	setuid root permissions.
68168069Seric
682*68330Seric	The usual solution is to not use the problematic flags.  If
683*68330Seric	you must use them, you have to write a special queue
68468069Seric	directory and have them processed by the same uid that
68568069Seric	submitted the job in the first place.
68668069Seric----------------------------------------------------------------------
687*68330Seric@(#)FAQ	8.11	(Berkeley)	02/14/95
688*68330SericSend updates to sendmail@CS.Berkeley.EDU.
689