path: root/debian/part1

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!hookup!nic.ott.hookup.net!vertex.tor.hookup.net!nic.win.hookup.net!news-out.internetmci.com!newsfeed.internetmci.com!uwm.edu!math.ohio-state.edu!howland.erols.net!newsxfer3.itd.umich.edu!news.cic.net!not-for-mail
From: brad@etext.org
Newsgroups: comp.mail.sendmail,comp.mail.misc,comp.answers,news.answers
Subject: comp.mail.sendmail Frequently Asked Questions (Part 1 of 2)
Followup-To: comp.mail.sendmail
Date: 27 Mar 1997 06:01:28 GMT
Organization: The ETEXT Archives
Lines: 1734
Approved: news-answers-request@MIT.Edu
Distribution: world
Expires: 05/01/97 02:00:01
Message-ID: <5hd2fo$pou$1@news.cic.net>
Reply-To: sendmail-faq@etext.org (Sendmail FAQ Maintainers)
NNTP-Posting-Host: locust.cic.net
Summary: This posting contains a list of Frequently Asked Questions
    (and their answers) about the program "sendmail", distributed with
    many versions of Unix.  It should be read by anyone who wishes to
    post to the Usenet newsgroup comp.mail.sendmail.
Keywords: sendmail mail SMTP FAQ
X-Posting-Frequency: posted on the 27th of each month
Xref: senator-bedfellow.mit.edu comp.mail.sendmail:42630 comp.mail.misc:38790 comp.answers:25080 news.answers:98196

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

URL: http://www.his.com/~brad/sendmail/index.html


			  comp.mail.sendmail
		    Frequently Asked Questions (FAQ)
		      Last updated March 24, 1997

	   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-1>
and <http://www.imc.org/sendmail-faq-2> 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-*" 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 more web-friendly (in
that all original work is done in SGML), and using the linuxdoc-sgml
tools, automatically generate both the HTML and ASCII text versions,
automatically posting the ASCII version 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.  Nevertheless, the Landfield Hypertext
Usenet FAQ Archive seems to work well, and if you must access
the comp.mail.sendmail FAQ via the web, try slinging over to
<http://www.landfield.com/faqs/mail/sendmail-faq/>.


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

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

Date: March 24, 1997
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 version 8 sendmail panic my SunOS 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?
	3.20  Why can't I get mail to some places, but instead
	        always get the error "reply: read error from
	        name.of.remote.host"?
	3.21  Why doesn't "FEATURE(xxx)" work?
	3.22  How do I configure sendmail to not use DNS?
	3.23  How do I get all my queued mail delivered to my Unix
		box from my ISP?


    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?
	4.10  How can I solve "cannot alias non-local names" errors?

    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.1.4  Why can't I use SunOS/Solaris to get email to
		    certain large sites?
	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: January 17, 1997
Subject:  Q0 -- TO DO list

* Make the FAQ more web-friendly by writing it in SGML and using
    the linuxdoc-sgml tools to automate the generation of the HTML
    and ASCII text versions.
* 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: January 21, 1997
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-1> and
<http://www.imc.org/sendmail-faq-2>.


    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.  However, Kent Landfield has put together an alternative
web archive of Usenet FAQs, and it appears to parse things in a
more sensible manner.

    The root of the Landfield FAQ archive is at
<http://www.landfield.com/faqs/>, and the comp.mail.sendmail FAQ
can be found at <http://www.landfield.com/faqs/mail/sendmail-faq/>.

    The Landfield Usenet Hypertext FAQ Archive supports full text
searching with multiple ways to access Usenet's Frequently Asked
Question postings.  Hyperlinks are enabled where ever possible to
make references easy to follow.  A full set of FAQ statistics is
also available.


    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-*"
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/>
		<http://www.landfield.com/faqs/>
    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: November 24, 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 place 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: January 21, 1997
Subject:  Q2.8 -- What is the latest release of sendmail?

    For version 8 sendmail, there are three release trees.

    For those people who, for whatever reason, are unable or
