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 -unfilled -offset indent
47 table name file: /path/to/file
48 table name db: /path/to/file.db
49 Aliasing tables
51 Aliasing tables are mappings that associate a recipient to one or many
52 destinations. They can be used in two contexts: primary domain aliases
53 and virtual domain mapping. -unfilled -offset indent
54 action name method alias Pf < table >
55 action name method virtual Pf < table >
56 In a primary domain context, the key is the user part of the recipient
58 address, whilst the value is one or many recipients as described in
59 aliases(5):
60 user1 otheruser
61 user2 otheruser1,otheruser2
62 user3 otheruser@example.com
63 In a virtual domain context, the key is either a user part, a full email
65 address or a catch all, following selection rules described in
66 smtpd.conf(5),
67 and the value is one or many recipients as described in
68 aliases(5):
69 user1 otheruser
70 user2@example.org otheruser1,otheruser2
71 @example.org otheruser@example.com
72 @ catchall@example.com
73 The following directive shares the same table format,
75 but with a different meaning.
76 Here, the user is allowed to send mail from the listed addresses:
77 -unfilled -offset indent
78 listen on interface auth [...] senders Pf < table >
79 Domain tables
81 Domain tables are simple lists of domains or hosts. -unfilled -offset
82 indent
83 match for domain Pf < table >action name
84 match helo Pf < table >[...] action name
85 In that context, the list of domains will be matched against the recip‐
87 ient domain or against the HELO name advertised by the sending host,
88 respectively. For Ql static, Ql file and dbopen(3) backends, a wild‐
89 card may be used so the domain table may contain:
90 example.org
91 *.example.org
92 Credentials tables
94 Credentials tables are mappings of credentials. They can be used in
95 two contexts: -unfilled -offset indent
96 listen on interface tls [...] auth Pf < table >
97 action name relay host relay-url auth Pf < table >
98 In a listener context, the credentials are a mapping of username and
100 encrypted passwords:
101 user1 $2b$10$hIJ4QfMcp.90nJwKqGbKM.MybArjHOTpEtoTV.DgLYAiThuoYmTSe
102 user2 $2b$10$bwSmUOBGcZGamIfRuXGTvuTo3VLbPG9k5yeKNMBtULBhksV5KdGsK
103 The passwords are to be encrypted using the
105 smtpctl(8)
106 encrypt subcommand.
107 In a relay context, the credentials are a mapping of labels and
109 username:password pairs:
110 label1 user:password
111 The label must be unique and is used as a selector for the proper credentials
113 when multiple credentials are valid for a single destination.
114 The password is not encrypted as it must be provided to the remote host.
115 Netaddr tables
117 Netaddr tables are lists of IPv4 and IPv6 network addresses. They can
118 only be used in the following context:
119 D1 match from src Pf < table >action name
121 When used as a "from source", the address of a client is compared to
123 the list of addresses in the table until a match is found.
124 A netaddr table can contain exact addresses or netmasks, and looks as
126 follow:
127 192.168.1.1
128 ::1
129 ipv6:::1
130 192.168.1.0/24
131 Userinfo tables
133 User info tables are used in rule context to specify an alternate user
134 base, mapping virtual users to local system users by UID, GID and home
135 directory.
136 D1 action name method userbase Pf < table >
138 A userinfo table looks as follows:
140 joe 1000:100:/home/virtual/joe
141 jack 1000:100:/home/virtual/jack
142 In this example, both joe and jack are virtual users mapped to the local
144 system user with UID 1000 and GID 100, but different home directories.
145 These directories may contain a
146 forward(5)
147 file.
148 This can be used in conjunction with an alias table
149 that maps an email address or the domain part to the desired virtual
150 username.
151 For example:
152 joe@example.org joe
153 jack@example.com jack
154 Source tables
156 Source tables are lists of IPv4 and IPv6 addresses. They can only be
157 used in the following context:
158 D1 action name relay src Pf < table >
160 Successive queries to the source table will return the elements one by
162 one.
163 A source table looks as follow:
165 192.168.1.2
166 192.168.1.3
167 ::1
168 ::2
169 ipv6:::3
170 ipv6:::4
171 Mailaddr tables
173 Mailaddr tables are lists of email addresses. They can be used in the
174 following contexts: -unfilled -offset indent
175 match mail-from Pf < table >action name
176 match rcpt-to Pf < table >action name
177 A mailaddr entry is used to match an email address against a username,
179 a domain or a full email address. A "*" wildcard may be used in part
180 of the domain name.
181 A mailaddr table looks as follow:
183 user
184 @domain
185 user@domain
186 user@*.domain
187 Addrname tables
189 Addrname tables are used to map IP addresses to hostnames. They can be
190 used in both listen context and relay context: -unfilled -offset indent
191 listen on interface hostnames Pf < table >
192 action name relay helo-src Pf < table >
193 In listen context, the table is used to look up the server name to
195 advertise depending on the local address of the socket on which a con‐
196 nection is accepted. In relay context, the table is used to determine
197 the hostname for the HELO sequence of the SMTP protocol, depending on
198 the local address used for the outgoing connection.
199 The format is a mapping from inet4 or inet6 addresses to hostnames:
201 ::1 localhost
202 127.0.0.1 localhost
203 88.190.23.165 www.opensmtpd.org
204
206 smtpd.conf(5), makemap(8), smtpd(8)
207 $Mdocdate: August 11 2019 $ TABLE(5)