732 lines
32 KiB
Plaintext
732 lines
32 KiB
Plaintext
Newsgroups: comp.mail.sendmail,comp.mail.misc,comp.mail.smail,comp.answers,news.answers
|
|
Subject: comp.mail.sendmail Frequently Asked Questions (FAQ)
|
|
From: brad@birch.ims.disa.mil (Brad Knowles)
|
|
Followup-to: comp.mail.sendmail
|
|
Summary: This posting contains a list of Frequently Asked Questions
|
|
(and their answers) about the program "sendmail", distributed
|
|
with many versions of Unix (and available for some other
|
|
operating systems). This FAQ is shared between
|
|
comp.mail.sendmail and the Sendmail V8 distribution. It should
|
|
be read by anyone who wishes to post to comp.mail.sendmail, or
|
|
anyone having questions about the newsgroup itself.
|
|
|
|
Archive-name: mail/sendmail-faq
|
|
Posting-Frequency: monthly (first Monday)
|
|
|
|
|
|
[The most recent copy of this document can be obtained via anonymous
|
|
FTP from rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
|
|
If you do not have access to anonymous FTP, you can retrieve it by
|
|
sending email to mail-server@rtfm.mit.edu with the command "send
|
|
usenet/news.answers/mail/sendmail-faq" in the message.]
|
|
|
|
|
|
|
|
Sendmail Version 8
|
|
Frequently Asked Questions
|
|
Last updated 9/17/95
|
|
|
|
|
|
This FAQ is specific to Version 8.6.10 of sendmail. Other questions,
|
|
particularly regarding compilation and configuration, are answered in
|
|
src/READ_ME and cf/README (found in the V8 sendmail distribution).
|
|
|
|
This is also the official FAQ for the Usenet newsgroup
|
|
comp.mail.sendmail.
|
|
|
|
======================================================================
|
|
BEFORE YOU GO ANY FURTHER
|
|
======================================================================
|
|
|
|
* What do you wish everyone would do before sending you mail or
|
|
posting to comp.mail.sendmail?
|
|
|
|
Read this FAQ completely. Read src/READ_ME and cf/README
|
|
completely. Read the books written to help with common
|
|
problems such as compilation and installation, configuration,
|
|
security issues, etc.... Ask themselves if their question
|
|
hasn't already been answered.
|
|
----------------------------------------------------------------------
|
|
* How can I be sure if this is the right place to look for answers
|
|
to my questions?
|
|
|
|
1. Do you know, for a fact, that the question is related to
|
|
sendmail V8?
|
|
|
|
2. Do you know, for a fact, that the question is related to an
|
|
older version of sendmail?
|
|
|
|
3. Is the question about a sendmail-like program (e.g., Smail,
|
|
Zmailer, MMDF, etc...)?
|
|
|
|
4. Is the question about an SMTP Gateway product for a LAN
|
|
mail package (e.g., cc:Mail, MS-Mail, WordPerfect
|
|
Office/GroupWise, etc...)?
|
|
|
|
If you answered "yes" to the question #1, then this is the
|
|
right place.
|
|
|
|
If you answered "yes" to questions #2 or #3, then you should
|
|
seriously consider upgrading to the most recent version of
|
|
sendmail V8.
|
|
|
|
For question #2, If you're going to continue using an older
|
|
version of sendmail, you may not find much help and will
|
|
probably get some responses that amount to "Get V8".
|
|
Otherwise, this is probably the best place to look for
|
|
answers.
|
|
|
|
If you answered "yes" to question #3 and are not going to
|
|
upgrade to sendmail V8, then this is probably not the right
|
|
place to look.
|
|
|
|
If you answered "yes" to question #4, then this is almost
|
|
certainly not the right place to look.
|
|
|
|
For questions #3 and #4, try looking around elsewhere in the
|
|
"comp.mail.*" hierarchy for a more appropriate newsgroup.
|
|
For example, you might want to try posting to comp.mail.misc
|
|
or comp.mail.smail.
|
|
|
|
If you couldn't answer "yes" to any of the above questions,
|
|
then you're DEFINITELY in the wrong place. For the sake of
|
|
your sanity and ego, not to mention avoiding the waste of
|
|
your time and ours, try asking your System or E-Mail
|
|
Administrator(s) before you post any questions publicly.
|
|
----------------------------------------------------------------------
|
|
* Where can I find the latest version of this FAQ?
|
|
|
|
It is included in the most recent Version 8 distribution of
|
|
sendmail (described below), as well as via anonymous FTP from
|
|
rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
|
|
If you do not have access to anonymous FTP, you can retrieve
|
|
it by sending email to mail-server@rtfm.mit.edu with the
|
|
command "send usenet/news.answers/mail/sendmail-faq" in the
|
|
message.
|
|
----------------------------------------------------------------------
|
|
* I don't have access to Usenet news. Can I still get access to
|
|
comp.mail.sendmail?
|
|
|
|
Yes. Send email to mxt@dl.ac.uk with the command "sub
|
|
comp-news.comp.mail.sendmail <full-US-ordered-email-address>"
|
|
in the message.
|
|
|
|
E-mail you want posted on comp.mail.sendmail should be sent
|
|
to comp-mail-sendmail@dl.ac.uk
|
|
----------------------------------------------------------------------
|
|
* I have sendmail-related DNS questions. Where should I ask them?
|
|
|
|
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 Info-BIND mailing list (if the question is
|
|
specific to that program) or to the Usenet newsgroup
|
|
comp.protocols.tcp-ip.domains (DNS in general).
|
|
----------------------------------------------------------------------
|
|
* How do I subscribe to either of these?
|
|
|
|
For comp.protocols.tcp-ip.domains, you have to be on Usenet.
|
|
They don't have a news-to-mail gateway yet.
|
|
|
|
For the Info-BIND mailing list, send email to
|
|
bind-request@uunet.uu.net with the command "subscribe" in the
|
|
message. Submissions should be sent to bind@uunet.uu.net
|
|
|
|
======================================================================
|
|
GENERAL QUESTIONS
|
|
======================================================================
|
|
|
|
* Where can I get Version 8?
|
|
|
|
Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail.
|
|
----------------------------------------------------------------------
|
|
* What are the differences between Version 8 and other versions?
|
|
|
|
See doc/changes/changes.me in the sendmail distribution.
|
|
----------------------------------------------------------------------
|
|
* What happened to sendmail 6.x and 7.x?
|
|
|
|
When a new (Alpha/Beta) version of sendmail was released, it
|
|
was changed to Release 6. Development continued in that tree
|
|
until 4.4BSD was released, when everything on the 4.4 tape
|
|
was set to be version 8.1. Version 7.x never existed.
|
|
----------------------------------------------------------------------
|
|
* What books are available describing sendmail?
|
|
|
|
There is one book available devoted to sendmail:
|
|
|
|
Costales, Allman, and Rickert, _Sendmail_. O'Reilly &
|
|
Associates.
|
|
|
|
Several books have sendmail chapters, for example:
|
|
|
|
Nemeth, Snyder, and Seebass, _Unix System Administration
|
|
Handbook_. Prentice-Hall.
|
|
Carl-Mitchell and Quarterman, _Practical Internetworking with
|
|
TCP/IP and UNIX_. Addison-Wesley.
|
|
Hunt, _TCP/IP Network Administration_. O'Reilly & Associates.
|
|
|
|
Another book about sendmail is due out "soon":
|
|
|
|
Avolio & Vixie, _Sendmail Theory and Practice_. Digital
|
|
Press (release date unknown).
|
|
|
|
For details on sendmail-related DNS issues, consult:
|
|
|
|
Liu and Albitz, _DNS and BIND_. O'Reilly & Associates.
|
|
|
|
For details on UUCP, see:
|
|
|
|
O'Reilly and Todino, _Managing UUCP and Usenet_.
|
|
O'Reilly & Associates.
|
|
|
|
======================================================================
|
|
COMPILING AND INSTALLING SENDMAIL 8
|
|
======================================================================
|
|
|
|
* Version 8 requires a new version of "make". Where can I get this?
|
|
|
|
Actually, Version 8 does not require a new version of "make".
|
|
It includes a collection of Makefiles for different architectures,
|
|
only one or two of which require the new "make". For a supported
|
|
architecture, use ``sh makesendmail''. If you are porting to a
|
|
new architecture, start with Makefile.dist.
|
|
|
|
If you really do want the new make, it is available on any of
|
|
the BSD Net2 or 4.4-Lite distribution sites. These include:
|
|
|
|
ftp.uu.net /systems/unix/bsd-sources
|
|
gatekeeper.dec.com /.0/BSD/net2
|
|
ucquais.cba.uc.edu /pub/net2
|
|
ftp.luth.se /pub/unix/4.3bsd/net2
|
|
|
|
Diffs and instructions for building this version of make
|
|
under SunOS 4.1.x are available on ftp.css.itd.umich.edu in
|
|
/pub/systems/sun/Net2-make.sun4.diff.Z. A patchkit for
|
|
Ultrix is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z.
|
|
Patches for AIX 3.2.4 are available on ftp.uni-stuttgart.de
|
|
in /sw/src/patches/bsd-make-rus-patches.
|
|
|
|
There is also a Linux version available on the main Linux
|
|
distribution sites as pmake; this version is included as
|
|
standard with the current Slackware distributions.
|
|
----------------------------------------------------------------------
|
|
* What macro package do I use to format the V8 man pages?
|
|
|
|
The BSD group switched over the the ``mandoc'' macros for the
|
|
4.4 release. These include more hooks designed for hypertext
|
|
handling. However, new man pages won't format under the old
|
|
man macros. Fortunately, old man pages will format under the
|
|
new mandoc macros.
|
|
|
|
Get the new macros with the BSD Net2 or 4.4-Lite release (see
|
|
above for locations; for example, on FTP.UU.NET the files
|
|
/system/unix/bsd-sources/share/tmac/me/strip/sed and
|
|
/system/unix/bsd-sources/share/tmac/* are what you need).
|
|
|
|
This macro set is also included with newer versions of groff.
|
|
----------------------------------------------------------------------
|
|
* What modes should be used when installing sendmail?
|
|
|
|
The sendmail binary should be owned by root, mode 4755.
|
|
The queue directory should be owned by root, with a mode
|
|
between 700 and 755. Under no circumstances should
|
|
it be group or other writable!
|
|
The sendmail config file should be owned by root, mode 644.
|
|
The aliases file should generally be owned by one trusted
|
|
user and writable only by that user, although it is
|
|
not unreasonable to have it group writable by a
|
|
"sysadmin" group. It should not be world writable.
|
|
The aliases database files (aliases.db or aliases.{pag,dir}
|
|
depending on what database format you compile with)
|
|
should be owned by root, mode 644.
|
|
|
|
======================================================================
|
|
CONFIGURATION QUESTIONS
|
|
======================================================================
|
|
|
|
* How do I make all my addresses appear to be from a single host?
|
|
|
|
Using the V8 configuration macros, use:
|
|
|
|
MASQUERADE_AS(my.dom.ain)
|
|
|
|
This will cause all addresses to be sent out as being from
|
|
the indicated domain.
|
|
----------------------------------------------------------------------
|
|
* How do I rewrite my From: lines to read ``First_Last@My.Domain''?
|
|
|
|
There are a couple of ways of doing this. This describes
|
|
using the "user database" code. This is still experimental,
|
|
and was intended for a different purpose -- however, it does
|
|
work with a bit of care. It does require that you have the
|
|
Berkeley "db" package installed (it won't work with DBM).
|
|
|
|
First, create your input file. This should have lines like:
|
|
|
|
loginname:mailname First_Last
|
|
First_Last:maildrop loginname
|
|
|
|
Install it in (say) /etc/userdb. Create the database:
|
|
|
|
makemap btree /etc/userdb.db < /etc/userdb
|
|
|
|
You can then create a config file that uses this. You will
|
|
have to include the following in your .mc file:
|
|
|
|
define(confUSERDB_SPEC, /etc/userdb.db)
|
|
FEATURE(notsticky)
|
|
----------------------------------------------------------------------
|
|
* So what was the user database feature intended for?
|
|
|
|
The intent was to have all information for a given user
|
|
(where the user is the unique login name, not an inherently
|
|
non-unique full name) in one place. This would include phone
|
|
numbers, addresses, and so forth. The "maildrop" feature is
|
|
because Berkeley does not use a centralized mail server
|
|
(there are a number of reasons for this that are mostly
|
|
historic), and so we need to know where each user gets his or
|
|
her mail delivered -- i.e., the mail drop.
|
|
|
|
We are in the process of setting up our 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.
|
|
----------------------------------------------------------------------
|
|
* Why are you so hostile to using full names for e-mail addresses?
|
|
|
|
Because full names are not unique. For example, the computer
|
|
community has two Andy Tannenbaums and two Peter Deutsches.
|
|
At one time, Bell Labs had two Stephen R. Bournes with
|
|
offices a few doors apart. You can create alternative
|
|
addresses (e.g., Stephen_R_Bourne_2), but that's even worse
|
|
-- which one of them has to have their name desecrated in
|
|
this way? And you can bet that one of them will get most of
|
|
the other person's e-mail.
|
|
|
|
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 e-mail -- 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.
|
|
|
|
Finger services should be as fuzzy as possible (within
|
|
reason, of course). Mail services should be unique.
|
|
----------------------------------------------------------------------
|
|
* Should I use a wildcard MX for my domain?
|
|
|
|
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 "config error: mail loops back to myself"
|
|
errors.
|
|
|
|
See RFCs 1535-1537 for more detail and other related (or
|
|
common) problems.
|
|
----------------------------------------------------------------------
|
|
* How can I get sendmail to process messages sent to an account and
|
|
send the results back to the originator?
|
|
|
|
This is a local mailer issue, not a sendmail issue.
|
|
Depending on what you're doing, look at procmail (mentioned
|
|
again below), ftpmail, or Majordomo.
|
|
|
|
Check your local archie server to see what machine(s) nearest
|
|
you have the most recent versions of these programs.
|
|
----------------------------------------------------------------------
|
|
* How can I get sendmail to deliver local mail to $HOME/.mail
|
|
instead of into /usr/spool/mail (or /usr/mail)?
|
|
|
|
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", 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). This is also available via public FTP from
|
|
ftp.cs.columbia.edu in /pub/hlfsd/{README.hlfsd,hlfsd.ps}.
|
|
----------------------------------------------------------------------
|
|
* I'm trying to to get my mail to go into queue only mode, and it
|
|
delivers the mail interactively anyway. (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.
|
|
----------------------------------------------------------------------
|
|
* There are four UUCP mailers listed in the configuration files.
|
|
Which one should I use?
|
|
|
|
The choice is partly a matter of local preferences and what
|
|
is running at the other end of your UUCP connection. Unlike
|
|
good protocols that define what will go over the wire, UUCP
|
|
uses the policy that you should do what is right for the
|
|
other end; if they change, you have to change. This makes it
|
|
hard to do the right thing, and discourages people from
|
|
updating their software. In general, if you can avoid UUCP,
|
|
please do.
|
|
|
|
If you can't avoid it, you'll have to find the version that
|
|
is closest to what the other end accepts. Following is a
|
|
summary of the UUCP mailers available.
|
|
|
|
uucp-old (obsolete name: "uucp")
|
|
This is the oldest, the worst (but the closest to UUCP) way
|
|
of sending messages across UUCP connections. It does
|
|
bangify everything and prepends $U (your UUCP name) to the
|
|
sender's address (which can already be a bang path
|
|
itself). It can only send to one address at a time, so it
|
|
spends a lot of time copying duplicates of messages. Avoid
|
|
this if at all possible.
|
|
|
|
uucp-new (obsolete name: "suucp")
|
|
The same as above, except that it assumes that in one rmail
|
|
command you can specify several recipients. It still has a
|
|
lot of other problems.
|
|
|
|
uucp-dom
|
|
This UUCP mailer keeps everything as domain addresses.
|
|
Basically, it uses the SMTP mailer rewriting rules.
|
|
|
|
Unfortunately, a lot of UUCP mailer transport agents
|
|
require bangified addresses in the envelope, although you
|
|
can use domain-based addresses in the message header. (The
|
|
envelope shows up as the From_ line on UNIX mail.) So....
|
|
|
|
uucp-uudom
|
|
This is a cross between uucp-new (for the envelope
|
|
addresses) and uucp-dom (for the header addresses). It
|
|
bangifies the envelope sender (From_ line in messages)
|
|
without adding the local hostname, unless there is no host
|
|
name on the address at all (e.g., "wolf") or the host
|
|
component is a UUCP host name instead of a domain name
|
|
("somehost!wolf" instead of "some.dom.ain!wolf").
|
|
|
|
Examples:
|
|
|
|
We are on host grasp.insa-lyon.fr (UUCP host name "grasp").
|
|
The following summarizes the sender rewriting for various
|
|
mailers.
|
|
|
|
Mailer sender rewriting in the envelope
|
|
------ ------ -------------------------
|
|
uucp-{old,new} wolf grasp!wolf
|
|
uucp-dom wolf wolf@grasp.insa-lyon.fr
|
|
uucp-uudom wolf grasp.insa-lyon.fr!wolf
|
|
|
|
uucp-{old,new} wolf@fr.net grasp!fr.net!wolf
|
|
uucp-dom wolf@fr.net wolf@fr.net
|
|
uucp-uudom wolf@fr.net fr.net!wolf
|
|
|
|
uucp-{old,new} somehost!wolf grasp!somehost!wolf
|
|
uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr
|
|
uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf
|
|
|
|
======================================================================
|
|
RESOLVING PROBLEMS
|
|
======================================================================
|
|
|
|
* When I compile, I get "undefined symbol inet_aton" messages.
|
|
|
|
You've probably replaced your resolver with the version from
|
|
BIND 4.9.3. You need to compile with -l44bsd in order to get
|
|
the additional routines.
|
|
----------------------------------------------------------------------
|
|
* I'm getting "Local configuration error" messages, such as:
|
|
|
|
553 relay.domain.net config error: mail loops back to myself
|
|
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: Be sure you kill and restart the sendmail daemon
|
|
after you change the configuration file (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!
|
|
----------------------------------------------------------------------
|
|
* 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") on the sendmail distribution
|
|
for a full discussion of how to do this.
|
|
----------------------------------------------------------------------
|
|
* 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 sendmail V8 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:
|
|
|
|
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 you have installed sendmail V8 in /usr/local/lib.
|
|
----------------------------------------------------------------------
|
|
* When I use sendmail V8 on an IBM RS/6000 running AIX, the system
|
|
resource controller always reports sendmail as "inoperative" even
|
|
though it is running. What's wrong?
|
|
|
|
IBM's system resource controller is one of their "value
|
|
added" features to AIX -- it's not a Unix standard. You'll
|
|
need to either redefine the subsystem to use signals (see
|
|
chssys(1)) or dump the entire subsystem and invoke sendmail
|
|
in /etc/rc.tcpip or some other boot script.
|
|
----------------------------------------------------------------------
|
|
* When I use sendmail V8 on an Intel x86 machine running Linux, I
|
|
have some problems. Specifically, I have....
|
|
|
|
The current versions of Linux are generally considered to be
|
|
great for hobbyists and anyone else who wants to learn Unix
|
|
inside and out, or wants to always have something to do, or
|
|
wants a machine for light-duty mostly personal use and not
|
|
high-volume multi-user purposes.
|
|
|
|
However, for those who want a system that will just sit in
|
|
the background and work without a fuss handling thousands of
|
|
mail messages a day for lots of different users, it's not
|
|
(yet) stable enough to fit the bill.
|
|
|
|
Unfortunately, there are no known shareware/freeware
|
|
implementations of any operating system that provides the
|
|
level of stability necessary to handle that kind of load
|
|
(i.e., there are no free lunches).
|
|
|
|
If you're wedded to the Intel x86 platform and want to run
|
|
sendmail, we suggest you look at commercial implementations
|
|
of Unix such as Interactive, UnixWare, Solaris, or BSD/386
|
|
(just a sample of the dozens of different versions of Unix
|
|
for Intel x86).
|
|
|
|
Of all known vendor supported versions of Unix for Intel x86,
|
|
BSDI's BSD/386 is least expensive and the only one known to
|
|
currently ship with sendmail V8 pre-installed. Since sendmail
|
|
V8 is continuing to be developed at UC Berkeley, and BSD/386
|
|
is a full BSD 4.4 implementation, this is obviously be the most
|
|
"native" sendmail V8 environment.
|
|
----------------------------------------------------------------------
|
|
* When I use sendmail on an Intel x86 machine running OS/2, I have
|
|
some problems. Specifically, I have....
|
|
|
|
The OS/2 port of sendmail is known to have left out huge
|
|
chunks of the code and functionality of even much older
|
|
versions of sendmail, in large part because the underlying OS
|
|
just doesn't have the necessary hooks to make it happen.
|
|
This port is so broken that we make no attempt to provide any
|
|
kind of support for it. Try BSDI's BSD/386 instead.
|
|
----------------------------------------------------------------------
|
|
* 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.
|
|
----------------------------------------------------------------------
|
|
* I just upgraded to 8.x and suddenly I'm getting messages in my
|
|
syslog of the form "collect: I/O error on connection". What is
|
|
going wrong?
|
|
|
|
Nothing. 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.
|
|
----------------------------------------------------------------------
|
|
* I just upgraded to 8.x and now when my users try to forward their
|
|
mail to a program they get an "illegal shell" 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, 8.x 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.
|
|
----------------------------------------------------------------------
|
|
* I just upgraded to 8.x 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 V8 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, set the IDENT timeout to zero using
|
|
``OrIdent=0'' in the configuration file. This will
|
|
completely disable all use of the IDENT protocol.
|
|
|
|
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 (usually
|
|
called something like "/var/namedb/root.cache"; see your
|
|
/etc/named.boot file to get your value) are up to date.
|
|
Either of these can cause long delays.
|
|
----------------------------------------------------------------------
|
|
* I just upgraded to 8.x 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 -- otherwise the
|
|
configurations use a default that probably disagrees with
|
|
your local mail system. See cf/README for details.
|
|
----------------------------------------------------------------------
|
|
* Under V8, the "From " header gets mysteriously munged when I send
|
|
to an alias.
|
|
|
|
``It's not a bug, it's a feature.'' This happens when you
|
|
have a "owner-list" alias and you send to "list". V8
|
|
propagates the owner information into the envelope sender
|
|
field (which appears as the "From " header on UNIX mail or as
|
|
the Return-Path: header) so that downstream errors are
|
|
properly returned to the mailing list owner instead of to the
|
|
sender. In order to make this appear as sensible as possible
|
|
to end users, I recommend making the owner point to a
|
|
"request" address -- for example:
|
|
|
|
list: :include:/path/name/list.list
|
|
owner-list: list-request
|
|
list-request: eric
|
|
|
|
This will make message sent to "list" come out as being "From
|
|
list-request" instead of "From eric".
|
|
----------------------------------------------------------------------
|
|
* I am trying to use MASQUERADE_AS (or the user database) to
|
|
rewrite from addresses, and although it works in the From: header
|
|
line, it doesn't work in the envelope (e.g., the "From " line).
|
|
|
|
Believe it or not, this is intentional. The interpretation
|
|
of the standards by the V8 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. Other people have since described scenarios
|
|
where the envelope cannot be correct without this rewriting,
|
|
so 8.7 will have an option to rewrite both header and
|
|
envelope.
|
|
----------------------------------------------------------------------
|
|
* I want to run Sendmail version 8 on my DEC system, but you don't
|
|
have MAIL11V3 support in sendmail. How do I handle this?
|
|
|
|
Get Paul Vixie's reimplementation of the mail11 protocol from
|
|
gatekeeper.dec.com in /pub/DEC/gwtools.
|
|
|
|
Rumour has it that he will be fully integrating into sendmail
|
|
V8 what little is left of IDA sendmail that is not handled
|
|
(or handled as well) by V8. No additional information on
|
|
this project is currently available.
|
|
----------------------------------------------------------------------
|
|
* Messages seem to disappear from my queue unsent. When I look in
|
|
the queue directory I see that they have been renamed from qf* to
|
|
Qf*, and sendmail doesn't see these.
|
|
|
|
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.
|
|
----------------------------------------------------------------------
|
|
@(#)FAQ 8.16 (Berkeley) 9/17/95
|
|
Send updates to sendmail@sendmail.ORG.
|