Fix sendmail_flags, long ago it was imported from /etc/netstart

[unix-history] / usr.sbin / sendmail / FAQ

			    Sendmail Version 8
			Frequently Asked Questions
			     VERY EARLY DRAFT
		       Last Update: October 18, 1993


This FAQ is specific to Version 8 of sendmail.

----------------------------------------------------------------------
  * What are the differences between Version 8 and other versions?

	See CHANGES-R5-R8 in the anonymous FTP directory.
----------------------------------------------------------------------
  * What happened to sendmail 6.x and 7.x?

	When I released a new version of sendmail, I changed it to
	Release 6.  Development continued in that tree until 4.4BSD
	was released, when everything on the 4.4 tape was set to be
	version 8.1.  Version 7.x never existed.
----------------------------------------------------------------------
  * Where can I get Version 8?

	Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail.
----------------------------------------------------------------------
  * 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".  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 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
----------------------------------------------------------------------
  * 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 release.
----------------------------------------------------------------------
  * What books are available describing sendmail?

	There are currently no books available devoted to sendmail.
	However, there are several books that have sendmail chapters.

	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.

|	At least two books are due out "soon":

	Costales, Allman, and Rickert, _Sendmail_.  O'Reilly &
|		Associates (to appear 11/93).
	Avolio & Vixie, _Sendmail Theory and Practice_.  Digital
|		Press (release date unknown).
----------------------------------------------------------------------
  * 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 they will get most of the other person's
	email.

	So called "full names" are just 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.

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

	Finger services should be as fuzzy as possible.  Mail services
	should be unique.
----------------------------------------------------------------------
  * 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.
----------------------------------------------------------------------
  * 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.
----------------------------------------------------------------------
  * I'm connected to the network via a SLIP link.  Sometimes my sendmail
    process hangs (although it looks like part of the message has been
    transfered).  Everything else works.  What's wrong?

	Most likely, the problem isn't sendmail at all, but the low
	level network connection.  It's important that the MTU (Maximum
	Transfer Unit) for the SLIP connection be set properly at both
	ends.  If they disagree, large packets will be trashed and
	the connection will hang.
----------------------------------------------------------------------
+ * How can I get sendmail to deliver local mail to $HOME/.mail
+   instead of into /usr/spool/mail (or /usr/mail)?
+
+	This is a local mailer issue, not a sendmail issue.  Either
+	modify your local mailer (source code will be required) or
+	change the program called in the "local" mailer configuration
+	description to be a new program that does this local delivery.
+	I understand that "procmail" works well, although I haven't
+	used it myself.
----------------------------------------------------------------------
+ * Under V8, the "From " header gets mysteriously munged when I send
+   to an alias.
+
+	``It's not a bug, it's a feature.''  This happens when you have
+	a "owner-list" alias and you send to "list".  V8 propogates the
+	owner information into the envelope sender field (which appears
+	as the "From " header on UNIX mail or as the Return-Path: header)
+	so that downstream errors are properly returned to the mailing
+	list owner instead of to the sender.  In order to make this
+	appear as sensible as possible to end users, I recommend making
+	the owner point to a "request" address -- for example:
+
+		list:		:include:/path/name/list.list
+		owner-list:	list-request
+		list-request:	eric
+
+	This will make message sent to "list" come out as being
+	"From list-request" instead of "From eric".
----------------------------------------------------------------------