Posted-By: auto-faq 3.1.1.2
Archive-name: mail/sendmail-faq/part1


			  comp.mail.sendmail
		    Frequently Asked Questions (FAQ)
		      Last updated October 18, 1996

	   Copyright 1996, by Brad Knowles, all rights reserved


This FAQ is edited and maintained by Brad Knowles <brad@etext.org>.
The official archive for all FAQs posted to <news:news.answers> is
<ftp://rtfm.mit.edu/pub/usenet/news.answers/>, with many known
mirrors.  On this site, the latest version of this FAQ can be found in
<ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq/>.
Since this server tends to be extremely busy, as an alternative, you
might want to try using <http://www.imc.org/sendmail-faq/> instead.

If you don't have access to FTP or WWW, this FAQ can be retrieved by
sending Internet email to <mail-server@rtfm.mit.edu> with an empty
subject line (it gets ignored) and the command "send
usenet/news.answers/mail/sendmail-faq/part*" as the body of the
message (omitting the quotes, of course).

As an alternative, you might want to try sending Internet email to
<info@imc.org> with an empty subject line (it gets ignored) and "send
sendmail-faq/part*" as the body of the body of the message (again,
omitting the quotes).

Additional alternative access methods are detailed within.


This FAQ is in RFC 1153 digest format.  The "Date:" field of each
entry represents the date of the last update made to that entry.


This FAQ has now been split into two parts, to try and make it easier
to pass through older or less capable news or mail gateways.


The intent is to ultimately make this document web-native (in that all
original work is done in HTML), and have automated processes extract
the ASCII information and automatically post that to
comp.mail.sendmail as appropriate.  In the meanwhile, all
pseudo-HTMLized versions of this FAQ are considered unsupported.  We
cannot be held responsible for what someone else's program does to
this document in an attempt to make it more web-friendly.


Comments/updates should be sent to <sendmail-faq@etext.org>.

----------------------------------------------------------------------

Date: August 19, 1996
Subject: Table of Contents

Table of Contents
=================

    PART ONE
    ========

    0.  TO DO

    1.  COPYRIGHT NOTICE / REDISTRIBUTION REQUIREMENTS

    2.  INTRODUCTION / MISCELLANEOUS
	2.1   What is this newsgroup?
	2.2   What is the scope of this FAQ?
	2.3   Where can I find the latest version of this FAQ?
	2.4   How do I access comp.mail.sendmail by email?
	2.5   Where can I ask email-related DNS questions?
	2.6   How can I subscribe to these newsgroups?
	2.7   Which version of sendmail should I run?
	2.8   What is the latest release of sendmail?
	2.9   Where can I find it?
	2.10  What are the differences between Version 8 and other
		versions?
	2.11  What's the best platform for running sendmail?
	2.12  What is BIND and where can I get the latest version?
	2.13  What is smrsh and where can I get it?
	2.14  What is smap and where can I get it?
	2.15  What is TCP-Wrappers and where can I get it?
	2.16  Why won't db 1.85 build for my SGI running Irix >= 5.2?
	2.17  What is makemap and where can I get it?

    3.  VERSION 8 SPECIFIC ISSUES
	3.1   How do I make all my addresses appear to be from a single
		host?
	3.2   How do I rewrite my "From:" lines to read
		``First_Last@My.Domain''?
	3.3   So what was the user database feature intended for?
	3.4   Why are you so hostile to using full names for email
		addresses?
	3.5   Where do I find this user database (UserDB) code?
	3.6   How do I get the user database to work with Pine or
		with FEATURE(always_add_domain)?
	3.7   How do I manage several (virtual) domains?
	3.8   There are four UUCP mailers listed in the configuration
		files.  Which one should I use?
	3.9   How do I fix "undefined symbol inet_aton" and "undefined
		symbol _strerror" messages?
	3.10  How do I solve "collect: I/O error on connection" errors?
	3.11  Why can't my users forward their mail to a program?
	3.12  Why do connections to the SMTP port take such a long time?
	3.13  Why do I get "unknown mailer error 5 -- mail: options
		MUST PRECEDE recipients" errors?
	3.14  Why does sendmail 8.7.y panic my SunOS 4.1.3 box?
	3.15  Why does the "From " header gets mysteriously munged
		when I send to an alias?
	3.16  Why doesn't MASQUERADE_AS (or the user database) work
		for envelope addresses as well as header addresses?
	3.17  How do I run version 8 sendmail and support the MAIL11V3
		protocol?
	3.18  Why do messages disappear from my queue unsent?
	3.19  When is sendmail going to support RFC 1522 MIME header
	      encoding?


    PART TWO
    ========

    4.  GENERAL SENDMAIL ISSUES
	4.1   Should I use a wildcard MX for my domain?
	4.2   How can I set up an auto-responder?
	4.3   How can I get sendmail to deliver local mail to
		$HOME/.mail instead of into /usr/spool/mail (or
		/usr/mail)?
	4.4   Why does it deliver the mail interactively when I'm
		trying to get it to go into queue only mode?
	4.5   How can I solve "config error: mail loops back to
		myself" messages?
	4.6   Why does my sendmail process sometimes hang when
		connecting over a SLIP/PPP link?
	4.7   How can I summarize the statistics generated by
		sendmail in the syslog?
        4.8   How can I check my sendmail.cf to ensure that it's
                re-writing addresses correctly?
	4.9   What is procmail, and where can I get it?

    5.  VENDOR/OS SPECIFIC SENDMAIL ISSUES
	5.1   Sun Microsystems SunOS/Solaris 1.x/2.x
	    5.1.1  How can I solve "line 273: replacement $3 out of
		    bounds" errors?
	    5.1.2  How can I solve "line 445: bad ruleset 96 (50 max)"
		    errors?
	    5.1.3  Why does version 8 sendmail (< 8.7.5) sometimes
		    hang under Solaris 2.5?
	5.2   IBM AIX
	    5.2.1  The system resource controller always reports
		    sendmail as "inoperative".  What's wrong?
	    5.2.2  Why can't I use AIX to get email to some sites?
	    5.2.3  Why can't I get sendmail 8.7.1 to use MX records
		    with AIX 3.2.5?

    6.  ADDITIONAL INFORMATION SOURCES (RFC 1807 bibliography format)
	6.1   Reference material devoted exlusively to sendmail
	6.2   Reference material with chapters or sections on sendmail
	6.3   Reference material on subjects related to sendmail
	6.4   World-wide web index pages on sendmail
	6.5   World-wide web index pages Internet email in general
	6.6   Online tutorials for sendmail
	6.7   Online archives of mailing lists and Usenet newsgroups,
		relating to Internet email

    7.  THANKS!