unwilling to upgrade to version 8.8.z, releases of version 8.6 and
8.7 sendmail are still available.  As of this writing, the most
recent release of version 8.6 sendmail is 8.6.13, and the most
recent release of version 8.7 sendmail is 8.7.6.

    For the most recent releases of 8.6 and 8.7 sendmail, 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 were 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.


    The most recent release of version 8.8 sendmail is 8.8.5.

    On machines exposed directly to the Internet, you should either
already be running 8.8.5 sendmail or plan on upgrading to it in the
immediate future.  This release is considered "mature", has security
fixes included that will not be found in any previous release, and
therefore supercedes all previous releases.

    There is no further support for previous releases of sendmail.

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

Date: January 21, 1997
Subject:  Q2.9 -- Where can I find it?

    By anonymous FTP from ftp.sendmail.org in /pub/sendmail, or (in
URL form) via <ftp://ftp.sendmail.org/pub/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.

    Current releases of sendmail can also be found at
<ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/>.

    There are no other known official version 8 sendmail mirrors.


    Check the sendmail home page at <http://www.sendmail.org/> for
late-breaking updates and other useful information.

    If you want to be notified regarding future updates to sendmail
and other items of potential interest, you may want to subscribe
to the sendmail-announce mailing list.  Address your subscription
requests to "majordomo@lists.sendmail.org" with "subscribe
sendmail-announce" as the body of the message.

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

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 24, 1997
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/bind.html>, which
provides pointers to the most recent release of BIND.  Note that
BIND 4.9.5-P1 is the most recent "production version", and BIND
8.1 (the next major release; skipping 5.x-7.x) is a "release
candidate" as of version 8.1T3B.  See the BIND 8.1T3B announcement
at <ftp://ftp.isc.org/isc/bind/src/testing/t3b-ann.asc> for more
information.


    Note that there are bugs in older resolver libraries, which can
cause problems getting to large sites (that list more than five IP
addresses for a particular name), or represent a huge security hole
as they do not check the returned data to see if it will fit in the
amount of space pre-allocated for it.

    If at all possible, you should get the most recent "release"
version of BIND and make a serious attempt to integrate it into
your configuration, since virtually all vendor-provided resolver
libaries are woefully out of date.

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

Date: March 24, 1997
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, if
sendmail is the software, then 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.


    Either way, if the primary function of the machine is to handle
"large" quantities of mail (for whatever value you define "large"
to be), I strongly recommend getting the latest stable release of
version 8 sendmail.

    On the other hand, if the primary function of the machine is
to sit on some Engineer's desk and do CAD, then it may be easier
for you to leave the vendor-supplied version of sendmail on that
machine (after suitable configuration), and instead concentrate
your efforts on making the central mail handling machine(s) as
robust and capable as they can be.

    However, you may be surprised to find that it is easier
for you to support only one version of sendmail across all the
various platforms than it is to try and support multiple versions of
sendmail, each unique for their particular platform.  In that case,
the easy solution is to put version 8 sendmail everywhere, and not
have to worry about vendor-specific problems with older versions.


    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.
There have been conflicting reports of incompatibilities between
smapd and 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).

    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: January 21, 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.  The SANS 1996
Network Security Roadmap at <http://www.sans.org/roadmap.html> has
much useful information and pointers to many other useful resources.


    For the adventurous, you can get a source patch for version
8 sendmail (created for 8.7.6, but with work, applicable to older
releases) 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 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).  This functionality
is integrated in a different fashion into version 8.8.5 sendmail.

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

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

Date: November 24, 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>.

    A version of db 1.85 that has been supposedly patched
to compile under Irix 6.2 has been made available at
<http://reality.sgi.com/ariel/db-1.85-irix.tar.Z>, but I haven't
had a chance to download and check it out yet.

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

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: January 24, 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 -d 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)


    You also need to make sure that you have the "ik" flags specified
on the affected mailer definition.


    Note: The program "makemap" is discussed in further detail
