340 lines
15 KiB
Plaintext
340 lines
15 KiB
Plaintext
Sendmail Version 8
|
|
Frequently Asked Questions
|
|
Version 8.3 of 4/14/94
|
|
|
|
|
|
This FAQ is specific to Version 8 of sendmail.
|
|
|
|
----------------------------------------------------------------------
|
|
* What are the differences between Version 8 and other versions?
|
|
|
|
See CHANGES-R5-R8 in the anonymous FTP directory.
|
|
----------------------------------------------------------------------
|
|
* What happened to sendmail 6.x and 7.x?
|
|
|
|
When I released a new version of sendmail, I changed it 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.
|
|
----------------------------------------------------------------------
|
|
* Where can I get Version 8?
|
|
|
|
Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail.
|
|
----------------------------------------------------------------------
|
|
* 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". 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 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.
|
|
----------------------------------------------------------------------
|
|
* 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 release.
|
|
|
|
This macro set is also available with newer versions of groff.
|
|
----------------------------------------------------------------------
|
|
* What books are available describing sendmail?
|
|
|
|
There is one book available devoted to sendmail, and
|
|
several books that have sendmail chapters.
|
|
|
|
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.
|
|
Costales, Allman, and Rickert, _Sendmail_. O'Reilly &
|
|
Associates.
|
|
|
|
Another book is due out "soon":
|
|
|
|
Avolio & Vixie, _Sendmail Theory and Practice_. Digital
|
|
Press (release date unknown).
|
|
----------------------------------------------------------------------
|
|
* 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 they will get most of the other person's
|
|
email.
|
|
|
|
So called "full names" are just 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.
|
|
|
|
Even worse is fuzzy matching in e-mail -- this can make good
|
|
addresses turn bad. For example, I'm currently (to the best
|
|
of my knowledge) the only ``Allman'' at Berkeley, so mail
|
|
sent to "Allman@Berkeley.EDU" should get to me. But if
|
|
another Allman ever appears, this address could suddenly
|
|
become ambiguous. I've 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. Mail services
|
|
should be unique.
|
|
----------------------------------------------------------------------
|
|
* 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.
|
|
----------------------------------------------------------------------
|
|
* 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.
|
|
----------------------------------------------------------------------
|
|
* I'm connected to the network via a SLIP 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.
|
|
----------------------------------------------------------------------
|
|
* How can I get sendmail to deliver local mail to $HOME/.mail
|
|
instead of into /usr/spool/mail (or /usr/mail)?
|
|
|
|
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.
|
|
I understand that "procmail" works well, although I haven't
|
|
used it myself.
|
|
|
|
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:/pub/hlfsd/{README.hlfsd,hlfsd.ps}.
|
|
----------------------------------------------------------------------
|
|
* 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 propogates 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".
|
|
----------------------------------------------------------------------
|
|
* 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 accros 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
|
|
----------------------------------------------------------------------
|
|
* 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 doesn't
|
|
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.
|
|
----------------------------------------------------------------------
|
|
* 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.
|
|
----------------------------------------------------------------------
|
|
* 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.
|
|
----------------------------------------------------------------------
|