------------------------------

Date: May 23, 1996
Subject:  Q0 -- TO DO list

* Make the FAQ web-native by writing directly in HTML
* Index
* Additional net resources (web pages, anonymous ftp sites, etc...)
* Larger, more clearly written annotated bibliography (including RFCs
    and comments/corrections for books specific to sendmail)
* Reorganize by platform/version of sendmail (All Sun questions in one
    section, all AIX questions in another, etc...)

------------------------------

Date: May 28, 1996
Subject:  Q1 -- COPYRIGHT NOTICE / REDISTRIBUTION REQUIREMENTS

    The entire contents of this document are copyright 1996 by Brad
Knowles, all rights reserved.

    This document may be freely distributed for non-profit purposes
(including, but not limited to: posting to mailing lists, Usenet
newsgroups, and world-wide-web pages; inclusion on CD-ROM or other
distribution media; and insertion into text retrieval systems), so
long as it is the latest version available at the time, all parts are
distributed together, and it is kept completely intact without
editing, changes, deletions, or additions.  Non-profit redistribution
in accordance with these guidelines does not require contact with or
approval from the copyright holder.

    Redistribution of this document for profit without express prior
permission is not allowed.  At the very least, expect to provide the
copyright holder a free copy of the product (exactly as it would be
sold to customers, all distribution media intact), or a percentage of
the gross revenue from said product and sufficient proof that the
integrity and completeness requirements set for non-profit
distribution will be met.


    In the event that the copyright holder discovers a redistributed
version that is not in compliance with the above requirements, he will
make a good-faith effort to get it corrected or removed, and failing
that, at least note its deprecated status in a new version.  Legal
action will likely be taken against redistribution for profit that
is not in compliance with the above requirements.

------------------------------

Date: May 28, 1996
Subject:  Q2.1 -- What is this newsgroup?

    The Usenet newsgroup <news:comp.mail.sendmail> is dedicated to the
discussion of the program named "sendmail" in all its various forms.
It is most commonly found on computers running a flavor of the
Operating System known as Unix, or derived from Unix.

    This program has been ported to other OSes, but those versions
have typically been ported by a particular vendor and are considered
proprietary.  There are many versions of sendmail, but the original
author (Eric Allman) is continuing development on a particular version
typically referred to as "Version Eight" or sometimes just "V8".  This
is considered by many to be the One True Version.  This is also the
version that this FAQ is centered around.


    If you have a question that amounts to "How do I send mail to my
friend?", then you're in the wrong newsgroup.  You should first check
with your System or E-Mail Administrator(s), BBS SysOp(s), etc...
before you post your question publicly, since the answer will likely
be very highly dependant on what software and hardware you have.  You
also don't want to embarass yourself publicly, nor do you want to
annoy the kinds of people who are likely to be the counterparts of
your System or E-Mail Administrator(s), BBS SysOp(s), etc....  If
asking them doesn't do you any good, make sure you read this FAQ and
the other mail-related FAQs at the archive sites listed below.

    If you have a question about another program similar to sendmail
(technically referred to as an "SMTP MTA"), an SMTP Gateway package,
or a LAN email package, then you should see if there is another group
in the <news:comp.mail> hierarchy that more closely matches the
particular program you want to ask a question about.  For example, the
SMTP MTA known as Smail has <news:comp.mail.smail> dedicated to it.
The Mail User Agent (MUA) Eudora has two newsgroups dedicated to it
(<news:comp.mail.eudora.mac> and <news:comp.mail.eudora.ms-windows>),
depending on which hardware platform you use.  If there isn't a more
appropriate newsgroup, try <news:comp.mail.misc>.  Again, make sure
your question isn't already addressed in one of the mail-related
FAQs or other available documentation.  See the IMC website (more
info below) for a good list of mail-related FAQs.


    If you have a question about an older or vendor-proprietary
version of sendmail, be prepared for a lot of answers that amount to
"Get V8".  Version 8 isn't a panacea, but it does solve many problems
known to plague previous versions, as well as having many new features
that make it much easier to administer large or complex sites.  In
many cases, it makes at least possible what was previously virtually
impossible, and relatively easy the previously difficult.


    There are, of course, many alternative programs that have sprung
up in an attempt to answer one or another weakness or perceived fault
of sendmail, but so far, none of them have had the kind of success it
would require to unseat it as the de facto standard program for
sending Internet mail.  Obviously, this forum should not be used to
discuss the merits of any of the alternative programs versus sendmail.
These kinds of discussions should be taken to <news:comp.mail.misc>,
or you should agitate to get a new newsgroup or newsgroup hierarchy
created where that sort of thing is acceptable (or even the norm, such
as a <news:comp.mail.advocacy> or <news:comp.mail.mta.advocacy>
newsgroup).

------------------------------

Date: July 9, 1996
Subject:  Q2.2 -- What is the scope of this FAQ?

    This FAQ is strongly centered around version 8 sendmail, for many