in Q2.17.  The UserDB feature is discussed further on pp. 643-645
of _sendmail, 2nd Ed._ by Costales.

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

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: November 24, 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 (-DNEWDB), 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: March 24, 1997
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 (local part of ruleset 0) section, add:

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

	    If you have any other rewrite rules in ruleset 98, these
	    should be able to either go after or before the existing
	    rules, but you may have to do some experimenting to
	    find out which placement works best.

    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.  Test with sendmail -bv and/or sendmail -bt

    6.	Restart sendmail.  You must do this in order to have the
	daemon reread the sendmail.cf.


    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/>.  None of these have been tested
by the maintainer of this FAQ, but are believed to work correctly.
Which you use is a matter of your personal aesthetics.


    If you're using version 8.8 sendmail, you can make use of the
new "virtual user table" feature (for one thing, it won't require
that you add new rewrite rules to your sendmail configuration, as
the previous example does).

	1.  Put "FEATURE(virtusertable)" in your sendmail.mc
	    file.

	2.  By default, sendmail will build tables out of
	    /etc/virtusertable.  If you want to change this, put
	    something like:

		define(`VIRTUSER_TABLE', `-o hash /usr/local/lib/virtusertable')dnl

	    in your sendmail.mc file.

	3.  Construct the virtusertable file like so:

		info@foo.com	foo-info
		info@bar.com	bar-info
		@baz.org	jane@elsewhere.net
		@somedom.com	error : 5.5.0 User unknown

	    (Contrast with steps 1 and 4 in the previous example
	    using regular mailertables).

	4.  Compile the textfile into a database:

		makemap hash /etc/virtusertable.db </etc/virtusertable

	    You may you use other lookup-methods than hash (btree
	    for example).  Make sure that this database type matches
	    what is defined for the table in step 2.

	5.  Put all the domains listed on the LHS of these aliases
	    in your sendmail.cw file, or on the Cw line in your
	    sendmail.cf.

	6.  Recompile your sendmail.cf from your sendmail.mc and
	    test it.

	7.  Once you are satisfied, move it into place and restart
	    sendmail.


    Note that the virtusertable is only referenced for inbound
mail (more accurately, only for controlling delivery).  If you
want to rewrite mail addresses from your virtual domain users as
they pass through your system, you'll also need to make comparable
modifications to the genericstable (used for rewriting).

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

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 24, 1997
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.

    Note that if you are using PPP and the MTU on your end does
not match what your service provider has configured, you may see
these problems.  Discuss with your service provider what the MTU
should be set to, and correct if there is a mismatch.

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

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: November 24, 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 (and above), 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: March 24, 1996
Subject:  Q3.14 -- Why does version 8 sendmail panic my SunOS box?

    Sendmail 8.7.y panics SunOS 4.1.3_U1 (at least for 1<=y<=3)
and SunOS 4.1.3, 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), 102010-03 (4.1.3_U1), or 102517 (4.1.4).
This should be available from your hardware vendor through your
support contract or their online support facilities (including
being available on the SunSolve CD).

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

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: November 24, 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 (or later), 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.

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

Date: January 17, 1997
Subject:  Q3.20 -- Why can't I get mail to some places, but
	      instead always get the error "reply: read error from
	      name.of.remote.host"?

    This is usually caused by a bug in the remote host's mail server,
or Mail Transport Agent (MTA).  The "EHLO" command of ESMTP causes
the remote server to drop the SMTP connection.  There are several
MTAs that have this problem, but one of the most common server
implementations can be identified by the "220 All set, fire away"
greeting it gives when you telnet to its SMTP port.

    To work around this problem, you can configure sendmail to use
a mailertable with an entry telling sendmail to use plain SMTP when
talking to that host:

	name.of.remote.host		smtp:name.of.remote.host


    Sites which must run a host with this broken SMTP implemetation
should do so by having a site running sendmail or some other
reliable (and reasonably modern) SMTP MTA act as an MX server for
the problem host.


    There is also a problem wherein some TCP/IP implementations
