TheLib.Ru » ОС и Сети » Автор неизвестен » Sendmail FAQ (Updated 29-aug-1998 » онлайн-чтение (стр. 1)

 

 

---------------------------------------------------------------
Origin: 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





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.


http://www.sendmail.org/faq/.


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


comp.protocols.tcp-ip.domains
(DNS in general) or to the Info-BIND mailing list (if the question is
specific to that program).


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




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.


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.


<!-- no longer true, is it?
-- Current releases of sendmail can also be found at
-- ftp://ftp.cs.berkeley.edu/ucb/src/sendmail/ . -->


There are no other known official version 8 sendmail mirrors.


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


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


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


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.


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


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.


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





Masquerading and Relaying page.


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