reasons.  First and foremost, this is the area of most interest on the
part of the maintainer of this FAQ.  Secondly, version 8 is where most
of the additional development is being concentrated.  Version 8
sendmail is also the best documented of all SMTP MTAs, by virtue of
the book by Bryan Costales (see entry
sendmail-faq//book/ISBN/1-56592-056-2 in Q6.1).

    Other versions of sendmail get mentioned in passing, and some
interesting interactions between version 8 and various OSes is also
covered.

    This FAQ is aimed primarily at the experienced Unix System
Administrator/Postmaster/DNS Domain Administrator.  If you're looking
for introductory texts, see the references in Q6.1.


    Where I've provided URLs, I've generally tried to keep them
exactly as they should be entered, without line breaks or anything
else.  This may make them or the surrounding text ugly, but hopefully
they'll be easier to cut-and-paste, or just click on once I've got an
HTMLized version.  However, this has not been possible in the
bibliography section, since I'm trying to adhere to RFC 1807
guidelines, and they explicitly require lines to be no longer than 79
characters.  In those cases, I've tried to break the lines at
relatively obvious and innocuous places.

------------------------------

Date: July 9, 1996
Subject:  Q2.3 -- Where can I find the latest version of this FAQ?

    I post changes as they occur to my sendmail FAQ support page at
<http://www.his.com/pub/brad/sendmail/>.

    The ASCII text of my private version can be found at
<ftp://ftp.his.com/pub/brad/sendmail/sendmail-faq/part*>, while the
latest "single part" version before the split can be found at
<ftp://ftp.his.com/pub/brad/sendmail/sendmail-faq/old>.  I don't have
an HTMLized version yet, but when I do, I will put in a link to it
from my support page as well as updating this document.


    The official version (as posted to <news:news.answers>) is in
<ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq/>.

    The Internet Mail Consortium <http://www.imc.org> maintains an
archive of email related FAQs and many other documents.  On their
site, the latest version of this FAQ can be found in
<http://www.imc.org/sendmail-faq/>.

    Unfortunately, the parser for the Ohio State semi-official
pseudo-HTMLized version tends to misinterpret the way I provide URLs,
so I no longer support it or provide the URL for this FAQ at that
site.



    If you don't have access to FTP or WWW, this FAQ can be retrieved
by sending Internet email to <mail-server@rtfm.mit.edu> with an empty
subject line (it gets ignored) and the command "send
usenet/news.answers/mail/sendmail-faq/part*" as the body of the
message (omitting the quotes, of course).

    Since this server tends to be extremely busy, as an alternative,
you might want to try sending Internet email to <info@imc.org> with an
empty subject line (it gets ignored) and "send sendmail-faq/part*" as
the body of the body of the message (again, omitting the quotes).


    Well known mirrors for the FAQs archived at rtfm.mit.edu can be
found at:

    Continent	URL
    ---------	-------------------------------------------
    North	<ftp://mirrors.aol.com/pub/rtfm/usenet/>
    America	<ftp://ftp.uu.net/usenet/news.answers/>
		<ftp://ftp.seas.gwu.edu/pub/rtfm/>
    Europe	<ftp://ftp.uni-paderborn.de/pub/FAQ/>
		<ftp://ftp.Germany.EU.net/pub/newsarchive/news.answers/>
		<ftp://ftp.sunet.se/pub/usenet/>
		<http://www.cs.ruu.nl/cgi-bin/faqwais/>
		<http://www.lib.ox.ac.uk/internet/news/faq/by_group.index.html>
    Asia	<ftp://nctuccca.edu.tw/USENET/FAQ/>
		<ftp://hwarang.postech.ac.kr/pub/usenet/news.answers/>
		<ftp://ftp.hk.super.net/mirror/faqs/>
    Australia	<ftp://ftp.info.au/usenet/FAQs/>



    Additional information on how to get access to various Internet
resources by email can be found in Bob Rankin's Internet-by-Email FAQ,
<ftp://rtfm.mit.edu/pub/usenet/news.answers/internet-services/access-via-email>.

    To get the latest edition of this document sent to you by return
email, send a message to one of these addresses:

	To: mail-server@rtfm.mit.edu (for US, Canada & South America)
	Enter only this line in the BODY of the note:
	    send usenet/news.answers/internet-services/access-via-email

	To: mailbase@mailbase.ac.uk (for Europe, Asia, etc.)
	Enter only this line in the BODY of the note:
	    send lis-iis e-access-inet.txt

------------------------------

Date: March 23, 1996
Subject:  Q2.4 -- How do I access comp.mail.sendmail by email?

    Send email to <mxt@dl.ac.uk> with the command "sub
comp-news.comp.mail.sendmail <full-US-ordered-email-address>" as the
body of the message (with your correct address in placed of the
"full-US-ordered-email-address", and omitting the double quotes in all
cases of this example).

    E-mail you want posted on comp.mail.sendmail should be sent to
<comp-mail-sendmail@dl.ac.uk>

------------------------------

Date: March 23, 1996
Subject:  Q2.5 -- Where can I ask email-related DNS questions?

    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 Usenet newsgroup <news:comp.protocols.tcp-ip.domains> (DNS in
general) or to the Info-BIND mailing list (if the question is specific
to that program).

------------------------------

Date: May 23, 1996
Subject:  Q2.6 -- How can I subscribe to these?

    For <news:comp.protocols.tcp-ip.domains>, you have to be on
Usenet.  They don't have a news-to-mail gateway yet (I'm working on
this), but they do have a FAQ, and it can be found at
<ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ>.

    Questions from all levels of experience can be found on this
newsgroup (as well as people to answer them), so don't be shy about
asking a question you think may be too simple.


    For the Info-BIND mailing list, send email to
<bind-request@vix.com> with and empty subject (it gets ignored) and
the command "subscribe" as the body of the message.  Submissions
should be sent to <bind@vix.com>.

    Note that this list is now moderated, and anything you post to it
may get material added, deleted, or changed by the moderator.  He
reserves the right to reject any postings (and possibly unsubscribe
the poster), if he deems them inappropriate.

------------------------------

Date: May 23, 1996
Subject:  Q2.7 -- Which version of sendmail should I run?

    If you're concerned at all about the security of your machines,