are broken, and if any connection attempt to a remote end gets a
"connection refused", then *all* connections to that site will
get closed.  Of course, if you try to use the IDENT protocol across
a firewall (at either end), this is highly likely to result in the
same apparent kind of "read error".

    The fix is simple -- on those machines with broken TCP/IP
implementations, do not attempt to use IDENT.  When compiling newer
releases of version 8 sendmail, the compiler should automatically
detect whether you're on a machine that is known to have this kind
of TCP/IP networking problem, and make sure that sendmail does
not attempt to use IDENT.  If you've since patched your machine so
that it no longer has this problem, you'll need to go back in and
explicitly configure sendmail for support of IDENT, if you want
that feature.

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

Date: January 17, 1996
Subject:  Q3.21 -- Why doesn't "FEATURE(xxx)" work?

    When creating m4 Master Config (".mc") files for version 8
sendmail, many "FEATURE()" macros simply change the definition of
internal variables that are referenced in the "MAILER()" definitions.

    To make sure that everything works as desired, you need to
make sure that "OSTYPE()" macros are put at the very beginning
of the file, followed by "FEATURE()" and "HACK()" macros, local
definitions, and at the very bottom, the "MAILER()" definitions.

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

Date: March 24, 1997
Subject:  Q3.22 -- How do I configure sendmail to not use DNS?

    In situations where you're behind a firewall, or across a
dial-up line, there are times when you need to make sure that
programs (such as sendmail) do not use the DNS at all.


    With version 8.8, you change the service switch file to omit
"DNS" and use only NIS, files, and other map types as appropriate.

    With previous releases of version 8 sendmail, you need to
recompile the binary and make sure that "NAMED_BIND" is turned off
in src/conf.h.


    Note that you'll need to forward all your outbound mail to
another machine as a "relay" (one that does use DNS, and understands
how to properly use MX records, etc...), otherwise you won't be able
to get mail to any site(s) other than the one(s) you configure in
your /etc/hosts file (or whatever).

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

Date: March 24, 1997
Subject:  Q3.23 -- How do I get all my queued mail delivered to my
	      Unix box from my ISP?

    Assuming you're running sendmail or some other SMTP MTA on
some sort of a Unix host, and your ISP uses version 8.8 sendmail
and they queue all mail for your domain (as opposed to stuffing it
all in one file that you need to download via POP3 or somesuch),
something like the following script should do the trick:

	#!/bin/sh
	telnet mail.myisp.com. 25 < __EOF__
	EHLO me.mydomain.com
	ETRN mydomain.com
	QUIT
	__EOF__


    Note that this is indented for readability, and the real script
would have column position #1 of the file be the first printable
character in each line.

    Of course, you'll have to fill in the appropriate details for
"mail.myisp.com", "mydomain.com", etc....


    If this script doesn't work, you may have problems with "here"
documents being fed as standard input to commands (like telnet).  In
that case, you'll need to build a similar script using "expect".  For
more information on expect, see <http://expect.nist.gov> and the book
"Exploring Expect: A Tcl-Based Toolkit for Automating Interactive
Applications" (<http://www.ora.com/catalog/expect/noframes.html>).


    If your ISP doesn't use version 8.8 sendmail, you may have to
cobble together alternative solutions.  They may have a "ppplogin"
script that is executed every time your machines dials them up, and
if so, you may be able to have them modified this script so as to
put a "sendmail -qRmydomain.com" in it (which is effectively what
the "ETRN" command does, but in a safer fashion).

    Alternatively, they may have a hacked finger daemon, so
that you'd put "finger mydomain.com@theirhost.theirdomain.com"
in your script.  Or, they may have some other solution for you.
However, only they would be able to answer what solutions they have
available to them.

    Obviously, the easiest and most "standard" solution is to have
them upgrade their system to the most recent stable release of
version 8.8 sendmail.

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

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
***********************************************************************