summaryrefslogtreecommitdiff
path: root/usr.sbin/sendmail/FAQ
blob: cc27e50805fd2cc9bfdb21e17276d1889fa46c8e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
Newsgroups: comp.mail.sendmail,comp.mail.misc,comp.mail.smail,comp.answers,news.answers
Subject: comp.mail.sendmail Frequently Asked Questions (FAQ)
From: brad@birch.ims.disa.mil (Brad Knowles)
Followup-to: comp.mail.sendmail
Summary: This posting contains a list of Frequently Asked Questions
    (and their answers) about the program "sendmail", distributed
    with many versions of Unix (and available for some other
    operating systems).  This FAQ is shared between
    comp.mail.sendmail and the Sendmail V8 distribution.  It should
    be read by anyone who wishes to post to comp.mail.sendmail, or
    anyone having questions about the newsgroup itself.

Archive-name: mail/sendmail-faq
Posting-Frequency: monthly (first Monday)


[The most recent copy of this document can be obtained via anonymous
FTP from rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
If you do not have access to anonymous FTP, you can retrieve it by
sending email to mail-server@rtfm.mit.edu with the command "send
usenet/news.answers/mail/sendmail-faq" in the message.]



			    Sendmail Version 8
			Frequently Asked Questions
		         Last updated 9/17/95


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

This is also the official FAQ for the Usenet newsgroup
comp.mail.sendmail.

======================================================================
BEFORE YOU GO ANY FURTHER
======================================================================

  * What do you wish everyone would do before sending you mail or
    posting to comp.mail.sendmail?

	Read this FAQ completely.  Read src/READ_ME and cf/README
	completely.  Read the books written to help with common
	problems such as compilation and installation, configuration,
	security issues, etc....  Ask themselves if their question
	hasn't already been answered.
----------------------------------------------------------------------
  * How can I be sure if this is the right place to look for answers
    to my questions?

	1. Do you know, for a fact, that the question is related to
	   sendmail V8?

	2. Do you know, for a fact, that the question is related to an
	   older version of sendmail?

	3. Is the question about a sendmail-like program (e.g., Smail,
	   Zmailer, MMDF, etc...)?

	4. Is the question about an SMTP Gateway product for a LAN
	   mail package (e.g., cc:Mail, MS-Mail, WordPerfect
	   Office/GroupWise, etc...)?

	If you answered "yes" to the question #1, then this is the
	right place.

	If you answered "yes" to questions #2 or #3, then you should
	seriously consider upgrading to the most recent version of
	sendmail V8.

	For question #2, If you're going to continue using an older
	version of sendmail, you may not find much help and will
	probably get some responses that amount to "Get V8".
	Otherwise, this is probably the best place to look for
	answers.

	If you answered "yes" to question #3 and are not going to
	upgrade to sendmail V8, then this is probably not the right
	place to look.

	If you answered "yes" to question #4, then this is almost
	certainly not the right place to look.

	For questions #3 and #4, try looking around elsewhere in the
	"comp.mail.*" hierarchy for a more appropriate newsgroup.
	For example, you might want to try posting to comp.mail.misc
	or comp.mail.smail.

	If you couldn't answer "yes" to any of the above questions,
	then you're DEFINITELY in the wrong place.  For the sake of
	your sanity and ego, not to mention avoiding the waste of
	your time and ours, try asking your System or E-Mail
	Administrator(s) before you post any questions publicly.
----------------------------------------------------------------------
  * Where can I find the latest version of this FAQ?

	It is included in the most recent Version 8 distribution of
	sendmail (described below), as well as via anonymous FTP from
	rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
	If you do not have access to anonymous FTP, you can retrieve
	it by sending email to mail-server@rtfm.mit.edu with the
	command "send usenet/news.answers/mail/sendmail-faq" in the
	message.
----------------------------------------------------------------------
  * I don't have access to Usenet news.  Can I still get access to
    comp.mail.sendmail?

	Yes.  Send email to mxt@dl.ac.uk with the command "sub
	comp-news.comp.mail.sendmail <full-US-ordered-email-address>"
	in the message.

	E-mail you want posted on comp.mail.sendmail should be sent
	to comp-mail-sendmail@dl.ac.uk
----------------------------------------------------------------------
  * I have sendmail-related DNS questions.  Where should I ask them?

	Depending on how deeply they get into the DNS, they can be
	asked here.  However, you'll probably be told that you should
	send them to the Info-BIND mailing list (if the question is
	specific to that program) or to the Usenet newsgroup
	comp.protocols.tcp-ip.domains (DNS in general).
----------------------------------------------------------------------
  * How do I subscribe to either of these?

	For comp.protocols.tcp-ip.domains, you have to be on Usenet.
	They don't have a news-to-mail gateway yet.

	For the Info-BIND mailing list, send email to
	bind-request@uunet.uu.net with the command "subscribe" in the
	message.  Submissions should be sent to bind@uunet.uu.net

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

  * 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 a new (Alpha/Beta) version of sendmail was released, it
	was changed 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).

	For details on sendmail-related DNS issues, consult:

	    Liu and Albitz, _DNS and BIND_.  O'Reilly & Associates.

	For details on UUCP, see:

	    O'Reilly and Todino, _Managing UUCP and Usenet_.
		O'Reilly & Associates.