you should make sure you're at least running a recent release of
version 8 sendmail (either from your vendor or the public version
detailed in 1.8).

    Check the CERT Alerts and Summaries (details in 1.13) to make sure
that you're running a version that is free of known security holes.
Just because the sendmail program provided by your vendor isn't list
doesn't mean that you're not vulnerable, however.  If your particular
vendor or version isn't listed, check with your vendor and on the
appropriate Internet mailing lists and Usenet newsgroups to verify.

    If nothing else, the most recent public version is usually a
pretty good bet, although you should check <news:comp.mail.sendmail>
to see if anyone has posted recent comments that haven't yet been
folded into a new release.


    That said, you need to look at what the primary function is for
the machine.  If its primary function is to run some CAD/CAM package
on the desk of an Engineer, then there's probably not much sense in
replacing the vendor-supplied version of sendmail (assuming it's
secure, according to the CERT Alerts and Summaries).  Just set the
machine up to forward all outbound mail to a central mail relay, and
then worry about making that central mail relay the best it can be.
Also arrange to have all their inbound mail pass through a central
Mail eXchanger (probably the same machine as the central Mail Relay),
for the same reasons.


    If the primary function for a machine is to act as that central
Mail Relay/Mail eXchanger, then I *strongly* recommend the best
version of sendmail you can get, and in my opinion that is the latest
release of version 8.  IDA sendmail is also pretty good, but virtually
everything it does, version 8 does better, and version 8 has the
additional advantage of having continued development as well.  On a
central mailhub, recent versions of IDA sendmail are the oldest
sendmail that I'd even consider leaving in place instead of replacing
with version 8.

    However, keep in mind that version 8 still hasn't been ported (so
far as we know) to some of the older (and perhaps more esoteric)
platforms, and if you're stuck using one of them, you may not have
much choice.


    Recently, some vendors have started shipping (or announced that
they will soon ship) version 8 sendmail pre-configured for their
machines.  Unfortunately, in most cases this means you get a
pre-compiled binary and a sendmail.cf file (that may need a bit of
tweaking), but not much else of the "standard" version 8 sendmail
installation kit.  Silicon Graphics (SGI) is known to already be
shipping version 8 sendmail in this fashion, and both Hewlett-Packard
and Sun Microsystems have announced that they soon will be (Sun has a
patch today that can be applied to upgrade many machines to an older
release of version 8 sendmail).

    This may be suitable for desktop machines forwarding all their
mail to a central Mail Relay and receiving all their mail from a
central Mail eXchanger, but I personally believe that this is not
likely to be suitable for the central Mail Relay/Mail eXchanger
itself.  In that case, I recommend you get and install the latest
version and get the m4 macros, the on-line documentation, the source
code, etc....

------------------------------

Date: October 18, 1996
Subject:  Q2.8 -- What is the latest release of sendmail?

    For version 8 sendmail, there are now three release trees.

    For those people who, for whatever reason, are unable or
unwilling to upgrade to version 8.7.y (or later), a release of
version 8.6 sendmail is still available (but perhaps not for much
longer, as it is now at least two minor releases behind).  As of this
writing, the most recent release of version 8.6 sendmail is 8.6.13.

    As of this writing, the most recent release of version 8.7
sendmail is 8.7.6.  This is a mature release of version 8 sendmail,
and the security fix that was recently rolled in has not been (nor
will it be) integrated into 8.6.x.  On machines exposed directly
to the Internet, you should either already be running this release
or plan on upgrading to it in the immediate future.  All previous
releases of sendmail have known security holes or other problems,
and should be replaced by 8.7.6.


    For both of these releases, there is a version number difference
between the sendmail program itself and the associated configuration
files.  This is okay.  The security-related bug fixes that have been
made only required changes to the sendmail program itself and not
the configuration files, so only the version number of the sendmail
program itself was incremented.


    Version 8.8 sendmail has now been
made publicly available.  You can find it at
<FTP://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.8.2.tar.gz>.
This has a very important security bug fix, and it is vital that you
do not run any earlier release of version 8.8 sendmail (including
alpha or beta releases).  Once version 8.8 stablizes, there will
be no further support for previous releases of version 8 sendmail.

------------------------------

Date: October 15, 1996
Subject:  Q2.9 -- Where can I find it?

    By anonymous FTP from ftp.sendmail.org in /ucb/sendmail, or (in
URL form) via <ftp://ftp.sendmail.org/ucb/sendmail/>.  If you care,
there should be files in this directory that end with the extension
".sig" which you can check with PGP to make sure that corresponding
archives haven't been modified.  You'll need to have the PGP key
of Eric Allman on your public keyring to be able to verify these
archives with their associated .sig files.

    As of yet, there are no known official version 8 sendmail mirrors.

------------------------------

Date: March 23, 1996
Subject:  Q2.10 -- What are the differences between Version 8 and
	other versions?

    See doc/changes/changes.{me,ps} in the distribution.  See also
RELEASE_NOTES at the top level.

------------------------------

Date: March 23, 1996
Subject:  Q2.11 -- What is BIND and where can I get the latest version?

    BIND stands for "Berkeley Internet Name Daemon", and is the
Internet de-facto standard program for turning host names into IP
addresses.

    The BIND Home Page is at <http://www.isc.org/isc/bind.html>,
which provides pointers to the most recent release of BIND.
Note that BIND 4.9.4 was recently released as a final production
version, and there is also a patch that you should get and apply.

------------------------------

Date: March 23, 1996
Subject:  Q2.12 -- What's the best platform for running sendmail?

    Generally speaking, I adhere to the old axiom that you should
choose what software you want to run first, then choose the platform
(hardware and OS) that best runs this software.  By this token, a
recent version of BSD Unix would probably be best, since sendmail was
developed at UC Berkeley on BSD Unix.  FreeBSD and BSD/OS are two
known implementations of BSD Unix for Intel-based PC's (among other
hardware platforms), and this would make them the most "native" OSes
for sendmail.  FreeBSD is freely available by anonymous ftp or on
CD-ROM, and BSD/OS is a commercial product.

    However, not everyone has this kind of "luxury".  If you're on a
