The User Database is a special database file that you create for
use by
sendmail
.
It causes sender and recipient addresses to be rewritten under
control of an external database file.
Ordinarily, any local address is first looked up in the
aliases
database. If it is not found there, that user's
~/.forward
is next
examined. If the User Database is enabled, the address is looked up
in that database after aliasing and before forwarding.
Lookup can be local via a database file, remote via a User Database
server, or via a Hesiod network service. Here, we describe the
database file form. The others are described in
Section 34.8.75, UserDatabaseSpec (U)
.
The User Database is automatically enabled when you compile
sendmail
if you include support for NEWDB or HESIOD
(see
Section 18.8.54, USERDB
).
To see whether a precompiled version of
sendmail
includes User Database
support, run it with the
-d0.1
switch:
%
/usr/lib/sendmail -d0.1 -bt < /dev/null
Version 8.8.4
Compiled with: LOG MIME8TO7 NETINET NETUNIX NEWDB SCANF
USERDB
XDEBUG
note
If USERDB is listed, User Database support is included.
Next you must declare the location of
its database file with the
UserDatabaseSpec
(
U
) option
(see
Section 34.8.75
):
OU/etc/userdb.db
in your cf file (V8)
O UserDatabaseSpec=/etc/userdb.db
in your cf file (V8.7)
define(`confUSERDB_SPEC',/etc/userdb.db)
in your m4 file
Here, the location of the database file is set to be
/etc/userdb.db
.
You can also enable a default location for the database file that will
take effect should the
UserDatabaseSpec
(
U
) option be
missing by defining that location with UDB_DEFAULT_SPEC in
compiling (see
Section 18.8.53, UDB-DEFAULT-SPEC
).
The User Database is a
btree
class (see
Section 33.8.1
)
database file created from a source text file using the
makemap
program:
%
makemap btree /etc/userdb.db < /etc/userdb
Here,
/etc/userdb
is the source-text file that is input, and
/etc/userdb.db
is the database we are creating (the one defined by the
U
option in the
previous section).
[5]
The source-text file is composed of key and value pairs, one pair per line:
key value
whitespace
The
key
is a user's login name, a colon, and one of two
possible keywords:
maildrop
or
mailname
.
The keyword that is chosen determines the nature of the
value
.
maildrop
The
value
is the official delivery address for this user.
If there are multiple official addresses, they should either be listed
as a single compound value, with separating commas, as,
for example:
root:maildrop sysadmin@here.us.edu,bill@there.us.edu
or be listed on individual lines:
root:maildrop sysadmin@here.us.edu
root:maildrop bill@there.us.edu
This latter form requires you to use the
-d
command-line switch
with the
makemap
(1) program (see
Section 33.2.1.1
) when
creating the database but has the advantage of being a simpler source
file to manage.
mailname
The
mailname
keyword causes a "reverse alias" transformation,
wherein the login name in the key is changed into the address
in the value for outgoing mail. For example:
bob:mailname Bob.Roberts@Here.US.EDU
This causes mail sent by
bob
to go out addressed as though
it is from
Bob.Roberts@Here.US.EDU
.
[6]
This transformation occurs in the header and envelope.
But note that the sender-envelope is not rewritten by UDB unless
the
F=i
flag (see
Section 30.8.24, F=i
) is present in the
delivery agent that is selected for the sender.
Also note that the recipient headers are not rewritten by UDB
unless the
F=k
flag (see
Section 30.8.26, F=j
)
delivery agent is selected for the recipient.
Naturally, the
maildrop
and
mailname
keywords should
occur in pairs. Each outgoing address that is created with
mailname
should have a corresponding
maildrop
entry so that return
mail can be delivered. In the above example a reasonable pair
might look like this:
bob:mailname Bob.Roberts@Here.US.EDU
Bob.Roberts:maildrop bob
Here, outgoing mail from the user named
bob
will be addressed
as though it is from
Bob.Roberts@Here.US.EDU
. Incoming mail
(whether it is original or in reply to the outgoing) will be addressed
as though it is to the name
Bob.Roberts
, which will be
transformed into and delivered to the local user
bob
.
The
mailname
keyword allows the host part of outgoing
addresses to mask the real hostname of the originating machine.
This property can, for example, be used to convert the hostname into a
firewall name:
bob:mailname bob@Firewall.US.EDU
Here, the canonical name of
bob
's machine is
Here.US.EDU
.
The
mailname
keyword causes outgoing mail from
bob
to appear as though it is from the firewall machine
(
Firewall.US.EDU
) instead.
Ordinarily, this transformation is not automatic. Each username
that is to appear to be from the firewall machine will
need an entry like that above in the User Database.
To automate this process, you can use the special username
:default
in a
mailname
declaration:
:default:mailname Firewall.US.EDU
If a
maildrop
entry is found for a particular name,
but no corresponding
mailname
record is found, the
outgoing address is ordinarily unchanged. If, however, a default
hostname has been defined with
:default
, that hostname
replaces the local hostname for all addresses that lack their own
mailname
entry:
:default:mailname Firewall.US.EDU
bob:maildrop bob@here.us.edu
In this example the user
bob
has a
maildrop
entry
but lacks a
mailname
entry. Outgoing mail from this user
will have the
:default
hostname used instead of the
local hostname. The user
sally
, on the other hand, has
neither a
maildrop
entry nor a
mailname
entry
and so will not have her outgoing address rewritten.