Provided by: opensmtpd_5.7.3p2-1_amd64 
NAME
table - format description for smtpd tables
DESCRIPTION
This manual page documents the file format for the various tables used in the smtpd(8)
mail daemon.
The format described here applies to tables as defined in smtpd.conf(5).
TABLE TYPES
There are two types of tables: lists and mappings. A list consists of a series of values,
while a mapping consists of a series of keys and their associated values. The following
illustrates how to declare them as static tables:
table mylist { value1, value2, value3 }
table mymapping { key1 = value1, key2 = value2, key3 = value3 }
When using a
Ql file
table, a list will be written with each value on a line by itself:
value1
value2
value3
A mapping will be written with each key and value on a line,
whitespaces separating both columns:
key1 value1
key2 value2
key3 value3
A file table can be converted to a
db(3)
database using the
makemap(8)
utility with no syntax change.
Tables using a
Ql file
or
db(3)
backend will be referenced as follows:
table name file:/path/to/file
table name db:/path/to/file.db
Aliasing tables
Aliasing tables are mappings that associate a recipient to one or many destinations. They
can be used in two contexts: primary domain aliases and virtual domain mapping.
accept for domain example.org alias <myaliases> deliver to mbox
accept for domain example.org virtual <myaliases> deliver to mbox
In a primary domain context, the key is the user part of the recipient address,
whilst the value is one or many recipients as described in
aliases(5):
user1 otheruser
user2 otheruser1,otheruser2
user3 otheruser@example.com
In a virtual domain context, the key is either a user part, a full email
address or a catch all, following selection rules described in
smtpd.conf(5),
and the value is one or many recipients as described in
aliases(5):
user1 otheruser
user2@example.org otheruser1,otheruser2
@example.org otheruser@example.com
@ catchall@example.com
Domain tables
Domain tables are simple lists of domains. They can only be used in one context:
accept for domain <mydomains> deliver to mbox
In that context, the list of domains will be matched against the recipient
domain.
For
Ql static,
Ql file
and
db(3)
backends, a wildcard may be used so the domain table may contain:
example.org
*.example.org
Credentials tables
Credentials tables are mappings of credentials. They can be used in two contexts:
listen on tls [...] auth <credentials>
accept for any relay tls+auth://label@host auth <credentials>
In a listener context, the credentials are a mapping of username and encrypted
passwords:
user1 $2a$06$hIJ4QfMcp.90nJwKqGbKM.MybArjHOTpEtoTV.DgLYAiThuoYmTSe
user2 $2a$06$bwSmUOBGcZGamIfRuXGTvuTo3VLbPG9k5yeKNMBtULBhksV5KdGsK
The passwords are to be encrypted using the
smtpctl(8)
encrypt subcommand.
In a relay context, the credentials are a mapping of labels and
username:password pairs,
where the username may be omitted if identical to the label:
label1 user:password
label2 password
The label must be unique and is used as a selector for the proper credentials
when multiple credentials are valid for a single destination.
The password is not encrypted as it must be provided to the remote host.
Netaddr tables
Netaddr tables are lists of IPv4 and IPv6 network addresses. They can only be used in the
following context:
accept from source <netaddr> for domain example.org deliver to mbox
When used as a "from source", the address of a client is compared to the list
of addresses in the table until a match is found.
A netaddr table can contain exact addresses or netmasks, and looks as follow:
192.168.1.1
::1
ipv6:::1
192.168.1.0/24
Userinfo tables
User info tables are used to described virtual system users. They are used in rule
context to specify an alternate user base, mapping virtual users to local system UID, GID
and home directory.
accept for domain example.org userbase <userinfo> deliver to maildir
The userinfo table is a mapping from virtual user names to a set of system user
ID, group ID and path to home directory.
A userinfo table looks as follows:
joe 1000:100:/home/virtual/joe
jack 1000:100:/home/virtual/jack
In this example, both joe and jack are virtual users mapped to the local
system user with UID 1000 and GID 100, but different home directories.
These directories may contain a
forward(5)
file.
Source tables
Source tables are lists of IPv4 and IPv6 addresses. They can only be used in the
following context:
accept for domain example.org relay source <addresses>
Successive queries to the source table will return the elements one by one.
A source table looks as follow:
192.168.1.2
192.168.1.3
::1
::2
ipv6:::3
ipv6:::4
Mailaddr tables
Mailaddr tables are lists of email addresses. They can be used in the following contexts:
accept sender <senders> for domain example.org deliver to mbox
accept for domain example.org recipient <recipients> deliver to mbox
A mailaddr entry is used to match an email address against a username,
a domain or a full email address.
A "*" wildcard may be used in part of the domain name.
A mailaddr table looks as follow:
user
@domain
user@domain
user@*.domain
Addrname tables
Addrname tables are used to map IP addresses to hostnames. They can be used in both
listen context and relay context:
listen on 0.0.0.0 hostnames <addrname>
accept for any relay hostnames <addrname>
In listen context, the table is used to look up the server name to advertise
depending on the local address of the socket on which a connection is accepted.
In relay context, the table is used to determine the hostname for the HELO
sequence of the SMTP protocol, depending on the local address used for the
outgoing connection.
The format is a mapping from inet4 or inet6 addresses to hostnames:
::1 localhost
127.0.0.1 localhost
88.190.23.165 www.opensmtpd.org
SEE ALSO
smtpd.conf(5), makemap(8), smtpd(8)
$Mdocdate: February 4 2014 $ TABLE(5)