homogenous network (i.e., completely composed of only one type of
hardware and OS), then you should probably be running the same OS as
the rest of the machines on the network, regardless of the axiom
stated above.  You may have other problems, but you should at least be
able to get some local support on the OS for your machine.


    For more information on BSD Unix in general, see the Usenet
newsgroups under <news:comp.unix.bsd>, <news:comp.bugs.4bsd>,
<news:comp.os.386bsd>.  For more information on BSD/OS, see the BSD
newsgroups mentioned above, or the BSD/OS Home Page at
<http://www.bsdi.com/>.  For more information on FreeBSD, see the
Usenet newsgroups under <news:comp.unix.bsd.freebsd>, or the FreeBSD
Home Page at <http://www.freebsd.org/>.

------------------------------

Date: July 9, 1996
Subject:  Q2.13 -- What is smrsh and where can I get it?

    From <ftp://info.cert.org/pub/tools/smrsh/README>:

	smrsh is a restricted shell utility that provides the ability
	to specify, through a configuration, an explicit list of
	executable programs.  When used in conjunction with sendmail,
	smrsh effectively limits sendmail's scope of program execution
	to only those programs specified in smrsh's configuration.

	smrsh has been written with portability in mind, and uses
	traditional Unix library utilities.  As such, smrsh should
	compile on most Unix C compilers.

The purpose for restricting the list of programs that can be executed
in this manner is to keep mail messages (either through an alias or
the .forward file in a user's home directory) from being sent to
arbitrary programs which are not necessarily known to be sufficiently
paranoid in checking their input, and can therefore be easily
subverted (this is related to, but different from, the /etc/shells
feature discussed in Q3.11).

    More information regarding the CERT-CC can be found at their web
site, <http://www.cert.org>.  For more information on CERT Alerts and
CERT Summaries, see <ftp://info.cert.org/pub/cert_advisories/> and
<ftp://info.cert.org/pub/cert_summaries/>, respectively.


    You can find smrsh in the most recent sendmail source archive, as
well as <ftp://info.cert.org/pub/tools/smrsh/>.  Other very useful
programs can be found in <ftp://info.cert.org/pub/tools/>.

------------------------------

Date: July 5, 1996
Subject:  Q2.14 -- What is smap and where can I get it?

    Smap (and smapd) are tools out of the Trusted Information Systems
(TIS) Firewall Toolkit (fwtk).  They were originally written by
firewall expert Marcus Ranum under contract to TIS, and TIS is
continuing what maintenance there is.  The toolkit may be found at
<ftp://ftp.tis.com/pub/firewalls/toolkit/>.  Support questions
regarding the toolkit may be sent to <mailto:fwall-support@tis.com>,
while you may join their mailing list <mailto:fwall-users@tis.com> by
sending electronic mail to <mailto:fwall-users-request@tis.com>.


    The concept of smap and smapd is that sendmail is a huge,
monolithic setuid root program that is virtually impossible to verify
as being "correct" and free from bugs (historically, sendmail has been
rather buggy and an easy mark for system crackers to exploit, although
with the advent of version 8 sendmail, this becomes much more
difficult).  In contrast, smap and smapd are very small (only a few
hundred lines long), and relatively easy to verify as being correct
and functioning as designed (however, as you will see later, we can
question their design).  According to the theory, it is therefore
safer and "better" to run smap and smapd as "wrappers" around
sendmail, which would no longer need to be run setuid root.

    Unfortunately, smap and smapd have a few problems of their own,
and don't appear to have been updated since late March 1996.  Smapd is
also known to be incompatible with sendmail 8.7.y (both cannot be run
on the same machine, although if you're running sendmail 8.6.x and
smap/smapd on the local machine, people on the outside can still use
sendmail 8.7.y to talk to you), and it is unknown as to whether TIS
intends to update the software to fix this problem.

    For further information on smap and smapd, see the documentation
that comes with the TIS Firewall Toolkit.


    For more information on firewalls, see the Firewalls FAQ at
<http://www.v-one.com/newpages/faq.htm>.

------------------------------

Date: August 22, 1996
Subject:  Q2.15 -- What is TCP-Wrappers and where can I get it?

    TCP-Wrappers is another security enhancement package.  The theory
is that you take programs being run under inetd (see /etc/inetd.conf)
and before you run the program to do the real work (ftpd, telnetd,
etc...), you first run the connection attempt through a package that
checks to see if the IP address of the source packet is coming from a
host known to be either good or bad (you may filter connection
attempts by source host name, domain name, raw IP address, port they
are attempting to connect to; and either allow known good connections
through thus refusing unknown connections, or accept all connections
except those known to be bad).

    The practice of TCP-Wrappers actually follows the theory
quite well.  It is a very useful and important tool in the System
Administrator's Bag of Things To Help You Secure Your Machine
>From Crackers, Spammers, Junkmailers, and Other Undesirables.
However, it only works for programs that communicate via TCP packets
(not UDP, such as NFS) started up out of inetd.  It does not work
for RPC-based services, and programs that start up a daemon outside
of inetd and just leave it running obviously don't benefit beyond
the initial connection that gets the daemon started (however, see
the FTP URL below for other packages that can help secure RPC and
portmapper-based services).

    However, most sendmail installations tend to start up a daemon and
leave it running at all times.  If you did run sendmail out of inetd,
you'd lose the benefit of the load average checking code that is
executed only in daemon mode, and for systems that handle a lot of
mail, this is vitally important.

    You can get TCP-Wrappers from
<ftp://ftp.win.tue.nl/pub/security/>, a site that has
a whole host of other useful security tools, such as
securelib, portmap, satan, cops, crack, etc...  You can
also find pointers to many other useful security tools at
<http://ciac.llnl.gov/ciac/SecurityTools.html>, and the COAST Archive
at <http://www.cs.purdue.edu/homes/spaf/hotlists/csec.html> is a
veritable cornucopia of all things security related.


    For the adventurous, you can get a source patch for version 8
sendmail that will take the core TCP-Wrappers code and integrate it
into the daemon, so that you get the best of both worlds.  However,
this isn't quite as smoothly integrated as it should be, is not for
the faint-of-heart, and is certainly not officially supported by
the orginal author of sendmail (Eric Allman).  However, it appears
that a more fully integrated version of this patch (or similar
functionality) will find it's way into version 8.8 sendmail.

    You should be able to find the unsupported patch at
<ftp://ftp.win.tue.nl/pub/security/sendmail-tcpd.patch>.

------------------------------

Date: August 30, 1996

Subject:  Q2.16 -- Why won't db 1.85 build for my SGI running Irix
	>= 5.2?

    The db 1.85 package as available from ftp.cs.berkeley.edu
provides Irix support up to Irix 4.05F, but 5.{2,3} need a slightly
patched version.  Some vendors also provide db standard with their OS
(DEC Unix 4.0, for example).

    A tarball incorporating these changes is available at
<ftp://ftp.his.com/pub/brad/sendmail/irix5.tar.gz>.  This will
extract into ./db.1.85/PORT/irix.5.2, with a symbolic link
created from ./db.1.85/PORT/irix.5.3 to this same directory.
Make sure you extract this archive into the same directory
where you extracted the db 1.85 archive as available from
ftp.cs.berkeley.edu.  (see Q3.5 for more information on getting
the db 1.85 package).  An ASCII context diff of this same patch is
at <ftp://ftp.his.com/pub/brad/sendmail/irix4-5.diff>.

    Further changes need to be made for Irix 6.2, and no tarball
or context diff is yet available that incorporates these changes.

------------------------------

Date: August 30, 1996

Subject:  Q2.17 -- What is makemap and where can I get it?

    The program "makemap" is used to build the databases used by
version 8 sendmail, for things like the UserDB, mailertables,
etc....

    It is distributed as part of the basic Operating System from
some vendors, but source code for it is also included at the root
level of the sendmail archive (at least, it is for sendmail 8.6.12
and 8.7.5, and presumably will continue to be as newer releases come
out).  However, it is not considered a "supported" part of version
8 sendmail.  Just like the other source provided in the archive,
the Makefile will likely need some tweaking for your specific site.

    It turns out that Irix 5.3 doesn't appear to have the dbm or
ndbm libraries, but to compile makemap.c, you need to have -DNDBM
on the "DBMDEF=" line (some necessary things are defined only
in /usr/include/ndbm.h).  Try just leaving off "-lndbm" from the
"LIBS=" line in the Makefile for makemap.

    If you plan on using makemap with db 1.85 on an SGI machine
running a version of Irix later than 4.x, see Q2.16 for some
additional steps to get db 1.85 compiled on your machine.

------------------------------

Date: May 28, 1996
Subject:  Q3.1 -- How do I make all my addresses appear to be from a
	single host?

    Using the m4 macros, use:

	MASQUERADE_AS(my.dom.ain)

    This will cause all addresses to be sent out as being from the
indicated domain.

    On your mailhub/mailhost/Domain Mail eXchanger, you may need to
add "my.dom.ain" to the sendmail.cw file or the "Cwhost.my.dom.ain"
line in the sendmail.cf file.

    If you're using version 8.7 sendmail, and you want to hide this
information in the envelope as well as the headers, use:

	FEATURE(masquerade_envelope)

------------------------------

Date: August 30, 1996
Subject:  Q3.2 -- 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

    If your login name is "john" and your full name is "John Q.
Public", then this would be:

	john:mailname		John_Q_Public@your.domain.goes.here
	John_Q_Public:maildrop	john

    The words "mailname" and "maildrop" must be typed in literally,
just as they appear.


    Install this file 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)

    Version 8.7 sendmail changes the semantics of this feature such
