- How do I make all my addresses to appear to be from a single host?
- How do I rewrite my From: lines to read "First_Last@My.Domain" or "Different_Name@My.Domain"?
- But what about fully qualified addresses, such as those from Pine of FEATURE(always_add_domain)?
- So what was the user database database featured intended for?
- Why the hostility toward using full names for email addresses?
- deprecated
- How do I manage several (virtual) domains?
- There are four UUCP mailers listed in the configuration files. Which one should I use?
- depcreated
- How do I solve "collect: I/O error on connection" or "reply: read error from host.name" errors?
- Why can't my users forward their mail to a program?
- Why do connections to the SMTP port take such a long time?
- Why do I get "unknown mailer error 5 -- mail: options MUST PRECEDE recipients" errors?
- Why does version 8 sendmail panic my SunOS box?
- Why does the Unix From line get mysteriously munged when I send to an alias?
- Why doesn't MASQUERADE_AS (or the user database) work for envelope addresses as well as header addresses?
- How do I run version 8 sendmail and support the MAIL11V3 protocol?
- Why do messages disappear from my queue unsent?
- When is sendmail going to support RFC 2047 MIME header encoding?
- Why can't I get mail to some places, but instead always get the error "reply: read error from name.of.remote.host"?
- Why doesn't "FEATURE(xxx)" work?
- How do I configure sendmail not to use DNS?
- How do I get all my queued mail delivered to my Unix box from my ISP?
- Why do I get the error message
unable to write /etc/mail/sendmail.pid?
- Why can't I compile sendmail with Berkeley DB 2.X?
- What operating systems has Berkeley sendmail been ported to?
- How do I prevent Relaying Denied errors for my clients?
- Why isn't virtual hosting working, even after I added a
Kvirtuser to sendmail.cf?
- How can I add a header specifying the actual recipient when having multiple users in a virtual domain go to a single mailbox?
- What do I do when
Build fails because groff was not found?
- What does "
class hash not available" mean?
- How do I configure majordomo with sendmail 8.9 without relaxing the
DontBlameSendmail option?
- How do I configure my system in general with sendmail 8.9?
- What does "
foo not available for sendmail programs" mean?
- How do I add a footer/signature to all (outgoing) e-email messages?
- What does "
Cannot open hash database ... Invalid argument" mean?
- What does "
parse error before `NDBM'" mean?
- What does "
may be forged" mean?
- How do I send using an alternate port?
- Why can't I use BerkeleyDB 4.1.x?
- How do I use CIDR notation in the access map (or other places)?
- Why isn't CIRD notation directly supported by sendmail?
- What does "Need to recompile with -DNEWDB for hash support" mean?
- I disabled sendmail on some machines which don't receive mail, but since upgrading to 8.12 they can't send mail either; why?
How do I make all my addresses to appear to be from a single host?
This question is answered in detail at the configuration Masquerading and Relaying page
How do I rewrite my From: lines to read "First_Last@My.Domain" or "Different_Name@My.Domain"?
Use the generics table, as described in steps 6 and 7 of the
Virtual Hosting
page.
But what about fully qualified addresses, such as those from Pine of FEATURE(always_add_domain)?
Note: this question used to be "How do I get the user database
to work with Pine or with FEATURE(always_add_domain)?" But the
user database is no longer the recommended solution for this
problem, so the question has been clarified appropriately.
The proper solution is to use the generics table, as described in steps 6 and 7 of the Virtual Hosting page. The
important thing to note is that the host/domain part of the
fully-qualified address must be specified via
GENERICS_DOMAIN() or
GENERICS_DOMAIN_FILE().
So what was the user database database featured intended for?
The intent was to have all information for a given user (where
the user is the unique login name, not an inherently non-unique
full name) in one place. This would include phone numbers,
addresses, and so forth. The "maildrop" feature is because
Berkeley does not use a centralized mail server (there are a
number of reasons for this that are mostly historic), and so we
need to know where each user gets his or her mail delivered --
i.e., the mail drop.
UC Berkeley is (was) in the process of setting up their
environment so that mail sent to an unqualified "name" goes to
that person's preferred maildrop; mail sent to "name@host" goes
to that host. The purpose of "FEATURE(notsticky)" is to cause
"name@host" to be looked up in the user database for delivery to
the maildrop.
Why the hostility toward using full names for email addresses?
Because full names are not unique. For example, the computer
community has 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. Moreover, at institutions with high
turnover (such as universities), a given name may refer to
different people at different times, which can again lead to mail
going to the wrong person.
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).
The problem is even worse outside of America, where non-ASCII characters (e.g., characters with umlauts or the Norwegian Ø) are used in names. Since non-ASCII characters cannot be used in the SMTP envelope or e-mail headers, the full names are mangled anyway.
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.
How do I manage several (virtual) domains?
This question is answered in detail at the Virtual Hosting page.
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.
How do I solve "collect: I/O error on connection" or "reply: read error from host.name" errors?
If you are just getting occasional such messages, they're probably due to a temporary network problem, or the remote host crashing or otherwise abruptly terminating the connection. If you are getting a lot of these from a single host, there is probably some incompatibility between 8.x and that host (see Q3.12 and Q3.20). 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.
Another possibility is that you have a router/firewall filtering out all incoming ICMP messages, while your OS is doing "Path MTU discovery" (e.g. modern TCP/IP stacks do this by default). Path MTU discovery relies on certain ICMP messages being allowed through back to the host originating the traffic - see our tip on Path MTU Discovery and RFC 1191 for the details.
Lastly, here is part of a post from comp.mail.sendmail about a SCO 7.1.0 specific bug which may produce similar problems.
Subject: Re: Recipient mail server times out sendmail connection
Date: 5 Jun 2002 21:37:02 -0700
From: maillist@screamingplants.com (ike)
I ran a packet sniffer on mail traffic that was causing
problems and found that the tcp checksums for large packets
were all off by 14. I found out later that there is a network
bug in the OS (SCO 7.1.0). After applying a few patches, the
problem appears to have been resolved.
Why can't my users forward their mail to a program?
I just upgraded to version 8 sendmail and now when my users
try to forward their mail to a program they get an "illegal
shell" or "cannot mail to programs" message and their mail is not
delivered. What's wrong?
In order for people to be able to run a program from their
.forward file, version 8 sendmail insists that their shell (that
is, the shell listed for that user in the passwd entry) be a
"valid" shell, meaning a shell listed in /etc/shells. If
/etc/shells does not exist, a default list is used, typically
consisting of /bin/sh and /bin/csh.
This is to support environments that may have NFS-shared
directories mounted on machines on which users do not have login
permission. For example, many people make their file server
inaccessible for performance or security reasons; although users
have directories, their shell on the server is
/usr/local/etc/nologin or some such. If you allowed them to run
programs anyway you might as well let them log in.
If you are willing to let users run programs from their
.forward file even though they cannot telnet or rsh in (as might
be reasonable if you run smrsh to control the list of programs
they can run) then add the line:
/SENDMAIL/ANY/SHELL/
to /etc/shells. This must be typed exactly as indicated, in
caps, with the trailing slash.
NOTA BENE: DO NOT list /usr/local/etc/nologin in /etc/shells
-- this will open up other security problems.
IBM AIX does not use /etc/shells -- a list of allowable login
shells is contained, along with many other login parameters, in
/etc/security/login.cfg. You can copy the information in the
"shells=" stanza into a /etc/shells on your system so sendmail
will have something to use. Do NOT add "/usr/lib/uucp/uucico" or
any other non-login shell into /etc/shells.
Also note that there are some weird things that AFS throws
into the mix, and these can keep a program from running or
running correctly out of .forward files or the system-wide
aliases.
See also "smrsh" in Q2.13 and Q3.34, and "directory permissions" in Q3.33.
Why do connections to the SMTP port take such a long time?
I just upgraded to version 8 sendmail and suddenly connections
to the SMTP port take a long time. What is going wrong?
It's probably something weird in your TCP implementation that
makes the IDENT code act oddly. On most systems version 8
sendmail tries to do a ``callback'' to the connecting host to get
a validated user name (see RFC 1413 for detail). If the
connecting host does not support such a service it will normally
fail quickly with "Connection refused", but certain kinds of
packet filters and certain TCP implementations just time out.
To test this (pre-8.7.y sendmail), set the IDENT timeout to zero using:
define(`confREAD_TIMEOUT',`Ident=0')dnl
in the .mc file used by m4 to generate your sendmail.cf file.
Alternatively, if you don't use m4, you can put ``OrIdent=0'' in
the configuration file (we recommend the m4 solution, since that
makes maintenance much easier for people who don't understand
sendmail re-write rules, or after you've been away from it for a
while). Either way, this will completely disable all use of the
IDENT protocol.
For version 8.7.y sendmail (and above), you should instead use:
define(`confTO_IDENT',`0s')dnl
Another possible problem is that you have your name server
and/or resolver configured improperly. Make sure that all
"nameserver" entries in /etc/resolv.conf point to functional
servers. If you are running your own server, make certain that
all the servers listed in your root cache are up to date (this
file is usually called something like "/var/namedb/root.cache";
see your /etc/named.boot file to get your value). Either of these
can cause long delays.
You may also wish to check out our tips on how to set up DNS for your private address space.
Why do I get "unknown mailer error 5 -- mail: options MUST PRECEDE recipients" errors?
I just upgraded to version 8 sendmail and suddenly I get
errors such as ``unknown mailer error 5 -- mail: options MUST
PRECEDE recipients.'' What is going wrong?
You need OSTYPE(systype) in your .mc file, where "systype" is set correctly for your hardware & OS combination -- otherwise the configurations use a default that probably disagrees with your local mail system. See 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.
Why does version 8 sendmail panic my SunOS box?
Sendmail 8.7.y panics SunOS 4.1.3_U1 (at least for 1 <= y
<= 3) and SunOS 4.1.3, and sendmail 8.6.x seems fine on both
machines (at least for 9 <= x <= 12).
The problem is that a kernel patch is missing, specifically
100584-08 (4.1.3), 102010-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).
Why does the Unix From line get mysteriously munged when I send to an alias?
"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".
Why doesn't MASQUERADE_AS (or the user database)
work for envelope addresses as well as header
addresses?
Believe it or not, this is intentional. The interpretation of
the standards by the version 8 sendmail development group was
that this was an inappropriate rewriting, and that if the
rewriting were incorrect at least the envelope would contain a
valid return address.
If you're using version 8.7.y sendmail (or later), you can
use
FEATURE(masquerade_envelope)
in your sendmail.mc file to change this behavior. This is discussed in greater detail at the configuration Masquerading and Relaying page.
How do I run version 8 sendmail and support the
MAIL11V3 protocol?
Get the reimplementation of the mail11 protocol by Keith Moore from ftp://gatekeeper.dec.com/pub/misc/vixie/ (with contributions from Paul Vixie).
Why do messages disappear from my queue unsent?
When I look in the queue directory I see that qf* files have
been renamed to Qf*, and sendmail doesn't see these. What's
wrong?
If you look closely you should find that the Qf files are
owned by users other than root. Since sendmail runs as root it
refuses to believe information in non-root-owned qf files, and it
renames them to Qf to get them out of the way and make it easy
for you to find. The usual cause of this is twofold: first, you
have the queue directory world writable (which is probably a
mistake -- this opens up other security problems) and someone is
calling sendmail with an "unsafe" flag, usually a -o flag that
sets an option that could compromise security. When sendmail sees
this it gives up setuid root permissions.
The usual solution is to not use the problematic flags. If you
must use them, you have to write a special queue directory and
have them processed by the same uid that submitted the job in the
first place.
When is sendmail going to support RFC 2047 MIME header encoding?
This is considered to be a MUA issue rather than an MTA
issue.
Quoth Eric Allman:
The primary reason is that the information necessary to do the
encoding (that is, 8->7 bit) is unknown to the MTA. In
specific, the character set used to encode names in headers is
_NOT_ necessarily the same as used to encode the body (which is
already encoded in MIME in the charset parameter of the
Content-Type: header). Furthermore, it is perfectly reasonable
for, say, a Swede to be living and working in Korea, or a
Russian living and working in Germany, and want their name to
be encoded in their native character set; it could even be that
the sender was Japanese, the recipient Russian, and the body
encoded in ISO 8859-1. If all I have are 8-bit characters, I
can't choose the charset properly.
Similarly, when doing 7->8 bit conversions, I don't want
to throw away this information, as it is necessary for proper
presentation to the end user.
Why can't I get mail to some places, but instead
always get the error "reply: read error from
name.of.remote.host"?
This is usually caused by a bug in the remote host's mail
server, or Mail Transport Agent (MTA). The "EHLO" command of
ESMTP causes the remote server to drop the SMTP connection. There
are several MTAs that have this problem, but one of the most
common server implementations can be identified by the "220 All
set, fire away" greeting it gives when you telnet to its SMTP
port.
To work around this problem, you can configure sendmail to use
a mailertable with an entry telling sendmail to use plain SMTP
when talking to that host:
name.of.remote.host smtp:name.of.remote.host
Sites which must run a host with this broken SMTP
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.
Why doesn't "FEATURE(xxx)" work?
When creating m4 Master Config (".mc") files for version 8
sendmail, many FEATURE() macros
simply change the definition of internal variables that are
referenced in the MAILER()
definitions.
To make sure that everything works as desired, you need to
make sure that OSTYPE() macros
are put at the very beginning of the file, followed by FEATURE() and HACK() macros, local definitions, and at
the very bottom, the MAILER()
definitions. See the configuration Introduction and Example page for more
details.
How do I configure sendmail not to use DNS?
In situations where you're behind a firewall, or across a
dial-up line, there are times when you need to make sure that
programs (such as sendmail) do not use the DNS at all.
With older releases of version 8 sendmail (8.7 and earlier),
you needed to recompile the binary and make sure that
"NAMED_BIND" was turned off in src/conf.h.
With versions 8.8 and later, you change the service switch
file to omit "DNS" and use only NIS, files, and other map types
as appropriate. More information about the service switch file
can be found under the ServiceSwitchFile option in
§5.6
(Options) of the Installation and Operation Guide
and all of §4.9 (Name Server Access).
And 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). The
use of a smart host is one way to do this; the following in your
.mc will do:
define(`SMART_HOST', `name.of.smart.host')dnl
Also, starting with 8.9, it may help to include the following
in your .mc file:
FEATURE(`accept_unresolvable_domains')dnl
FEATURE(`accept_unqualified_senders')dnl
And starting with 8.12, changes to submit.cf are required as
well; the following in your submit.mc can minimize the problem:
define(`confDIRECT_SUBMISSION_MODIFIERS', `C')dnl
How do I get all my queued mail delivered to my Unix box from my ISP?
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 sendmail. See Q2.8 to
find out what exact version this is.
Why do I get the error message unable to write /etc/mail/sendmail.pid?
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.
Why can't I compile sendmail with Berkeley DB 2.X?
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 .
What operating systems has Berkeley sendmail been ported to?
Berkeley sendmail 8.9.3 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 Sendmail, Inc..
How do I prevent Relaying Denied errors for my clients?
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 should list the IP address (e.g., 1.2.3.4); 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.
Why isn't virtual hosting working, even after I added a Kvirtuser to sendmail.cf?
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 FEATURE(virtusertable);
detailed instructions are provided at our Virtual Hosting with Sendmail
page.
How can I add a header specifying the actual
recipient when having multiple users in a virtual domain go to a
single mailbox?
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.
- Use
FEATURE(local_procmail) in your
.mc file so procmail (which you must install
separately) will deliver mail to the mailbox.
- 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. Note that "domuser" must be an actual username,
*not* an alias.
It may be necessary to append "@localhost", as follows
@domain.com domuser+%1@localhost
- 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.
You may be tempted to eliminate variable
ENV_TO and use $1 directly. It
won't work, so don't bother.
FEATURE(local_procmail) causes sendmail to
deliver email to procmail directly. A .forward
file is not only unnecessary, it would prevent procmail from
setting $1 with the necessary text, so don't use
one.
You may need to replace formail with
/usr/local/bin/formail or some such, depending
on whether procmail can find it or not.
Another possible solution
from Andrzej Filip.
What do I do when Build fails because groff was not found?
You can get groff from ftp://ftp.gnu.org/pub/gnu/. But
it's not a big deal, because:
- You've already successfully built the sendmail binary to
get this far.
- You can just use the preformatted man pages anyway:
% cp *.0 obj*
What does "class hash not available"
mean?
You've built sendmail and/or makemap without
NEWDB specified in your DBMDEF
configuration, but you specified the class hash in sendmail.cf or
on a makemap command. The class hash requires NEWDB
support, for which you need the Berkeley database. Please refer
to the Database Definitions section of our Compiling Sendmail web page.
How do I configure majordomo with sendmail 8.9
without relaxing the DontBlameSendmail
option?
We have had some queries about this, as majordomo apparently
suggests some configuration values which sendmail 8.9 does not
like. Here is what one expert suggests:
The sendmail.cf contains:
O AliasFile=/etc/aliases, /etc/majordomo.aliases
O DontBlameSendmail=Safe
/etc/aliases contains the general majordomo aliases:
# Majordomo
majordomo: "|/usr/local/lib/majordomo/wrapper majordomo"
owner-majordomo: postmaster
majordomo-owner: postmaster
/etc/majordomo.aliases contains the majordomo lists of the
form:
wookie: "|/usr/local/lib/majordomo/wrapper resend -l wookie wookie-list"
wookie-list: :include:/usr/local/lib/majordomo/lists/wookie
owner-wookie: head-wookie
wookie-approval: owner-wookie
wookie-request: "|/usr/local/lib/majordomo/wrapper majordomo -l wookie"
The various directory owners/groups/permissions:
drwxr-xr-x 20 root root 1024 Dec 1 15:20 /
drwxr-xr-x 25 root root 3072 Jan 26 01:26 /etc
drwxr-xr-x 20 root root 1024 Feb 4 1998 /usr
drwxr-xr-x 18 root root 1024 Jan 16 18:40 /usr/local
drwxr-xr-x 5 root root 1024 Feb 6 1996 /usr/local/lib
lrwxrwxrwx 1 root root 16 Dec 1 10:01 /usr/local/lib/majordomo -> majordomo-1.94.4
drwxr-x--x 5 majordom majordom 1024 Jan 25 23:12 /usr/local/lib/majordomo-1.94.4
drwxr-xr-x 2 majordom majordom 32768 Jan 26 00:49 /usr/local/lib/majordomo-1.94.4/lists
-rw-rw-r-- 1 majordom majordom 655 Nov 3 17:03 /usr/local/lib/majordomo-1.94.4/lists/wookie
-rw-rw---- 1 majordom majordom 14588 Jan 19 10:28 /usr/local/lib/majordomo-1.94.4/lists/wookie.config
-rw-rw-r-- 1 majordom majordom 23 Jan 14 1997 /usr/local/lib/majordomo-1.94.4/lists/wookie.info
Now the differences that make this work that may not be the
same as instructed by the majordomo instructions:
- Put the majordomo.aliases file in /etc, not in the
majordomo install directory (/usr/local/lib/majordomo). If you
can't move the aliases file out of the majordomo directory,
you'll need to create the database backing file by hand the
first time as root:
# touch /usr/local/lib/majordomo/aliases
# newaliases -OAliasFile=/usr/local/lib/majordomo/aliases
- Make the permissions on /usr/local/lib/majordomo 0751, not
0775.
- Make the permissions on /usr/local/lib/majordomo/Log 0664,
owned by
majordom, group
majordom.
- /usr/local/lib/majordomo/lists is mode 0755, owner
majordom, group majordom.
- The permissions/owners for the lists should be as shown
above. These permissions/ownership allow
majordom
to continue to manage the lists.
How do I configure my system in generael with sendmail 8.9?
The following is taken directly from the DIRECTORY
PERMISSIONS section of the top-level README file in the
sendmail distribution.
Sendmail often gets blamed for many problems that are actually
the result of other problems, such as overly permissive modes on
directories. For this reason, sendmail checks the modes on system
directories and files to determine if can have been trusted. For
sendmail to run without complaining, you MUST
execute the following command:
chmod go-w / /etc /etc/mail /usr /var /var/spool /var/spool/mqueue
chown root / /etc /etc/mail /usr /var /var/spool /var/spool/mqueue
You will probably have to tweak this for your environment
(for example, some systems put the spool directory into /usr/spool
instead of /var/spool and use /etc/mail for aliases file instead of
/etc). If you set the RunAsUser option in your sendmail.cf, the
/var/spool/mqueue directory will have to be owned by the RunAsUser
user. As a general rule, after you have compiled sendmail, run the
command
sendmail -v -bi
to initialize the alias database. If it gives messages such
as
WARNING: writable directory /etc
WARNING: writable directory /usr/spool/mqueue
then the directories listed have inappropriate write
permissions and should be secured to avoid various possible
security attacks.
Beginning with sendmail 8.9, these checks have become more
strict to prevent users from being able to access files they
would normally not be able to read. In particular, .forward and
:include: files in unsafe directory paths (directory paths which
are group or world writable) will no longer be allowed. This
would mean that if user joe's home directory was writable by
group staff, sendmail would not use his .forward file. This
behavior can be altered, at the expense of system security, by
setting the DontBlameSendmail option. For example, to allow
.forward files in group writable directories:
O DontBlameSendmail=forwardfileingroupwritabledirpath
Or to allow them in both group and world writable
directories:
O DontBlameSendmail=forwardfileinunsafedirpath
Items from these unsafe .forward and :include: files will be
marked as unsafe addresses -- the items can not be deliveries to
files or programs. This behavior can also be altered via
DontBlameSendmail:
O DontBlameSendmail=forwardfileinunsafedirpath,
forwardfileinunsafedirpathsafe
The first flag allows the .forward file to be read, the
second allows the items in the file to be marked as safe for file
and program delivery.
Other files affected by this strengthened security include
class files (i.e. Fw /etc/sendmail.cw), persistent
host status files, and the files specified by the ErrorHeader and
HelpFile options. Similar DontBlameSendmail flags are available
for the class, ErrorHeader, and HelpFile files.
If you have an unsafe configuration of .forward and :include:
files, you can make it safe by finding all such files, and doing
a "chmod go-w $FILE" on each. Also, do a
"chmod go-w $DIR" for each directory in
the file's path.
What does "foo not available for
sendmail programs" mean?
It means that you are using smrsh, the sendmail restricted
shell; see Q2.13 for details on
this. To fix this problem, you need to create a sym-link from
smrsh's directory for restricted programs to the program
foo. The default location of this directory for
restricted programs is /usr/adm/sm.bin in the Open
Source version, but vendor versions differ. For example, RedHat
Linux 6.0 uses /etc/smrsh, and Solaris 8 uses
/var/adm/sm.bin . If you don't know the directory
for your OS, first check the smrsh man page, then if that fails,
try:
% strings /path/to/smrsh | grep ^/
where /path/to/smrsh is the P=
argument on the Mprog line in sendmail.cf .
So for example:
% cd /usr/adm/sm.bin
% ln -s /usr/bin/vacation
would allow the vacation program to be run from a user's
.forward file or an alias which uses the "|program"
syntax.
Finally, if you want to disable use of smrsh, remove the
FEATURE(`smrsh') line from the .mc file used to
build sendmail.cf; see cf/README
for details on this.
How do I add a footer/signature to all (outgoing) e-email messages?
This is quite complicated. At first sight it might be simple:
just "cat" some text (taken from a file or whatever) to the end
of an e-mail message passing through sendmail. However, there is a big
problem: what about structured e-mail messages, i.e.,
MIME messages? These can be arbitrarily complex and just
"cat"ting a footer to the end of the body can break the MIME
structure. (A MIME aware MUA will just not show such a footer, so
it's pretty useless in any case.) But signed messages (think:
PGP) will break. Another problem is the character set used by the
mime part to which the disclaimer is added needs to match the
actual character set of the disclaimer itself. Hence, there is
no easy solution to this problem!
If you know enough about MIME and some C programming, then
take a look at sendmail 8.11
(or later) and libmilter/README. It now offers the
functionality to achieve this goal.
Some open source milters are capable of adding footers, e.g.
MIMEDefang.
What does "Cannot open hash database ... Invalid argument" mean?
It's an error returned from the Berkeley DB library. It
normally means that the db file was built with a different
version of Berkeley DB than the one sendmail is currently using.
You need to recompile makemap with the same version of Berkeley
DB that sendmail was compiled with, and re-make your maps with
that new version of makemap.
From a typical Unix 'errno' man page:
22 EINVAL Invalid argument. Some invalid argument was supplied.
From the Berkeley DB 2.x 'db_open' man page (1.x 'dbopen' is
similar):
EINVAL
...
There is a mismatch between the version number of file and the
software.
Berkeley DB 3.x uses a special errno value for this - from
its 'db_open' man page:
DB_OLD_VERSION
The database cannot be opened without being first upgraded.
Unfortunately this isn't specifically handled by sendmail
upto and including 8.11.2, resulting in an error message that says
something like "Error -30990" instead of "Invalid argument".
Here is a table mapping versions of Berkeley DB with the
corresponding sendmail versions in which they are supported:
| Berkeley DB |
Sendmail |
| 0.X - 1.4 (OLD_NEWDB) |
8.1 - 8.8.8 |
| 1.5 and later 1.X |
8.1 and later |
| 2.0.0-2.6.3 |
8.9.0 and later |
| 2.6.4 and later 2.X |
8.9.2 and later |
| 3.0 and later 3.X |
8.10.0 and later |
What does "parse error before `NDBM'"
mean?
This error is generally accompanied by a message indicating
which file it occurred in, and which line number of that file,
usually:
ERROR NDBM or NEWDB must be defined.
You are supposed to read that line, and do something about
it.
Normally, on Linux and the various BSDs, NEWDB is used,
whereas on the "commercial" Unix variants (Solaris, HP-UX,
possibly others), NDBM is used. Perhaps you failed to install the
required libraries when you installed your system.
Please refer to 3.31 and the Database Definitions
section of our Compiling Sendmail web page for further details.
What does "may be forged" mean?
After sendmail does a hostname look-up on the IP address of
the connecting client, the IP addresses of that hostname are
looked up. If the client IP address does not appear in that list,
then the may be forged tag is added.
How do I send using an alternate port?
The port used for outgoing SMTP connections can be changed via
the respective *_MAILER_ARGS macros for the various
SMTP mailers. In a default configuration, sendmail uses either
the relay mailer (for e.g. SMART_HOST
when no mailer is specified) or the esmtp mailer
(when sending directly to the MX of the recipient domain).
So, if you want all outgoing SMTP connections to use port
2525, you can use this in your .mc file:
define(`RELAY_MAILER_ARGS', `TCP $h 2525')
define(`ESMTP_MAILER_ARGS', `TCP $h 2525')
If you want to use an alternate port only for specific
destinations, change (e.g.) only the
RELAY_MAILER_ARGS, and make sure the
relay mailer is not used for anything else. E.g. you
can have sendmail use port 2525 only when sending to your domain
with this in your .mc file:
FEATURE(`mailertable')
define(`confRELAY_MAILER', `esmtp')
define(`RELAY_MAILER_ARGS', `TCP $h 2525')
and then in your mailertable:
yourdomain.com relay:mail.yourdomain.com
This will force sendmail to use port 2525 for connections to
yourdomain.com. Of course, change 2525 to
whatever alternate port number you wish to use.
Why can't I use BerkeleyDB 4.1.x?
SleepyCat changed the API from Berkeley DB 4.0 to 4.1. Hence
it is not supported in sendmail 8.12.6. Moreover, the semantics
of the open() call have been changed, hence sendmail doesn't work
with DB 4.1.x (x <= 24), even if the "obvious" API changes are
made.
However, with the release of Berkeley DB 4.1.25 and sendmail
8.12.7, things should work again with these versions (or greater,
when the time comes).
How do I use CIDR notation in the access map (or other places)?
Use contrib/cidrexpand to pre-process the data into a format
that is supported by sendmail. For example:
cidrexpand < access | makemap hash access
Why isn't CIRD notation directly supported by sendmail?
Because it is in general very expensive to do this. Here's an
explanation from Per Hedeland:
And not just more complex, it would have to do many more
(comparatively expensive) lookups - there's no way, given
(e.g.) the IP address 66.205.192.123, to find the matching
"66.205.192.0/19" with a single lookup in a general key/value
hashed map. The code would have to look for "66.205.192.123",
"66.205.192.122/31", "66.205.192.120/30", "66.205.192.120/29",
etc, etc - 14 lookups to find a /19, 32 to establish a
non-match.
which is 8 times more than the available octet
boundary lookup.
I haven't done any measurements, but I wouldn't be surprised if
even in the absolute worst case, that your map is 128 times
bigger than it "needs" to be, the time for a single lookup
won't even double - i.e. you'll lose already on the second
lookup.
What does "Need to recompile with -DNEWDB for hash support" mean?
See Q3.31. This is the newer form of the
same error message, updated to be more informative and clueful.
The actual line of code contains:
"%s: Need to recompile with -D%s for %s support\n"
where the first %s gets replaced by the name of
the program (generally makemap), the second
%s gets replaced by the name of the macro which needs
to be defined (see the Database Definitions
section of our Compiling Sendmail web page for the full list), and the third
%s gets replaced by the argument to makemap which
could not be handled.
I disabled sendmail on some machines which don't receive mail, but since upgrading to 8.12 they can't send mail either; why?
8.12 uses a new paradigm: the binary is no longer setuid-root;
to make this work, there are now two queues, a "main" queue and a
client-only queue. To match these, there are two config files:
one for the main queue (sendmail.cf) and one for the client-only
queue (submit.cf). There are also two sendmail processes which
need to run: a daemon and a client queue runner. In the default
configuration of sendmail, the client queue runner must be able
to submit mail to the daemon on the local SMTP port. If the
daemon is not listening on the SMTP port, the mail remains in the
client-only queue. If you don't want to accept mail from other
machines, you should add some or all of the following lines to
your .mc file:
FEATURE(`no_default_msa')dnl
DAEMON_OPTIONS(`NAME=NoMTA4, Family=inet, Addr=127.0.0.1')dnl
DAEMON_OPTIONS(`Name=MSA4, Family=inet, Addr=127.0.0.1, Port=587, M=E')dnl
DAEMON_OPTIONS(`NAME=NoMTA6, Family=inet6, Addr=::1')dnl
DAEMON_OPTIONS(`Name=MSA6, Family=inet6, Addr=::1, Port=587, M=E')dnl
Use the FEATURE line regardless, then if your
machine has IPv4 addresses configured, use the first two
DAEMON_OPTIONS lines; likewise, use the second two
DAEMON_OPTIONS lines if it has IPv6 addresses
configured, and all four if both types of addresses are configured.
Then build a new .cf file from your .mc file, install it as
/etc/mail/sendmail.cf and start sendmail.
In some cases, however, it might be better instead to modify
submit.mc, to use
FEATURE(`msp', `smart_host')dnl
instead of the default
FEATURE(`msp', `[127.0.0.1]')dnl
This has the advantage that you don't have to run a daemon on
the local host, but a disadvantage of introducing a dependency on
the smart_host machine. Which of the two solutions is better for
you depends on whether or not your network architecture has such a
smart_host, how reliable you deem that smart_host to be, and how
inconvenient running a daemon locally would be.