======================================================================
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 for locations; for example, on FTP.UU.NET the files
	/system/unix/bsd-sources/share/tmac/me/strip/sed and
	/system/unix/bsd-sources/share/tmac/* are what you need).

	This macro set is also included 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, Eric Allman is currently
	(to the best of our knowledge) the only ``Allman'' at
	Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to
	him.  But if another Allman ever appears, this address could
	suddenly become ambiguous.  He's 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.

	See RFCs 1535-1537 for more detail and other related (or
	common) problems.
----------------------------------------------------------------------
  * How can I get sendmail to process messages sent to an account and
    send the results back to the originator?

	This is a local mailer issue, not a sendmail issue.
	Depending on what you're doing, look at procmail (mentioned
	again below), ftpmail, or Majordomo.

	Check your local archie server to see what machine(s) nearest
	you have the most recent versions of these programs.
----------------------------------------------------------------------
  * How can I get sendmail to deliver local mail to $HOME/.mail
    instead of into /usr/spool/mail (or /usr/mail)?

	Again, 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.  One program that is capable of doing this is
	"procmail", although there are probably many others as well.

	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 in /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 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 across 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 compile 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.
----------------------------------------------------------------------
  * When I use sendmail V8 on a Sun, I sometimes get lines like:

	/etc/sendmail.cf: line 445: bad ruleset 96 (50 max)

    what does this mean?  How do I fix it?

	You're somehow trying to start up the old Sun sendmail (or
	sendmail.mx) with a sendmail V8 config file, which Sun's
	sendmail doesn't like.  Check your /etc/rc.local, any
	procedures that have been created to stop and re-start the
	sendmail processes, etc....  Make sure that you've switched
	everything over to using the new sendmail.  To keep this
	problem from ever happening again, try the following:

	    mv /usr/lib/sendmail /usr/lib/sendmail.old
	    ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail
	    mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old
	    ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx
	    chmod 0000 /usr/lib/sendmail.old
	    chmod 0000 /usr/lib/sendmail.mx.old

	Assuming you have installed sendmail V8 in /usr/local/lib.
----------------------------------------------------------------------
  * When I use sendmail V8 on an IBM RS/6000 running AIX, the system
    resource controller always reports sendmail as "inoperative" even
    though it is running.  What's wrong?

	IBM's system resource controller is one of their "value
	added" features to AIX -- it's not a Unix standard.  You'll
	need to either redefine the subsystem to use signals (see
	chssys(1)) or dump the entire subsystem and invoke sendmail
	in /etc/rc.tcpip or some other boot script.
----------------------------------------------------------------------
  * When I use sendmail V8 on an Intel x86 machine running Linux, I
    have some problems.  Specifically, I have....

	The current versions of Linux are generally considered to be
	great for hobbyists and anyone else who wants to learn Unix
	inside and out, or wants to always have something to do, or
	wants a machine for light-duty mostly personal use and not
	high-volume multi-user purposes.

	However, for those who want a system that will just sit in
	the background and work without a fuss handling thousands of
	mail messages a day for lots of different users, it's not
	(yet) stable enough to fit the bill.

	Unfortunately, there are no known shareware/freeware
	implementations of any operating system that provides the
	level of stability necessary to handle that kind of load
	(i.e., there are no free lunches).

	If you're wedded to the Intel x86 platform and want to run
	sendmail, we suggest you look at commercial implementations
	of Unix such as Interactive, UnixWare, Solaris, or BSD/386
	(just a sample of the dozens of different versions of Unix
	for Intel x86).

	Of all known vendor supported versions of Unix for Intel x86,
	BSDI's BSD/386 is least expensive and the only one known to
	currently ship with sendmail V8 pre-installed.  Since sendmail
	V8 is continuing to be developed at UC Berkeley, and BSD/386
	is a full BSD 4.4 implementation, this is obviously be the most
	"native" sendmail V8 environment.
----------------------------------------------------------------------
  * When I use sendmail on an Intel x86 machine running OS/2, I have
    some problems.  Specifically, I have....

	The OS/2 port of sendmail is known to have left out huge
	chunks of the code and functionality of even much older
	versions of sendmail, in large part because the underlying OS
	just doesn't have the necessary hooks to make it happen.
	This port is so broken that we make no attempt to provide any
	kind of support for it.  Try BSDI's BSD/386 instead.
----------------------------------------------------------------------
  * I'm connected to the network via a SLIP/PPP 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 now when my users try to forward their
    mail to a program they get an "illegal shell" message and their
    mail is not delivered.  What's wrong?

	In order for people to be able to run a program from their
	.forward file, 8.x insists that their shell (that is, the
	shell listed for that user in the passwd entry) be a "valid"
	shell, meaning a shell listed in /etc/shells.  If /etc/shells
	does not exist, a default list is used, typically consisting
	of /bin/sh and /bin/csh.

	This is to support environments that may have NFS-shared
	directories mounted on machines on which users do not have
	login permission.  For example, many people make their
	file server inaccessible for performance or security
	reasons; although users have directories, their shell on
	the server is /usr/local/etc/nologin or some such.  If you
	allowed them to run programs anyway you might as well let
	them log in.

	If you are willing to let users run programs from their
	.forward file even though they cannot telnet or rsh in (as
	might be reasonable if you run smrsh to control the list of
	programs they can run) then add the line

		/SENDMAIL/ANY/SHELL/

	to /etc/shells.  This must be typed exactly as indicated,
	in caps, with the trailing slash.  NOTA BENE:  DO NOT
	list /usr/local/etc/nologin in /etc/shells -- this will
	open up other security problems.
----------------------------------------------------------------------
  * 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 weird 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 detail).  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 ``unknown
    mailer error 5 -- mail: options MUST PRECEDE 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
	propagates 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 am trying to use MASQUERADE_AS (or the user database) to
    rewrite from addresses, and although it works in the From: header
    line, it doesn't work in the envelope (e.g., the "From " line).

	Believe it or not, this is intentional.  The interpretation
	of the standards by the V8 development group was that this
	was an inappropriate rewriting, and that if the rewriting
	were incorrect at least the envelope would contain a valid
	return address.  Other people have since described scenarios
	where the envelope cannot be correct without this rewriting,
	so 8.7 will have an option to rewrite both header and
	envelope.
----------------------------------------------------------------------
  * 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.

	Rumour has it that he will be fully integrating into sendmail
	V8 what little is left of IDA sendmail that is not handled
	(or handled as well) by V8.  No additional information on
	this project is currently available.
----------------------------------------------------------------------
  * 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.
----------------------------------------------------------------------
@(#)FAQ	8.16	(Berkeley)	9/17/95
Send updates to sendmail@sendmail.ORG.