that notsticky is turned on by default, and if you want the old (8.6)
behaviour, you instead define:

	FEATURE(stickyhost)


    Note:  The program "makemap" is discussed in further detail in
Q2.17.

------------------------------

Date: March 23, 1996
Subject:  Q3.3 -- 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.

    UC Berkeley is (was) in the process of setting up their
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.

------------------------------

Date: March 23, 1996
Subject:  Q3.4 -- Why are you so hostile to using full names for email
	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 email.

    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 email -- 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.

    Directory services should be as fuzzy as possible (within reason,
of course).  Mail services should be unique.

------------------------------

Date: August 19, 1996
Subject:  Q3.5 -- Where do I find this user database (UserDB) code?

    The user database code is part of the Sendmail V8 distribution.
However, it depends on your installing the db library from the package
at <ftp://ftp.cs.berkeley.edu/pub/4bsd/db.1.85.tar.gz>.  If you
install this library, edit the Makefile to include the right option
(-NEWDB), and then make sendmail again, you get a binary which has the
database features described in the book and the documentation provided
in the sendmail source archive.

    If you're using SGI Irix above 4.x, see Q2.16 for the patches
you will need to get db 1.85 working on your machine.

------------------------------

Date: July 19, 1996
Subject:  Q3.6 -- How do I get the user database to work with Pine or
	with FEATURE(always_add_domain)?

    The basic incompatibility with Pine and the user database option
is in how Pine writes From addresses in the header.  Most MUAs write
the From address as "From: user", while Pine, for reasons given in
its documentation, write the From address as "From: user@FQDN"
(FQDN=fully qualified domain name).  Using the m4 feature macro
"always_add_domain" has the same effect.  Because of this difference,
the user database does not rewrite these headers.

    One solution to this problem is to make the following change in
the sendmail.mc file compiled by m4 into your /etc/sendmail.cf (or
wherever your sendmail.cf file is located) after you have the user
database option installed and working with other MUAs:

    Early in the section(s) where you are setting configuration
variables, add the following:

	# Define our userdb file for FQDN rewrites
	Kuserdb btree -o /etc/userdb.db

    And a bit later, before the "MAILER()" entries, but after other
