Imported Debian patch 8.8.8-20debian/8.8.8-20

1 files changed, 1755 insertions, 0 deletions

diff --git a/debian/part1 b/debian/part1
new file mode 100644
index 0000000..f6f347a
--- /dev/null
+++ b/debian/part1
@@ -0,0 +1,1755 @@
+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
+***********************************************************************