/usr/local/apache/htdocs/lib/public_html/book/SENDMAIL/sendmailfaq.txt Библиотека на Meta.Ua Sendmail FAQ
<META>
Интернет
Реестр
Новости
Рефераты
Товары
Библиотека
Библиотека
Попробуй новую версию Библиотеки!
http://testlib.meta.ua/
Онлайн переводчик
поменять

Sendmail FAQ (Updated 29-aug-1998



---------------------------------------------------------------
Origin: http://www.sendmail.org/faq/ Ў http://www.sendmail.org/faq/
---------------------------------------------------------------




Sendmail


Frequently Asked Questions (FAQ)




Last updated August 29, 1998


Comments and questions on this FAQ should be directed to
sendmail+faq@sendmail.org.






Table of Contents








1. COPYRIGHT NOTICE / REDISTRIBUTION REQUIREMENTS



The entire contents of this document are copyright 1997 - 1998 by the
Sendmail Consortium, 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.





2. INTRODUCTION / MISCELLANEOUS







Q2.1 -- What is this newsgroup?


Date: May 28, 1996


The Usenet newsgroup 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 dependent on what software and hardware you have. You
also don't want to embarrass 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 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
comp.mail.smail dedicated to it.
The Mail User Agent (MUA) Eudora has two newsgroups dedicated to it
(comp.mail.eudora.mac and
comp.mail.eudora.ms-windows),
depending on which hardware platform you use. If there isn't a more
appropriate newsgroup, try 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
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 comp.mail.advocacy or
news:comp.mail.mta.advocacy
newsgroup).




Subject: Q2.2 -- What is the scope of this FAQ?


Date: April 9, 1997


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 maintainers 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-222-0 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.




Q2.3 -- Where can I find the latest version of this FAQ?


Date: February 20, 1998


We post changes as they occur to the sendmail FAQ support page at
http://www.sendmail.org/faq/.




Q2.4 -- How do I access comp.mail.sendmail by email?


Date: November 24, 1996


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




Q2.5 -- Where can I ask email-related DNS questions?


Date: March 23, 1996


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




Q2.6 -- How can I subscribe to these?


Date: June 19, 1997


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


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.


Some more information from the BIND 8.1 src/README file:


























































Kits, Questions, Comments, and Bug Reports
URL Purpose
ftp.isc.org/isc/bind/src/cur current non-test release
ftp.isc.org/isc/bind/src/testing latest public test kit

comp.protocols.dns.bind using BIND
comp.protocols.dns.ops DNS operations in general
comp.protocols.dns.std DNS standards in general

bind-users-request@vix.com gw'd to c.p.d.bind
namedroppers-request@internic.net gw'd to c.p.d.std
bind-workers-request@vix.com code warriors only please

www.isc.org/bind.html the BIND home page
bind-bugs@isc.org bug reports






Q2.7 -- Which version of sendmail should I run?


Date: April 8, 1997


Updated: May 20, 1998


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 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 listed 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
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 we *strongly* recommend the best
version of sendmail you can get, and in our 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.


If fighting spam is a concern, then by all means upgrade to 8.9.X .
8.8.X has some good anti-spam features, but 8.9.X has more features,
and the anti-spam ones are far easier to configure than those in 8.8.X .


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), Hewlett-Packard and Sun
Microsystems are known to already be shipping version 8 sendmail in
this fashion.




Q2.8 -- What is the latest release of sendmail?


Date: October 24, 1997


Updated: July 2, 1998


For version 8 sendmail, there are four 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.


Version 8.9.1 was released on July 2, 1998.
Version 8.9.0 was released on May 20, 1998.


On machines exposed directly to the Internet, you should either already
be running sendmail 8.9.0 or plan on upgrading to it in the immediate future.
8.9.0 is considered "stable", 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.




Q2.9 -- Where can I find it?


Date: January 21, 1997


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.




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.




Q2.10 -- What are the differences between Version 8 and
other versions?


Date: March 23, 1996


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




Q2.11 -- What's the best platform for running sendmail?


Date: April 8, 1997


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


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 to 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 comp.unix.bsd,
comp.bugs.4bsd,
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/.




Q2.12 -- What is BIND and where can I get the latest version?


Date: June 24, 1997


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. In May of 1997,
the first production version of BIND-8 was released. The ISC has deprecated
BIND-4 other than for security related patches. No new features or
portability changes will be added to BIND-4. You should be using BIND-8.


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
libraries are woefully out of date.


Note that since the release of BIND version 8.1, many people building sendmail
have experienced problems compiling and linking with the new BIND include files
and libraries under /usr/local/. A section in our Compiling
Sendmail page explains this.




Q2.13 -- What is smrsh and where can I get it?


Date: July 9, 1996


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 their
advisories and
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/.




Q2.14 -- What is smap and where can I get it?


Date: July 5, 1996


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
here. Support questions
regarding the toolkit may be sent to
fwall-support@tis.com,
while you may join their mailing list
fwall-users@tis.com by sending electronic mail to
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.




Q2.15 -- What is TCP-Wrappers and where can I get it?


Date: April 8, 1997


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/
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 original 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.




Q2.16 -- Why won't db 1.85 build on my machine?


Date: April 8, 1997


Updated: May 20, 1997


As of release 8.9.X of sendmail, db 1.85 is no longer needed, as support
for db 2.X is included (starting with 2.3.16). More details are given at
Q3.25. The rest of this answer only applies
if you have not yet upgraded to 8.9.X .


The db 1.85 package as available from
http://www.sleepycat.com/packages/db.1.85.tar.gz
provides Irix support up to Irix 4.05F, but 5.{2,3} need a slightly
patched version, as does HP-UX 10.20. Some vendors also provide
db standard with their OS (DEC Unix 4.0, for example).


A tarball incorporating these changes for Irix 5.x 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 supposedly been patched
to compile under Irix 6.2 has been made available at
http://reality.sgi.com/ariel/freeware/#db,
but I haven't had a chance to download and check it out yet.


The context diffs required to get db
1.85 working under HP-UX 10.20 are available at
ftp://ftp.his.com/pub/brad/sendmail/hpux.10.20.diff.
A tarball incorporating these changes is available at
ftp://ftp.his.com/pub/brad/sendmail/hp-ux.10.20.tar.gz. This will
extract into ./db.1.85/PORT/hpux.10.20, so 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.




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


Date: August 30, 1996


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.





3. VERSION 8 SPECIFIC ISSUES







Q3.1 -- How do I make all my addresses appear to be from a single
host?



This question is answered in detail at the configuration
Masquerading and Relaying page.