configuration options have been set:

	LOCAL_RULE_1
	########################################################
	### Local Ruleset 1, rewrite sender header & envelope ##
	########################################################
	#Thanks to Bjart Kvarme <bjart.kvarme@usit.uio.no>
	S1
	R$-			$1 < @ $j . >			user => user@localhost
	R$- < @ $=w . > $*	$: $1 < @ $2 . > $3 ?? $1	user@localhost ?
	R$+ ?? $+		$: $1 ?? $(userdb $2 : mailname $: @ $)
	R$+ ?? @		$@ $1				Not found
	R$+ ?? $+		$>3 $2				Found, rewrite
	    
	#NOTE    ^^^^^^^^^^^^^^^       ^^^^^^^^^^^^^^^^^^^^^^^^^
	#	  Use Tab Characters  Use Tab Characters in these regions
	# to make three columns (the line with "mailname" only has 2 columns).

    Now the user database should re-write messages sent with Pine or
anything else that causes local users to have their address be fully
qualified (both header and envelope sender will be properly
re-written).  If this still does not work for you, try adding the
following to either the system-wide pine.conf, pine.conf.fixed, or
your personal .pinerc:

	user-domain=localhost

    This has been known to help solve the problem for some people.

    However, a more elegant (read: m4-based) solution for version 8
sendmail users has yet to be created.

------------------------------

Date: Aug 9, 1996
Subject:  Q3.7 -- How do I manage several (virtual) domains?

    If you want to provide mailservice to several domains and be able
to add identical names across different domains, as in this example:

	   user@a.dom.ain	mb1@dom.ain
	   user@b.dom.ain	mb2@dom.ain
	   user@c.dom.ain	mb@outer.space

    you may accomplish this by using an external database in
