1TABLE(5) File Formats Manual TABLE(5)
2
6 table - format description for smtpd tables
7
9 This manual page documents the file format for the various tables used
10 in the smtpd(8) mail daemon.
11 The format described here applies to tables as defined in
13 smtpd.conf(5).
14
16 There are two types of tables: lists and mappings. A list consists of
17 a series of values, while a mapping consists of a series of keys and
18 their associated values. The following illustrates how to declare them
19 as static tables:
20 table mylist { value1, value2, value3 }
21 table mymapping { key1 = value1, key2 = value2, key3 = value3 }
22 When using a
24 Ql file
25 table, a list will be written with each value on a line by itself.
26 Comments can be put anywhere in the file using a hash mark
27 (Sq #,)
28 and extend to the end of the current line.
29 value1
30 value2
31 value3
32 A mapping will be written with each key and value on a line,
34 whitespaces separating both columns:
35 key1 value1
36 key2 value2
37 key3 value3
38 A file table can be converted to a Berkeley database using the
40 makemap(8)
41 utility with no syntax change.
42 Tables using a
44 Ql file
45 or Berkeley DB backend will be referenced as follows:
46 table name file:/path/to/file
47 table name db:/path/to/file.db
48 Aliasing tables
50 Aliasing tables are mappings that associate a recipient to one or many
51 destinations. They can be used in two contexts: primary domain aliases
52 and virtual domain mapping.
53 accept for domain example.org alias <myaliases> deliver to mbox
54 accept for domain example.org virtual <myaliases> deliver to mbox
55 In a primary domain context, the key is the user part of the recipient address,
57 whilst the value is one or many recipients as described in
58 aliases(5):
59 user1 otheruser
60 user2 otheruser1,otheruser2
61 user3 otheruser@example.com
62 In a virtual domain context, the key is either a user part, a full email
64 address or a catch all, following selection rules described in
65 smtpd.conf(5),
66 and the value is one or many recipients as described in
67 aliases(5):
68 user1 otheruser
69 user2@example.org otheruser1,otheruser2
70 @example.org otheruser@example.com
71 @ catchall@example.com
72 Domain tables
74 Domain tables are simple lists of domains. They can only be used in
75 one context:
76 accept for domain <mydomains> deliver to mbox
77 In that context, the list of domains will be matched against the recipient
79 domain.
80 For
81 Ql static,
82 Ql file
83 and
84 dbopen(3)
85 backends, a wildcard may be used so the domain table may contain:
86 example.org
87 *.example.org
88 Credentials tables
90 Credentials tables are mappings of credentials. They can be used in
91 two contexts:
92 listen on tls [...] auth <credentials>
93 accept for any relay tls+auth://label@host auth <credentials>
94 In a listener context, the credentials are a mapping of username and encrypted
96 passwords:
97 user1 $2b$10$hIJ4QfMcp.90nJwKqGbKM.MybArjHOTpEtoTV.DgLYAiThuoYmTSe
98 user2 $2b$10$bwSmUOBGcZGamIfRuXGTvuTo3VLbPG9k5yeKNMBtULBhksV5KdGsK
99 The passwords are to be encrypted using the
101 smtpctl(8)
102 encrypt subcommand.
103 In a relay context, the credentials are a mapping of labels and
105 username:password pairs,
106 where the username may be omitted if identical to the label:
107 label1 user:password
108 label2 password
109 The label must be unique and is used as a selector for the proper credentials
111 when multiple credentials are valid for a single destination.
112 The password is not encrypted as it must be provided to the remote host.
113 Netaddr tables
115 Netaddr tables are lists of IPv4 and IPv6 network addresses. They can
116 only be used in the following context:
117 accept from source <netaddr> for domain example.org deliver to mbox
118 When used as a "from source", the address of a client is compared to the list
120 of addresses in the table until a match is found.
121 A netaddr table can contain exact addresses or netmasks, and looks as follow:
123 192.168.1.1
124 ::1
125 ipv6:::1
126 192.168.1.0/24
127 Userinfo tables
129 User info tables are used to described virtual system users. They are
130 used in rule context to specify an alternate user base, mapping virtual
131 users to local system UID, GID and home directory.
132 accept for domain example.org userbase <userinfo> deliver to maildir
133 The userinfo table is a mapping from virtual user names to a set of system user
135 ID, group ID and path to home directory.
136 A userinfo table looks as follows:
138 joe 1000:100:/home/virtual/joe
139 jack 1000:100:/home/virtual/jack
140 In this example, both joe and jack are virtual users mapped to the local
142 system user with UID 1000 and GID 100, but different home directories.
143 These directories may contain a
144 forward(5)
145 file.
146 Source tables
148 Source tables are lists of IPv4 and IPv6 addresses. They can only be
149 used in the following context:
150 accept for domain example.org relay source <addresses>
151 Successive queries to the source table will return the elements one by one.
153 A source table looks as follow:
155 192.168.1.2
156 192.168.1.3
157 ::1
158 ::2
159 ipv6:::3
160 ipv6:::4
161 Mailaddr tables
163 Mailaddr tables are lists of email addresses. They can be used in the
164 following contexts:
165 accept sender <senders> for domain example.org deliver to mbox
166 accept for domain example.org recipient <recipients> deliver to mbox
167 A mailaddr entry is used to match an email address against a username,
169 a domain or a full email address.
170 A "*" wildcard may be used in part of the domain name.
171 A mailaddr table looks as follow:
173 user
174 @domain
175 user@domain
176 user@*.domain
177 Addrname tables
179 Addrname tables are used to map IP addresses to hostnames. They can be
180 used in both listen context and relay context:
181 listen on 0.0.0.0 hostnames <addrname>
182 accept for any relay hostnames <addrname>
183 In listen context, the table is used to look up the server name to advertise
185 depending on the local address of the socket on which a connection is accepted.
186 In relay context, the table is used to determine the hostname for the HELO
187 sequence of the SMTP protocol, depending on the local address used for the
188 outgoing connection.
189 The format is a mapping from inet4 or inet6 addresses to hostnames:
191 ::1 localhost
192 127.0.0.1 localhost
193 88.190.23.165 www.opensmtpd.org
194
196 smtpd.conf(5), makemap(8), smtpd(8)
197 $Mdocdate: April 4 2017 $ TABLE(5)