Q3.2 -- How do I rewrite my From: lines to read
``First_Last@My.Domain''' or ``Different_Name@My.Domain''?


Date: September 23, 1997


There are a couple of ways of doing this. This describes using the
"user database" code, discussed in detail at the
Using UserDB to Map Full Names page.
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 DifferentName
DifferentName:maildrop loginname


Install it in (for example) /etc/userdb. Create the database:


makemap btree /etc/userdb.db < /etc/userdb


You can then create a config file that uses this. You will
have to include the following in your .mc file:


define(confUSERDB_SPEC, /etc/userdb.db)
FEATURE(notsticky)





Q3.3 -- Why are you so hostile to using full names for email
addresses?


Date: May 12, 1997


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.




Q3.4 -- So what was the user database feature intended for?


Date: May 12, 1997


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.




Q3.5 -- Where do I find this user database (UserDB) code?


Date: October 13, 1997


The user database code is part of the Sendmail V8 distribution.
However, it depends on your installing the db library from the
package at
http://www.sleepycat.com/packages/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.




Q3.6 -- How do I get the user database to work with Pine or
with FEATURE(always_add_domain)?


Date: July 19, 1996


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.




Q3.7 -- How do I manage several (virtual) domains?



This question is answered in detail at the
Virtual Hosting page.




Q3.8 -- There are four UUCP mailers listed in the
configuration files. Which one should I use?



This question is answered in detail at the configuration
Using UUCP Mailers page.




Q3.9 -- How do I fix "undefined symbol inet_aton" and
"undefined symbol _strerror" messages?



This question is answered in detail within the
Compiling Sendmail page.




Q3.10 -- How do I solve "collect: I/O error on connection" or
"reply: read error from host.name" errors?


Date: April 8, 1997


Updated: June 4, 1998


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 this problem is sometimes caused by incompatible
values of the MTU (Maximum Transmission Unit) size on a SLIP or
PPP connection. Be sure that your MTU size is configured to be
the same value as what your ISP has configured for your connection.
If you are still having problems, then have your ISP configure your
MTU size for 1500 (the maximum value), and you configure your MTU
size similarly.


Although it seems like a problem of this sort would affect all
of your connections, that is not the case. You may encounter this
problem with only a small number of sites with which you exchange
mail, and it may even affect only certain size messages.




Q3.11 -- Why can't my users forward their mail to a program?


Date: July 9, 1996


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.




Q3.12 -- Why do connections to the SMTP port take such a long time?


Date: November 24, 1996


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.




Q3.13 -- Why do I get "unknown mailer error 5 -- mail:
options MUST PRECEDE recipients" errors?


Date: March 23, 1996


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 the configuration OSTYPE
page 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.




Q3.14 -- Why does version 8 sendmail panic my SunOS box?


Date: March 24, 1996
Updated: November 4, 1997


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-05 (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).





Q3.15 -- Why does the Unix From line get mysteriously munged when I
send to an alias?


Date: December 3, 1997


``It's not a bug, it's a feature.'' This happens when you have an
owner-list alias and you send to list. V8 propagates
the owner information into the SMTP envelope sender field (which appears as the
Unix From line [sometimes incorrectly referred to as the From-space "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".




Q3.16 -- Why doesn't MASQUERADE_AS (or the user database)
work for envelope addresses as well as header addresses?


Date: November 24, 1996


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 behavior.
This is discussed in greater detail at the configuration
Masquerading and Relaying page.




Q3.17 -- How do I run version 8 sendmail and support the
MAIL11V3 protocol?


Date: March 23, 1996


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




Q3.18 -- Why do messages disappear from my queue unsent?


Date: March 23, 1996


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.




Q3.19 -- When is sendmail going to support RFC 1522 MIME header
encoding?


Date: March 23, 1996


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.






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"?


Date: January 17, 1997


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




Q3.21 -- Why doesn't "FEATURE(xxx)" work?


Date: January 17, 1996


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.
See the configuration Introduction and Example
page for more details.




Q3.22 -- How do I configure sendmail not to use DNS?


Date: March 24, 1997


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




Q3.23 -- How do I get all my queued mail delivered to my
Unix box from my ISP?


Date: June 6, 1997


In the contrib directory of the sendmail distribution is a
Perl script called etrn.pl. 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 some such), the command


etrn.pl mail.myisp.com mydomain.com

will do the trick. You can learn about Perl at the
Perl Language Home Page.
The O'Reilly book
is also very helpful.


If you don't have Perl, 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 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.




Q3.24 -- Why do I get the error message unable to write
/etc/mail/sendmail.pid
?


Date: August 6, 1997


sendmail checks if it has write access to the directory in which it
wants to create a file without granting special privileges to 'root'.
To have sendmail run properly, the directories /etc,
/etc/mail, and/or /var/run should be owned
by root and be writable by its owner.




Q3.25 -- Why can't I compile sendmail with Berkeley DB 2.X?


Date: August 12, 1997


Updated: May 20, 1998


sendmail 8.8 only supports Berkeley DB 1.85. It will not work with newer
Berkeley DB versions, even in compatibility mode


Sendmail 8.9, however, does include support for Berkeley DB 2.X, starting
with 2.3.16 .




Q3.26 -- What operating systems has Berkeley sendmail been ported to?


Date: December 18, 1997


Berkeley sendmail 8.8.8 supports most known flavors of UNIX, including:


386BSD A-UX AIX Altos
BSD-OS BSD43 CLIX CSOS
ConvexOS Dell DomainOS Dynix
EWS-UX_V FreeBSD HP-UX IRIX
ISC KSR LUNA Linux
Mach386 NCR.MP-RAS NEWS-OS NeXT
NetBSD NonStop-UX OSF1 OpenBSD
PTX Paragon PowerUX RISCos
SCO SINIX SMP_DC.OSx.NILE Solaris
SVR4 SunOS Titan ULTRIX
UMAX UNICOS UNIX_SV.4.x.i386
UX4800 UXPDS Utah dgux
maxion uts.systemV



Also, a Windows NT version is available from
MetaInfo, Inc..




Q3.27 -- How do I prevent Relaying Denied errors for my
clients?


Date: April 12, 1998


Last updated: August 9, 1998


You need to add the fully-qualified host name and/or IP address of each
client to class R, the set of relay-allowed domains. For version 8.8.X,
this is typically defined by the file /etc/sendmail.cR ;
for 8.9.X, it is typically /etc/mail/relay-domains . Note:
if your DNS is problematic, you may need to list the IP address in
square brackets (e.g., [1.2.3.4]) to get the
${client_name} macro to work properly; in general, however,
this should not be necessary.


Once you've updated the appropriate file, SIGHUP your sendmail
daemon and you should be OK.


Further details are available on our Allowing
controlled SMTP relaying in Sendmail 8.9
page.




Q3.28 -- Why isn't virtual hosting working, even after I added a
Kvirtuser line to sendmail.cf?


Date: April 12, 1998


Just adding the proper Kvirtuser line to sendmail.cf is not enough
to enable the virtual user table feature, a key ingredient for virtual hosting.
You need to use the m4 technique HREF="/m4/features.html#virtusertable">FEATURE(virtusertable);
detailed instructions are provided at our
Virtual Hosting with Sendmail page.




Q3.29 -- How can I add a header specifying the actual recipient when having
multiple users in a virtual domain go to a single mailbox?


Date: July 2, 1998


Stuffing multiple user's mail into a single mail box is not a good method of
distributing user mail but if you must do this, the following solution should
allow a tool like fetchmail to separate the messages for individual users.


  1. Use FEATURE(local_procmail) in your .mc file
    so procmail (which you must install separately) will deliver mail to
    the mailbox.

  2. Use FEATURE(virtusertable) to create a virtual user table
    entry for the domain as follows:

    @domain.com domuser+%1

    where domuser is the username of the mailbox you will be using.
  3. Put this in the respective domuser's
    $HOME/.procmailrc:

    DOMAIN=domain.com
    ENV_TO=$1

    :0f
    * ENV_TO ?? .
    | formail -i "X-Envelope-To: "$ENV_TO@$DOMAIN

    :0fE
    | formail -i "X-Envelope-To: UNKNOWN"

    This will insert an X-Envelope-To header with the original
    envelope recipient address when the message is delivered the normal way
    via the virtusertable, and UNKNOWN if for some reason it was
    sent directly to domuser.






4. GENERAL SENDMAIL ISSUES







Q4.1 -- Should I use a wildcard MX for my domain?


Date: July 9, 1996
Updated: November 5, 1997


If at all possible, no.


Wildcard MX records have lots of semantic "gotcha"s. For example,
they will match a host "unknown.your.domain" -- if you don't
explicitly test for unknown hosts in your domain, you will get "MX list for
hostname points back to hostname" or "config error: mail loops back to
myself".


See RFCs 1535, 1536, and 1912 (updates RFC 1537) for more detail
and other related (or common) problems. See also _DNS and BIND_ by
Albitz and Liu.


They can also cause your system to add your domain to outgoing
FQDNs in a desperate attempt to get the mail to where it's supposed to
go, but because *.your.domain is valid due to the wildcard MX,
delivery to not.real.domain.your.domain will get dumped on you, and
you may even find yourself in a loop as the domain keeps getting
tacked on time after time after time (the "config error: mail loops
back to myself" problem).



Wildcard MX records are just a bad idea, plain and simple.
They don't work the way you'd expect, and virtually no one gets
them right. Avoid them at all costs.




Q4.2 -- How can I set up an auto-responder?


Date: March 23, 1996


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



The latest version of Majordomo can be found at
ftp://ftp.greatcircle.com/pub/majordomo/.
It is written in Perl and
requires either Perl 4.036, and appears to run with only minor tweaks
under 5.001a or later. Make sure to check out the web interface for
Majordomo called "Mailserv" at
http://iquest.com/~fitz/www/mailserv/
or "LWGate" at
http://www.netspace.org/users/dwb/lwgate.html.
The latest versions of Perl (both 4.x and 5.x) can be found in
http://www.metronet.com/perlinfo/src/.
More information about Perl can be found at
http://www.metronet.com/perlinfo/perl5.html


The latest version of ftpmail can be found at
ftp://src.doc.ic.ac.uk/packages/ftpmail
or any comp.sources.misc archive (volume 37).




Subject: Q4.3 -- How can I get sendmail to deliver local mail to
$HOME/.mail instead of into /usr/spool/mail (or /usr/mail)?


Date: July 9, 1996


Again, this is a local mailer issue, not a sendmail issue. Either
modify your local mailer (source code will be required) or change the
program called in the "local" mailer configuration description to be a
new program that does this local delivery. One program that is
capable of doing this is procmail (see Q4.9), although there are
probably many others as well.


You might be interested in reading the paper ``HLFSD: Delivering
Email to your $HOME'' available in the Proceedings of the USENIX
System Administration (LISA VII) Conference (November 1993). More
information is at
ftp://ftp.cs.columbia.edu/pub/hlfsd/README.hlfsd,
while the actual archive of the papers is at
ftp://ftp.cs.columbia.edu/pub/hlfsd/hlfsd-paper.tar.gz
(tar archive, gzip'ed).




Subject: Q4.4 -- Why does it deliver the mail interactively when I'm
trying to get it to go into queue only mode?


Date: March 23, 1996


Or, I'm trying to use the "don't deliver to expensive mailer"
flag, and it delivers the mail interactively anyway. I can see it
does it: here's the output of "sendmail -v foo@somehost" (or Mail -v
or equivalent).



The -v flag to sendmail (which is implied by the -v flag to Mail
and other programs in that family) tells sendmail to watch the
transaction. Since you have explicitly asked to see what's going on,
it assumes that you do not want to to auto-queue, and turns that
feature off. Remove the -v flag and use a "tail -f" of the log
instead to see what's going on.


If you are trying to use the "don't deliver to expensive mailer"
flag (mailer flag "e"), be sure you also turn on global option "c" --
otherwise it ignores the mailer flag.




Subject: Q4.5 -- How can I solve "MX list for hostname points back to
hostname" and "config error: mail loops back to myself" messages?


Date: January 17, 1997
Updated: November 5, 1997


I'm getting these error messages:


553 MX list for domain.net points back to relay.domain.net
554 <user@domain.net>... Local configuration error

How can I solve this problem?


You have asked mail to the domain (e.g., domain.net) to be
forwarded to a specific host (in this case, relay.domain.net)
by using an MX record, but the relay machine doesn't recognize
itself as domain.net. Add domain.net to /etc/sendmail.cw (if you
are using FEATURE(use_cw_file)) or add "Cw domain.net" to your
configuration file.



IMPORTANT: When making changes to your configuration file, be
sure you kill and restart the sendmail daemon (for ANY change in the
configuration, not just this one):


kill `head -1 /etc/sendmail.pid`
sh -c "`tail -1 /etc/sendmail.pid`"

NOTA BENE: kill -1 does not work with versions prior to 8.7.y!


With version 8.8.z sendmail, if the daemon was started up with
a full pathname (i.e., "/usr/lib/sendmail -bd -q13m"), then you
should be able to send it a HUP signal ("kill -1", or more safely,
"kill -HUP") and have it reload itself (version 8.7.y sendmail
cannot do this safely, and represents a security risk if it's not
replaced with version 8.8.3 or later).




Subject: Q4.6 -- Why does my sendmail process sometimes hang when
connecting over a SLIP/PPP link?


Date: March 23, 1996


I'm connected to the network via a SLIP/PPP link. Sometimes my
sendmail process hangs (although it looks like part of the message has
been transfered). Everything else works. What's wrong?


Most likely, the problem isn't sendmail at all, but the low level
network connection. It's important that the MTU (Maximum Transfer
Unit) for the SLIP connection be set properly at both ends. If they
disagree, large packets will be trashed and the connection will hang.




Subject: Q4.7 -- How can I summarize the statistics generated by
sendmail in the syslog?


Date: April 9, 1997


This question is addressed on pages 445-449 of _sendmail, 2nd
Ed_ (see page 319 of first edition) by Bryan Costales (see entry
sendmail-faq//book/ISBN/1-56592-222-0 in Q6.1).


An updated version of this syslog-stat.pl script (so that
it understands the log format used in version 8 sendmail) is at
ftp://ftp.his.com/pub/brad/sendmail/syslog_stats.
The updated version of ssl has been uploaded to the SMTP Resources
Directory (in
ftp://ftp.is.co.za/networking/mail/tools/),
as well as
ftp://ftp.his.com/pub/brad/sendmail/ssl.
There is also another program (written by Bryan Beecher) at
ftp://ftp.his.com/pub/brad/sendmail/smtpstats.


If you're interested in summarizing POP statistics, there is
ftp://ftp.his.com/pub/brad/sendmail/popstats,
also written by Bryan Beecher.


To see what else is available today, check the Comprehensive Perl
Archive Network
ftp://ftp.funet.fi/pub/languages/perl/CPAN/CPAN
or ftp://ftp.cis.ufl.edu/pub/perl/CPAN/CPAN
for the site nearest you.
For the scripts themselves, look under CPAN/scripts/mailstuff/ at
any CPAN site. For more information, see the comp.lang.perl.* FAQs at
ftp://ftp.cis.ufl.edu:/pub/perl/faq/FAQ or
ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/lang/perl/.


There is also the "Sendmail Statistics Project" which has a web page at
http://www.josnet.se/projects/ssp/.
Although they have
examples online of what the output might look like, it now appears
that this project is either dead or at least indefinitely on hold.
Still, you may be able to talk to the authors in order to get what
code from them you can.



If you're interested in using these kinds of tools to help
you do some near real-time monitoring of your system, you might be
interested in MEWS (Mail Early Warning System). From the README:


If you've ever written a perl script to parse sendmail
log files looking for errors, MEWS might be of interest to
you. If you've ever thought about writing a perl script to
munge sendmail log files, cringed a little and hurriedly
came up with an excuse not to do it, read on.

If you don't have a Solaris 2.5 machine, you can probably
stop reading here.

The Mail Early Warning System (MEWS) gives postmasters
immediate notification of trouble spots on your mail
backbone. It only works with sendmail.

To explain it in a nutshell, whenever sendmail returns a
4xx or 5xx SMTP code, with the MEWS modifications, it also
sends the code over UDP to a daemon which then replays the
error message to interested parties. The man pages go into
a little bit more detail.

If this sounds like something you might be interested in
getting more details about, you can find the MEWS archive at
ftp://ftp.qualcomm.com/pub/people/eamonn/mews.tar.Z.




Subject: Q4.8 -- How can I check my sendmail.cf to ensure that it's
re-writing addresses correctly?


Date: July 9, 1996


The recommended program for this is "checksendmail" by Rob
Kolstad. Old versions of this are available on various archive sites,
but currently, the only way to get the most recent version (which has
been updated to understand version 8.7 long option name syntax, as
well as now supporting both Perl 4.x and Perl 5.x) is from Rob
himself.


The latest archive will be made publicly available (most likely
through the SMTPRD run by Andras Salamon; see Q6.5, entry
sendmail-faq//online/index/14) as soon as it is received.




Subject: Q4.9 -- What is procmail, and where can I get it?


Date: April 8, 1997


The program "procmail" is a replacement for the local mailer
(variously called /bin/mail, /usr/bin/mail, mail.local, rmail,
etc...). It has been ported to run on virtually every Unix-like
OS you're likely to run into, and has a whole host of features.
It is typically about 30% faster performing the job of the local
mailer than programs such as /bin/mail or /usr/bin/mail, it has been
hammered on widely to make it extremely secure (much more so than
most local mailers) and very robust. Procmail is also capable of
helping you put a quota on a user's mailbox through the standard
Unix quota mechanism (see Q4.3).


In short, whatever you've got, you're almost guaranteed that
procmail is better (if nothing else, the author has been able to focus
lots of time and energy into making it the best and fastest tool
available, while most system vendors just throw something together as
fast as they can and move on to the whole rest of the OS).


However, this only begins to scratch the surface of what procmail
is capable of. It's most important feature is the fact that it gives
you a standard way to create rules (procmail calls them "recipes") to
process your mail before the messages get put into your mailbox, and
for that feature alone, it is one of the most important tools any
administrator can have in their repertoire. By filtering out or
automatically dealing with 80% of your daily cruft, it lets you spend
more time on the hard 20%.


Note that recent releases of version 8 sendmail natively support
using procmail as an alternate local mailer (see
"FEATURE(local_procmail)" for version 8.7 and above). They also
support procmail as an additional local mailer, if you're concerned
about flat-out replacing your current local mailer with procmail (see
"MAILER(procmail)" in version 8.7 and above).


You can also install procmail as a user and run it out of your
.forward file, although this tends to be a bit slower and less
efficient.



The latest version of procmail can be found at
ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail/.


Procmail is also the core to a mailing list management package
called "SmartList", so if you've already got procmail, adding
SmartList may be a good option. Some listowners prefer Majordomo,
Listserv, or one of those other programs, but SmartList has more than
a few adherents as well. Your personal tastes will dictate whether
you swear by SmartList or at it.




Subject: Q4.10 -- How can I solve "cannot alias non-local names"
errors?


Date: March 24, 1997


I upgraded from my vendor's sendmail to the latest version and
now I'm getting these error messages when I run "newaliases":


/etc/aliases: line 13: MAILER-DAEMON... cannot alias non-local names
/etc/aliases: line 14: postmaster... cannot alias non-local names

How can I solve this problem?


Your local mailer doesn't have the "A" flag specified. Edit the
Mlocal line in sendmail.cf and add "A" to the flags listed after
"F=".


Better yet, if you're running a recent version of sendmail
that uses m4 to generate .cf files from .mc files, regenerate your
sendmail.cf and see if that fixes the problem. Remember to install
the new sendmail.cf and restart the sendmail daemon.




Subject: Q4.11 -- Is sendmail Year-2000 compliant?


Date: April 24, 1997


Quoth Eric Allman:


... I can make the following assurances:


Internally, sendmail represents dates in the Unix native format:
seconds since January 1, 1970. This does not overflow until well
after the year 2000.


Externally, sendmail always represents dates using four digit
years, as required by the applicable Internet standards.


At no time does sendmail store dates using only the last two digits of
the year. However, if a Date: field is received that has a
two digit year, sendmail does not attempt to repair that damage. However,
neither does it attempt to interpret the date.






Subject: Q4.12 -- How can I batch remote mail to be sent using my ISP
while delivering local mail immediately?


Date: October 14, 1997


First, you need to get sendmail not to use DNS on your local
machine so your host doesn't trying to connect to your ISP for a DNS query.
See
Q3.22 for more
information.


You also need to designate a
"smart host" or
external relay to handle all mail that you can't deliver locally (this would
be your ISP's mailhost).


You need to configure it so that the smtp mailer is considered
"expensive" by adding the F=e mailer flag and tell sendmail
not to connect to expensive mailers by default by setting the

HoldExpensive
option to True.


You need to add mydomain.com to the sendmail.cw
file or the Cw line in the sendmail.cf. See
Q4.5.


Finally, you need to run a program periodically to check in with your
ISP and get them to deliver any mail they may have queued for you. See
Q3.23.




5. VENDOR/OS SPECIFIC SENDMAIL ISSUES







5.1 -- Sun Microsystems SunOS/Solaris 1.x/2.x






Q5.1.1 -- How can I solve "line 273: replacement $3 out of bounds"
errors?


Date: March 23, 1996


When I use sendmail V8 with a Sun config file I get lines like:


/etc/sendmail.cf: line 273: replacement $3 out of bounds

the line in question reads:

R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether

what does this mean? How do I fix it?


V8 doesn't recognize the Sun "$%y" syntax, so as far as it is
concerned, there is only a $1 and a $2 (but no $3) in this line. Read
Rick McCarty's paper on "Converting Standard Sun Config Files to
Sendmail Version 8", in the contrib directory (file
"converting.sun.configs") in the latest version 8 sendmail
distribution for a full discussion of how to do this.




Q5.1.2 -- How can I solve "line 445: bad ruleset 96 (50 max)" errors?


Date: March 23, 1996


When I use sendmail V8 on a Sun, I sometimes get lines like:


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

what does this mean? How do I fix it?


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


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

Assuming, of course, that you have installed sendmail V8 in
/usr/local/lib/sendmail.v8.




Q5.1.3 -- Why does version 8 sendmail (< 8.7.5) sometimes
hang under Solaris 2.5?


Date: May 23, 1996


In moving from Solaris 2.4 to Solaris 2.5, the kernel changed its
name and is now in /kernel/genunix instead of /kernel/unix, so
_PATH_UNIX in conf.h is pointing to the wrong place.


If you can't upgrade to the latest release of sendmail 8.8.z,
the next best thing to do is change _PATH_UNIX in conf.h (in the
solaris2 part) to point to the generic interface /dev/ksyms, like so:


# define _PATH_UNIX "/dev/ksyms"





Q5.1.4 -- Why can't I use SunOS/Solaris to get email to
certain large sites?


Date: November 24, 1996


This is most likely a problem in your resolver libraries
(DNS, /etc/hosts, NIS, etc...). Older Sun (and Solaris?) resolver
libraries allocated enough room for only five IP addresses for each
host name, and if any program ever ran across a name with more than
five IP addresses for it, the program would crash.


For example, this would keep you from getting mail to CompuServe,
since (at the time of this writing) they list eleven IP addresses
for mx1.compuserve.com (one of the named MXes for compuserve.com).


This will affect you even if you use version 8 sendmail, since
it's a problem in the resolver libraries, and not in sendmail itself.



You should either get patches to the resolver libraries from
Sun, or the latest version of BIND (see Q2.12) and install their
resolver library routines. Between the two, installing BIND is a
bit more work, but it typically gives you much more up-to-date code
to help you resist attacks to your systems, more capable programs
to be used for serving the DNS (including support for IPv6 and
several other features), and some very useful utility programs.




Q5.1.5 -- Why do I have trouble compiling on Solaris?


Date: October 20, 1997


Many people have experienced compilation problems on Solaris, with
the compiler typically complaining about tm_zone or
TopFrame. The Solaris
section
of our Compiling Sendmail page
explains these.




Q5.1.6 -- How does 8.X compare to 8.X+Sun?


Date: August 29, 1998


With a Vn/Berkeley config file, they're identical.
There are a few minor differences between 8.X with a
Vn/Berkeley config file and 8.X+Sun
with the same config file, but the V line changed to
Vn/Sun. But most differences are the backwards
compatibility hacks needed for 8.X+Sun to support old
V1/Sun config files.


There are three web pages which discuss these in detail:
Berkeley migration
(from SMI-8.6 to 8.X),
Sun migration
(from SMI-8.6 to 8.X+Sun), and
Differences
(5 sections comparing and contrasting config files and binaries).




5.2 -- IBM AIX






Q5.2.1 -- The system resource controller always reports
sendmail as "inoperative". What's wrong?


Date: July 5, 1996


When I use version 8 sendmail on an IBM RS/6000 running AIX, the
system resource controller always reports sendmail as "inoperative",
even though it's actually running. What's wrong?


When running as a daemon, sendmail detaches from its parent
process, fooling the SRC into thinking that sendmail has exited. To
fix this, issue the commands:


kill `head -1 /etc/sendmail.pid`
chssys -s sendmail -f 9 -n 15 -S -a "-d99.100"
# use "-d0.1" in sendmail 8.6.x
startsrc -s sendmail -a "-bd -q30m"
# your sendmail args may vary

Now the SRC should report the correct status of sendmail. If you
are using version 8.6.x, use "-d0.1" instead of "-d99.100" (the debug
options changed somewhat in version 8.7). In 8.6.x a side-effect of
the "-d0.1" option is that a few lines of debug output will be printed
on the system console every time sendmail starts up.


For more information, read up on the System Resource Controller,
the lssrc command and the chssys command in the online AIX
documentation.




Q5.2.2 -- Why can't I use AIX to get email to some sites?


Date: April 8, 1997


When I use IBM's sendmail on an IBM RS/6000 running AIX trying to
get to certain sites, it seems that I can get to some of them and not
others. What's wrong?


There are two possible problems here:


1) Your version of sendmail is not configured to recognize MX
records in the DNS. Search through your sendmail.cf
looking for "OK MX" or "OK ALL". Older configurations had
this line commented out, and this will cause mail from you
to some sites to fail (because those sites have MX
records, but no A records in their DNS for the specific
Fully Qualified Domain Name you're trying to mail to).


For more information, see the comp.unix.aix FAQ
ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/.


2) There is a negative caching bug in AIX 3.2.5 with
/usr/sbin/named executables that are less than 103000
bytes long. Ask your IBM representative to give you PMP
3251, or the most recent patch that fixes this problem for
your particular configuration and version of the OS.




Q5.2.3 -- Why can't I get sendmail 8.7.1 to use MX records
with AIX 3.2.5?


Date: July 5, 1996


IBM, in their infinite wisdom, provided a header file that would
easily mis-compile. This resulted in the struct{} for the DNS query
to be mis-allocated, and MX processing would barf.


Fix 1) upgrade to 8.7.5 - this has a code fix for this problem.


Fix 2) Install the BIND 4.9.4 libraries and include files and
tweak the Makefile.AIX to use them - I *think* these Get It Right (if
not, at least it'll die during compile rather than failing weirdly at
runtime).


Fix 3) Hack Makefile.AIX to pass a -DBIT_ZERO_ON_LEFT to cause the
headers to use the right #ifdefs.

6. ADDITIONAL INFORMATION SOURCES (RFC 1807 bibliography format)






Q6 -- Additional information sources


Date: April 8, 1997


Updated: August 29, 1998


This probably isn't in strict RFC 1807 format, but I'm getting
closer. Unfortunately, the format detailed in RFC 1807 was never
intended to be used in this fashion, so I'm doing a bit of square-peg
fitting into round holes.


Note that the publisher ids that I've assigned should not be
misconstrued to imply that I have actually published all these
documents, it's just that I need some sort of reasonable entry for the
RFC 1807 "ID" field, and in lieu of information to the contrary
indicating what the actual publishers have registered, I have assigned
my own, independent, "third-party" IDs. Hopefully, the bibliographic
entries below make it obvious who the real publishers of the various
documents are.




6.1 Reference material devoted exclusively to sendmail



BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/reference/1
ENTRY:: March 23, 1996
TYPE:: Reference manual, available online in printable format
REVISION:: April 8, 1997; Updated "CONTACT" information
TITLE:: Sendmail Installation and Operation Guide
AUTHOR:: Allman, Eric
CONTACT:: Eric Allman <eric@Sendmail.ORG>
DATE:: November 19, 1995
PAGES:: 69
RETRIEVAL:: Contents of manual is in doc/op/op.ps of sendmail source
archive
KEYWORD:: version 8.7.5 sendmail
LANGUAGE:: English
NOTES:: {g|n}roff "me" macro format version is in doc/op/op.me
See: URL:http://www.sendmail.org/

ABSTRACT::


The documentation written by Eric Allman himself, comes with the
sendmail distribution. The file in doc/op/op.me (nroff "me" macro
format) may have a different number of pages depending on the type of
device it is printed on, etc....


Eric provides his free consulting in the form of continuing
development on sendmail, and occasional posts to comp.mail.sendmail.
Please don't be so rude as to ask him to provide further free
consulting directly to you. If you (or your company) are willing to
compensate him for his consulting time, he may be willing to listen.
At the very least, you should make sure you've exhausted all other
courses of action before resorting to adding another message to the
thousands he gets per day.



Check the sendmail home page 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.


END:: sendmail-faq//online/reference/1


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/1-56592-222-0
ENTRY:: March 23, 1996
REVISION:: April 8, 1997; Updated entire entry re: 2nd Ed.
TYPE:: Reference book, hardcopy
TITLE:: sendmail
AUTHOR:: Costales, Bryan
AUTHOR:: Allman, Eric
CONTACT:: Bryan Costales <bcx@BCX.COM>
O'Reilly & Associates, Inc.
103 Morris Street, Suite A
Sebastapol, CA 95472
Order by phone: 800-998-9938 (US/Canada inquiries)
800-889-8969 (US/Canada credit card orders)
707-829-0515 (local/overseas)
DATE:: January, 1997
PAGES:: 1021
COPYRIGHT:: Copyright (c) 1997 O'Reilly & Associates, Inc. All rights
reserved.
LANGUAGE:: English
NOTES:: See: URL:http://www.ora.com/catalog/sendmail2/

ABSTRACT::


The definitive reference for version 8 sendmail (specifically,
version 8.8). If you can have only one book on the subject of
sendmail, this one is it.


Bryan provides his consulting to the world in the form of his book,
unless you're willing to compensate him for his services as well.
Like Eric, you should make sure you've exhausted all other courses of
action before you spend any of his valuable time.


END:: sendmail-faq//book/ISBN/1-56592-222-0


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/1-55558-127-7
ENTRY:: March 23, 1996
TYPE:: Reference book, hardcopy
REVISION:: Sep 9, 1996; fixed typo
TITLE:: Sendmail: Theory and Practice
AUTHOR:: Avolio, Frederick M.
AUTHOR:: Vixie, Paul A.
CONTACT:: Fred Avolio <fma@al.org>, Paul Vixie <vix@al.org>
Digital Press
225 Wildwood Avenue
Woburn, MA 01801, USA
Ordering Info: voice 1 800 366 2665
fax 1 800 446 6520
DATE:: 1994
PAGES:: 262
COPYRIGHT:: Copyright (c) by 1995 Butterworth-Heinemann
LANGUAGE:: English
NOTES:: See: URL:http://www.vix.com/vix/smtap/

ABSTRACT::


Centers more on IDA sendmail (at least partly because version 8 didn't
exist when they began the book). Written more like a college
Sophomore or Junior level textbook.


While you'll probably never let the Costales book out of your grubby
little hands (especially if you do much work with version 8 sendmail),
this is a book you'll probably read once or maybe twice, learn some
very valuable things, but then likely put on a shelf and not read or
reference again (unless you have to write up a bibliographic entry for
it). Makes a better introduction to sendmail for management types,
especially if you don't want them getting their hands on too much
"dangerous" technical information. Also a *lot* smaller and less
imposing.


If possible, I recommend getting both, but if you can only get one,
get Costales unless you're going to be working exclusively with IDA
sendmail, in which case Avolio & Vixie will probably be more useful.


Note that Paul Vixie is extremely busy working on further development
of BIND, the Internet de facto standard program for serving the DNS,
upon which all Internet services depend, mail being only one of them.
Like Eric and Bryan, he's also very busy. Unless you're willing to
compensate him for his services, please let him get real work done.


END:: sendmail-faq//book/ISBN/1-55558-127-7




6.2 Reference material with chapters or sections on sendmail



BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/0-13-151051-7
ENTRY:: March 23, 1996
TYPE:: Reference book, hardcopy
REVISION:: May 23, 1996; Updated abstract.
TITLE:: Unix System Administration Handbook, Second Edition
AUTHOR:: Nemeth, Evi
AUTHOR:: Snyder, Garth
AUTHOR:: Seebass, Scott
AUTHOR:: Hein, Trent R.
CONTACT:: <sa-book@admin.com>
Prentice-Hall, Inc.
Upper Saddle River, New Jersey 07458
DATE:: January, 1995
PAGES:: 780
COPYRIGHT:: Copyright (c) 1995 by Prentice Hall PTR
LANGUAGE:: English
NOTES:: See: URL:http://www.admin.com/

ABSTRACT::


Still the best hands-on Unix System Administration book around.
Covers far more than just sendmail, but the sixty-four pages (pages
455-518 in the third printing) it does devote are very well written
and quite useful. Also provides a version of Rob Kolstad's
checksendmail script on the accompanying CD-ROM.


Note that Eric Allman and Marshall Kirk McKusick wrote the Foreword
for the Second Edition. This should give you at least an inkling as
to how essential this book is, even for experienced Unix
administrators.


END:: sendmail-faq//book/ISBN/0-13-151051-7


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/0-201-58629=0
ENTRY:: March 23, 1996
TYPE:: Reference book, hardcopy
REVISION:: March 27, 1996; Changed ID format to include ISBN,
moved URL to NOTES field from OTHER_ACCESS field,
also updated ABSTRACT
REVISION:: March 29, 1996; Updated ID, PAGES, COPYRIGHT, and ABSTRACT
TITLE:: Practical Internetworking With TCP/IP and UNIX
AUTHOR:: Carl-Mitchell, Smoot
AUTHOR:: Quarterman, John S.
CONTACT:: <tic@tic.com>
Addison Wesley Publishing Company
Computer Science & Engineering Division
One Jacob Way
Reading, MA 01867
USA
Orders: voice://800-822-6339 (USA)
fax://617-942-1117
DATE:: 1993
PAGES:: 476
COPYRIGHT:: Copyright (c) 1993 by Addison-Wesley Publishing
Company, Inc.
LANGUAGE:: English
NOTES:: See URL:http://heg-school.aw.com/cseng/authors/mitchell/
practical/practical.html

ABSTRACT::


Devotes 50 pages (most of chapter 8) to discussion of sendmail. As
far as TCP/IP networking books go that also happen to discuss
sendmail, it seems well-written and clear (better than I recall Hunt's
book being), but rather dated in the face of books devoted to the
topic and all the recent development activity in the sendmail
community. Forget about the references, though. The newest
sendmail-related reference listed is dated 1983, ten years before the
date on this book and most certainly wildly out-of-date now.


There are other books written on the subject of Internetworking with
TCP/IP (most notably Comer), but this particular book seems to have a
unique mix of theory (if perhaps a bit dated) and practical advice.
Other books tend to have lots of one or the other, or split their
theory and nitty-gritty details into separate books in a series (like
Comer).


Assuming that an update will be coming out soon, it probably deserves
a place on the shelf of most System or Network Administrators, right
next to _Internetworking with TCP/IP_ by Comer, _Managing Internet
Information Services_ by Liu, et. al., _DNS and BIND_ by Albitz and
Liu, _Unix System Administration_ by Nemeth, et. al., and last, but
certainly not least, _sendmail_ by Costales. However, it deserves
this place more because of the non-sendmail related material, as
opposed to what sendmail-related material there is.


END:: sendmail-faq//book/ISBN/0-201-58629-0


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/0-937175-82-X
ENTRY:: March 23, 1996
TYPE:: Reference book, hardcopy
REVISION:: April 8, 1997; updated URL in NOTES section
TITLE:: TCP/IP Network Administration
AUTHOR:: Hunt, Craig
CONTACT:: O'Reilly & Associates, Inc.
103 Morris Street, Suite A
Sebastapol, CA 95472
Order by phone: 800-998-9938 (US/Canada inquiries)
800-889-8969 (US/Canada credit card orders)
707-829-0515 (local/overseas)
DATE:: August, 1992
PAGES:: 502
LANGUAGE:: English
NOTES:: See: URL:http://www.ora.com/catalog/tcp/

ABSTRACT::


The book I learned sendmail from when there was no other book in print
that even mentioned the name.


Here primarily for historical purposes, especially with respect to the
sending of Internet mail and the DNS. Some of the other TCP/IP
networking stuff is relevant, but this book is getting more and more
dated as time goes by.


END:: sendmail-faq//book/ISBN/0-937175-82-X




6.3 Reference material on subjects related to sendmail



BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/1-56592-236-0
ENTRY:: March 23, 1996
TYPE:: Reference book, hardcopy
REVISION:: April 8, 1997; Updated entire entry for 2nd Ed.
TITLE:: DNS and BIND
AUTHOR:: Albitz, Paul
AUTHOR:: Liu, Cricket
CONTACT:: O'Reilly & Associates, Inc.
103 Morris Street, Suite A
Order by phone: 800-998-9938 (US/Canada inquiries)
800-889-8969 (US/Canada credit card orders)
707-829-0515 (local/overseas)
DATE:: January, 1997
PAGES:: 418
COPYRIGHT:: Copyright (c) 1997 O'Reilly & Associates, Inc. All rights
reserved.
LANGUAGE:: English
NOTES:: See: URL:http://www.ora.com/catalog/dns2/

ABSTRACT::


As definitive as Costales is on sendmail, this book is on the subject
of the Domain Name System (DNS) and the most common server software
for the DNS, namely BIND.


The second edition has been updated to reflect the changes in BIND
up through version 4.9.4, but even the first edition still stands the
test of time as the one book *every* DNS/Domain Administrator should
have on their shelf. The second edition is just that much better.


Since the sending of Internet mail is so very heavily dependant on
the DNS, it obviously also belongs on the shelf of any Postmaster
or System Administrator whose site does Internet email. That means
virtually every administrator of every site on the Internet.


END:: sendmail-faq//book/ISBN/1-56592-236-0


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/1-56592-153-4
ENTRY:: April 8, 1997
TYPE:: Reference book, hardcopy
TITLE:: Using & Managing UUCP
AUTHOR:: Ravin, Ed
AUTHOR:: O'Reilly, Tim
AUTHOR:: Dougherty, Dale
AUTHOR:: Todino, Grace
CONTACT:: O'Reilly & Associates, Inc.
103 Morris Street, Suite A
Order by phone: 800-998-9938 (US/Canada inquiries)
800-889-8969 (US/Canada credit card orders)
707-829-0515 (local/overseas)
DATE:: September, 1996
PAGES:: 424
LANGUAGE:: English
NOTES:: See: URL:http://www.ora.com/catalog/umuucp/

ABSTRACT::


Replaces _Managing UUCP and Usenet_ by Todino and O'Reilly as the
definitive book for using, installing, and managing UUCP.


The general assumption with version 8 sendmail is that virtually no
one uses UUCP to send email anymore, but if that assumption isn't true
for you, then you probably need this book.


END:: sendmail-faq//book/ISBN/1-56592-153-4




6.4 World-wide web index/resource pages on sendmail



BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/10
ENTRY:: March 23, 1996
TYPE:: Online sendmail index
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: comp.mail.sendmail FAQ Support Page
AUTHOR:: Knowles, Brad
CONTACT:: Brad Knowles <brad@etext.org>
OTHER_ACCESS:: URL:http://www.his.com/~brad/sendmail/
LANGUAGE:: English

ABSTRACT::


Support Page for this FAQ.


END:: sendmail-faq//online/index/10


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/17
ENTRY:: March 25, 1996
TYPE:: Online sendmail index
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: comp.mail.sendmail Most Frequently Asked Questions Support Page
AUTHOR:: Assman, Claus
CONTACT:: Claus Assmann <ca@informatik.uni-kiel.de>
OTHER_ACCESS:: URL:http://www.informatik.uni-kiel.de/~ca/email/english.html
LANGUAGE:: English

ABSTRACT::


Most Frequently Asked Questions on comp.mail.sendmail and their
answers. Also has some links to a few other resources.


END:: sendmail-faq//online/index/17


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/resources/22
ENTRY:: November 24, 1996
TITLE:: IICONS Sendmail Resources
AUTHOR:: Caloca, Paul
CONTACT:: Paul Caloca <pcaloca@iicons.com>
COPYRIGHT:: Copyright (c) 1996 Paul Caloca. All Rights Reserved.
OTHER_ACCESS:: URL:http://www.iicons.com/sendmail/index.html
LANGUAGE:: English

ABSTRACT::


Provides information on how to compile Sendmail and the NEWDB
db.1.85 for Solaris 2. Also has a section on which Sun patches
update Solaris 2 to BIND 4.9.3.


Has pointers to some non-Sun/Solaris sendmail resources, especially
including CERT Advisories related to sendmail.



END:: sendmail-faq//online/index/22




6.5 World-wide web index pages and other reference on Internet
email in general



BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/12
ENTRY:: March 23, 1996
TYPE:: Online general Internet email index
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: Internet Mail Consortium web site
CORP-AUTHOR:: Internet Mail Consortium
CONTACT:: <info@imc.org>
OTHER_ACCESS:: URL:http://www.imc.org/
LANGUAGE:: English

ABSTRACT::


If it has to do with Internet email, you'll probably find it here or a
link to it from here.


They have or have information on email-related Usenet FAQs, RFCs,
Internet Drafts (documents that are in the process of becoming RFCs),
IETF Working Groups, security standards, and are running a few
email-related mailing lists.


Tends to be focussed on the standards issues.


If you care about Internet email, you should make it your duty in life
to check this site frequently.


END:: sendmail-faq//online/index/12


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/13
ENTRY:: March 23, 1996
TYPE:: Online general Internet email index
REVISION:: August 20, 1996; Updated URL.
TITLE:: Email References
AUTHOR:: Wohler, Bill
CONTACT:: Bill Wohler <wohler@worldtalk.com>
OTHER_ACCESS:: URL:http://www.worldtalk.com/html/msg_resources/email_ref.html
LANGUAGE:: English

ABSTRACT::


The most exhaustive index site I know of for Internet email related
documents outside of the Internet Mail Consortium.


Also has pointers to other organizations that relate to Internet
email, such as the Electronic Messaging Association and the European
Electronic Messaging Association.


Tends to be focussed on the server and standards issues.


END:: sendmail-faq//online/index/13


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/14
ENTRY:: March 23, 1996
TYPE:: Online general Internet email index
REVISION:: June 28, 1996; Added acronym for SMTPRD
TITLE:: SMTP Resources Directory (SMTPRD)
AUTHOR:: Salamon, Andras
AUTHOR:: Knowles, Brad
CONTACT:: Andras Salamon <smtprd@dns.net>
OTHER_ACCESS:: URL:http://www.dns.net/smtprd/
LANGUAGE:: English

ABSTRACT::


Another good index site, but still very much in the early phases of
gestation. Based very heavily on the
DNS Resources Directory,
also by Andras Salamon.


A well-rounded site, for the amount of material it covers so far.


END:: sendmail-faq//online/index/14


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/15
ENTRY:: March 23, 1996
TYPE:: Online general Internet email index
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: E-Mail Web Resources
AUTHOR:: Wall, Matt
CONTACT:: Matt Wall <wall+@cmu.edu>
OTHER_ACCESS:: URL:http://andrew2.andrew.cmu.edu/cyrus/email/email.html
LANGUAGE:: English

ABSTRACT::


Another good index site, tends to be more focussed on client side and
LAN email packages. Also lists some email services, which no one else
that I've seen appears to have taken the time to catalog.


Excellent side-by-side feature comparison of various MUAs and their
compliance with various Internet protocols.


END:: sendmail-faq//online/index/15




6.6 Online tutorials for sendmail



BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/tutorial/9
ENTRY:: March 23, 1996
TYPE:: Online sendmail tutorial
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
REVISION:: August 29, 1998; updated URL.
TITLE:: Sendmail V8: A (Smoother) Engine Powers Network Email
AUTHOR:: Reich, Richard
CONTACT:: Richard Reich <richard@reich.com>
DATE:: February 8, 1996
COPYRIGHT:: Copyright (c) 1995 The McGraw-Hill Companies, Inc.
All Rights Reserved.
OTHER_ACCESS:: URL:http://www.networkcomputing.com/unixworld/tutorial/
008/008.txt.html
LANGUAGE:: English
NOTES:: UnixWorld Online: Tutorial: Article No. 008

ABSTRACT::


Good technical introduction. Some useful references. Notably does
not reference this FAQ as a place to get more information.


END:: sendmail-faq//online/article/9


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/tutorial/16
ENTRY:: March 23, 1996
TYPE:: Online sendmail tutorial
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: Sendmail -- Care and Feeding
AUTHOR:: Quinton, Reg
CONTACT:: Reg Quinton <reggers@julian.uwo.ca>
Computing and Communications Services
The University of Western Ontario
London, Ontario N6A 5B7
Canada
DATE:: March 24, 1992
OTHER_ACCESS:: URL:ftp://ftp.sterling.com/mail/sendmail/uwo-course/
sendmail.txt.Z
LANGUAGE:: English
NOTES:: Postscript version also available. See ftp://ftp.sterling.com/
mail/sendmail/uwo-course/sendmail.ps.Z

ABSTRACT::


Dated. Only here until I find better.


END:: sendmail-faq//online/tutorial/16


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/tutorial/21
ENTRY:: March 27, 1996
TYPE:: Online sendmail tutorial
REVISION:: August 29, 1998; updated URL.
TITLE:: Explosion in a Punctuation Factory
AUTHOR:: Bryan Costales
CONTACT:: Becca Thomas <editor@unixworld.com>
DATE:: January 1994
COPYRIGHT:: Copyright (c) 1995 The McGraw-Hill Companies, Inc.
All Rights Reserved.
OTHER_ACCESS:: URL:http://www.networkcomputing.com/unixworld/tutorial/
01/01.txt.html
LANGUAGE:: English

ABSTRACT::


Good introduction on how sendmail re-write rules work.


END:: sendmail-faq//online/article/21




6.7 Online archives of mailing lists and Usenet newsgroups,
relating to Internet email



BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/archive/18
ENTRY:: March 25, 1996
TYPE:: Online Usenet newgroup archive
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: DejaNews
OTHER_ACCESS:: URL:http://www.dejanews.com
LANGUAGE:: English
NOTES:: Archives/indexes only Usenet news.

ABSTRACT::


The first, and still most focussed, Usenet news archive/index site.
Others archive/index news as well as other things, but none that I've
seen do it better.


Go to "Power Search" then "Query Filter" if you wish to restrict the
newsgroups you search on to something like just comp.mail.sendmail and
not all newsgroups.


END:: sendmail-faq//online/archive/18


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/archive/19
ENTRY:: March 25, 1996
TYPE:: Online Usenet newgroup archive
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: AltaVista
OTHER_ACCESS:: URL:http://www.altavista.digital.com
LANGUAGE:: English
NOTES:: Archives/indexes Usenet news and World-wide web pages.

ABSTRACT::


One of the leading indexes of world-wide web pages, and their
archive/index of Usenet news is obviously secondary.


END:: sendmail-faq//online/archive/19


BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/archive/20
ENTRY:: March 25, 1996
TYPE:: Online Usenet newgroup archive
REVISION:: April 8, 1997; Additional information based on experience
TITLE:: InReference
OTHER_ACCESS:: URL:http://www.reference.com
LANGUAGE:: English

ABSTRACT::


Had promise to be the best Usenet news/publicly accessible mailing
list index/archive site in the world. The best minds that were
working on the project have since left, and the difference is
visible. You'll probably be happier with DejaNews instead.


END:: sendmail-faq//online/archive/20





7. THANKS!



Special thanks to:








Eric Allman
The core of the material here comes from his FAQ for version 8.6.9
sendmail. I couldn't even have gotten started were it not for him.
And if he hadn't written sendmail, there obviously wouldn't even
be a FAQ. Heck, there might not even be an Internet.
Paul Southworth
Provides FAQ posting services, useful comments on various sections, and the
mailclient-faq. I couldn't have kept doing this were it not for his help.
Ed Ravin
Virtually all the material regarding the use of sendmail on AIX is his,
and most of it has been carried over verbatim.


Thanks also to:


Neil Hoggarth, Andras Salamon, Johan Svensson, Christopher X.
Candreva, Bill Wohler, Matthew Wall, Henry W. Farkas, Claus
Assmann, Curt Sampson, Rebecca Lasher, Jim Davis, David
Keegel, Betty Lee, Alain Durand, Walter Schweizer, Christophe
Wolfhugel, Al Gilman, Valdis Kletnieks, John Gardiner Myers,
Paul DuBois, Adam Bentley, Dave Sill, Dave Wreski, Paul Caloca,
Eamonn Coleman, Michael Fuhr, Betty Lee, Derrell Lipman,
Era Eriksson, Richard Troxel, and the readers and posters of
comp.mail.sendmail.



Комментарии
Анонимно
Войти под своим именем


Ник:
Текст сообщения:
Введите код:  

Загрузка...
Поиск:
добавить сайт | реклама на портале | контекстная реклама | контакты Copyright © 1998-2020 <META> Все права защищены