conjunction with minor Ruleset rewriting in sendmail.cf.  Many ISPs
(Internet Service Providers) have asked me and here's a general
solution (you may combine it with userdb's if you need to):

    1.  Make a textfile (I usually make one for each domain and
	concatenate them before database-compilation) with the
	following structure:

	    user@a.dom.ain	mb1@dom.ain
	    user@b.dom.ain	mb2@dom.ain
	    user@c.dom.ain	mb@outer.space

	The LHS (Left Hand Side) is the mail-adress of a particular
	user and the RHS is the corresponding mailbox.  An example
	that might apply to the real world:

	    webmaster@josnet.se		wm.list@eowyn.josnet.se
	    webmaster@client1.se	joe@client1.se
	    webmaster@client2.se	anne@another.provider.se
	    webmaster@client3.se	joe@client3.se
	    joe@client1.se		c1_joe@mail.josnet.se
	    joe@client3.se		joeuser

	Note that you have to spell out the complete email-address in
	the LHS entry.  The RHS entry may be either a local address
	(for example 'johan' if that account exists) or a complete
	email-adress on another system (or a domain that the server
	recognizes as local for that matter).

    2.  Compile the textfile into a database:

	    makemap hash mbt.db <mbt

	You may you use other lookup-methods than hash (btree for
	example).  The resulting database is mbt.db in this example
	and the input is the textfile mbt.

    3.  Add a few lines in sendmail.cf:

	A.  In the beginning (typically in the "local info" section or
	    together with the user database option in the "options"
	    section):

	    # Declare mbt as a hash-lookup database:
	    Kmbt hash /etc/mail/mbt.db

       B.  In the Ruleset 98 section (local part of ruleset 0):

	    # Use mailboxtable-database:
	    R$+ < @ $+ . >	$: $1 < @ $2 > .
	    R$+ < @ $+ > $*	$: $(mbt $1@$2 $: $1 < @ $2 > $3 $)
	    R$+ < @ $+ > $*	$: $(mbt $2 $: $1 < @ $2 > $3 $)
	    RERROR $*		$#error $: $1
	    R$+ < @ $+ > .	$: $1 < @ $2 . >

    4.  The next-to-last line of these rules let you have an alias
	file like:

	    joe@somedom.com	joe
	    jim@somedom.com	jim@othersite
	    somedom.com		ERROR "No such user"

	And still have mail addressed to unknown users at that domain
	bounce properly.  You can also do a form of redirects, such
	as:

	    fred@somedom.com	ERROR "This user has moved to fred@otherdom.com"

    5.  Restart sendmail.  You must do this in order to reread the
	cf-file.

    6.  Test with sendmail -bv or sendmail -bt


    Note: Alternate sets of instructions and/or kits
can be found at <http://www.westnet.com/providers>,
<http://hub.org/softdocs/Sendmail-VD>,
<ftp://samson.oslo.uninett.no/pub/unix/sendmail/>, and
<http://jos.net/projects/mbt/>.  Neither these nor the instructions
here have yet to be tested by the maintainer of this FAQ, but are
believed to work correctly.  Which you use is a matter of your
personal aesthetics.

------------------------------

Date: July 9, 1996
Subject:  Q3.8 -- 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


    If your only contact with the external world is through UUCP,
you'll probably want to recompile sendmail with support for DNS turned
off (if your host architecture supports a service switch file that
sendmail understands, it will use the service switch however you've
got it configured, even if you've compiled sendmail with DNS support
turned off, so make sure the service switch file is also properly
configured).

    Using "FEATURE(nodns)" probably won't completely satisfy you, as
more recent releases of version 8 sendmail really, REALLY, want to
know what their canonical hostname is, and will go to great lengths to
figure this out from the DNS.  But if you don't have any nameservers,
this can obviously add significant amounts of time to process startup
as sendmail repeatedly tries (and fails) to find this information.  It
then becomes doubly important to have the proper Fully Qualified
Domain Name (FQDN) listed first in your /etc/hosts file or in the file
used to build your NIS/NIS+ table (or whatever you use).

    For more information on "FEATURE(nodns)", see the RELEASE_NOTES
file for sendmail versions 8.7.1 and later (search for "FQDN"), as
well as _sendmail_, page 741 (page reference correct as of first
edition, first printing).

------------------------------

Date: March 23, 1996
Subject:  Q3.9 -- How do I fix "undefined symbol inet_aton" and
	"undefined symbol _strerror" 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.

------------------------------

Date: March 23, 1996
Subject:  Q3.10 -- How do I solve "collect: I/O error on connection"
	errors?

    There is nothing wrong.  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.

------------------------------

Date: July 9, 1996
Subject:  Q3.11 -- Why can't my users forward their mail to a program?

    I just upgraded to version 8 sendmail and now when my users try to
forward their mail to a program they get an "illegal shell" or "cannot
mail to programs" 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, version 8 sendmail 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.


    IBM AIX does not use /etc/shells -- a list of allowable login
shells is contained, along with many other login parameters, in
/etc/security/login.cfg.  You can copy the information in the
"shells=" stanza into a /etc/shells on your system so sendmail will
have something to use.  Do NOT add "/usr/lib/uucp/uucico" or any other
non-login shell into /etc/shells.

    Also note that there are some weird things that AFS throws into
the mix, and these can keep a program from running or running
correctly out of .forward files or the system-wide aliases.


    See also "smrsh" in Q2.13.

------------------------------

Date: May 23, 1996
Subject:  Q3.12 -- Why do connections to the SMTP port take such a
	long time?

    I just upgraded to version 8 sendmail 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 version 8 sendmail
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 (pre-8.7.y sendmail), set the IDENT timeout to zero
using:

	define(`confREAD_TIMEOUT',`Ident=0')dnl

in the .mc file used by m4 to generate your sendmail.cf file.
Alternatively, if you don't use m4, you can put ``OrIdent=0'' in the
configuration file (we recommend the m4 solution, since that makes
maintenance much easier for people who don't understand sendmail
re-write rules, or after you've been away from it for a while).
Either way, this will completely disable all use of the IDENT
protocol.

    For version 8.7.y sendmail, you should instead use:

	define(`confTO_IDENT',`0s')dnl


    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 are up to date (this file is usually called something
like "/var/namedb/root.cache"; see your /etc/named.boot file to get
your value).  Either of these can cause long delays.

------------------------------

Date: March 23, 1996
Subject:  Q3.13 -- Why do I get "unknown mailer error 5 -- mail:
	options MUST PRECEDE recipients" errors?

    I just upgraded to version 8 sendmail 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, where "systype" is set
correctly for your hardware & OS combination -- otherwise the
configurations use a default that probably disagrees with your local
mail system.  See cf/README for details.

    If this is on a Sun workstation, you might also want to take a
look at the local mailer flags in the Sun-supplied sendmail.cf and
compare them to the local mailer flags generated for your version 8
sendmail.cf.  If they differ, you might try changing the V8 flags to
match the Sun flags.

------------------------------

Date: Jun 23, 1996
Subject:  Q3.14 -- Why does sendmail 8.7.y panic my SunOS 4.1.3 box?

    Sendmail 8.7.y panics SunOS 4.1.3_U1 (at least for 1<=y<=3) and
SunOS 4.1.3, but not SunOS 4.1.4, and sendmail 8.6.x seems fine on
both machines (at least for 9<=x<=12).  The problem is that a kernel
patch is missing, specifically 100584-08 (4.1.3) and 101790-01
(4.1.3_U1).  This should be available from your hardware vendor
through your support contract or their online support facilities
(including being available on the SunSolve CD, version 2.7.1 or
later).

    Sendmail 8.7.5 (and maybe earlier versions) also panics SunOS 4.1.3
(not 4.1.3_U1), but no patch numbers have yet been identified that fix
this problem.

------------------------------

Date: March 23, 1996
Subject:  Q3.15 -- Why does 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".

------------------------------

Date: May 28, 1996
Subject:  Q3.16 -- Why doesn't MASQUERADE_AS (or the user database)
	work for envelope addresses as well as header addresses?

    Believe it or not, this is intentional.  The interpretation of the
standards by the version 8 sendmail 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.


    If you're using version 8.7.y sendmail, you can use

	FEATURE(masquerade_envelope)

    in your sendmail.mc file to change this behaviour.

------------------------------

Date: March 23, 1996
Subject:  Q3.17 -- How do I run version 8 sendmail and support the
	MAIL11V3 protocol?

    Get the reimplementation of the mail11 protocol by Keith Moore
from <ftp://gatekeeper.dec.com/pub/DEC/gwtools/> (with contributions
from Paul Vixie).

------------------------------

Date: March 23, 1996
Subject:  Q3.18 -- Why do messages disappear from my queue unsent?

    When I look in the queue directory I see that qf* files have been
renamed to Qf*, and sendmail doesn't see these.  What's wrong?

    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.

------------------------------

Date: March 23, 1996
Subject:  Q3.19 -- When is sendmail going to support RFC 1522 MIME
	      header encoding?

    This is considered to be a MUA issue rather than an MTA issue.

Quoth Eric Allman:

	The primary reason is that the information necessary to
    do the encoding (that is, 8->7 bit) is unknown to the MTA.
    In specific, the character set used to encode names in headers
    is _NOT_ necessarily the same as used to encode the body
    (which is already encoded in MIME in the charset parameter
    of the Content-Type: header).  Furthermore, it is perfectly
    reasonable for, say, a Swede to be living and working in Korea,
    or a Russian living and working in Germany, and want their
    name to be encoded in their native character set; it could
    even be that the sender was Japanese, the recipient Russian,
    and the body encoded in ISO 8859-1.  If all I have are 8-bit
    characters, I can't choose the charset properly.

	Similarly, when doing 7->8 bit conversions, I don't want
    to throw away this information, as it is necessary for proper
    presentation to the end user.

------------------------------

Comments/updates should be sent to <sendmail-faq@etext.org>.

Copyright 1996, by Brad Knowles, all rights reserved

End of comp.mail.sendmail Frequently Asked Questions (FAQ), part 1 of 2
***********************************************************************
