1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
|
PPoossttffiixx SSmmaallll//HHoommee OOffffiiccee HHiinnttss aanndd TTiippss
-------------------------------------------------------------------------------
OOvveerrvviieeww
This document combines hints and tips for "small office/home office"
applications into one document so that they are easier to find. The text
describes the mail sending side only. If your machine does not receive mail
directly (i.e. it does not have its own Internet domain name and its own fixed
IP address), then you will need a solution such as "fetchmail", which is
outside the scope of the Postfix documentation.
* Selected topics from the STANDARD_CONFIGURATION_README document:
o Postfix on a stand-alone Internet host
o Postfix on hosts without a real Internet hostname
Selected topics from the SASL_README document:
o Enabling SASL authentication in the Postfix SMTP client
o Configuring Sender-Dependent SASL authentication
See the SASL_README and STANDARD_CONFIGURATION_README documents for further
information on these topics.
PPoossttffiixx oonn aa ssttaanndd--aalloonnee IInntteerrnneett hhoosstt
Postfix should work out of the box without change on a stand-alone machine that
has direct Internet access. At least, that is how Postfix installs when you
download the Postfix source code via http://www.postfix.org/.
You can use the command "ppoossttccoonnff --nn" to find out what settings are overruled
by your main.cf. Besides a few pathname settings, few parameters should be set
on a stand-alone box, beyond what is covered in the BASIC_CONFIGURATION_README
document:
/etc/postfix/main.cf:
# Optional: send mail as user@domainname instead of user@hostname.
#myorigin = $mydomain
# Optional: specify NAT/proxy external address.
#proxy_interfaces = 1.2.3.4
# Alternative 1: don't relay mail from other hosts.
mynetworks_style = host
relay_domains =
# Alternative 2: relay mail from local clients only.
# mynetworks = 192.168.1.0/28
# relay_domains =
See also the section "Postfix on hosts without a real Internet hostname" if
this is applicable to your configuration.
PPoossttffiixx oonn hhoossttss wwiitthhoouutt aa rreeaall IInntteerrnneett hhoossttnnaammee
This section is for hosts that don't have their own Internet hostname.
Typically these are systems that get a dynamic IP address via DHCP or via
dialup. Postfix will let you send and receive mail just fine between accounts
on a machine with a fantasy name. However, you cannot use a fantasy hostname in
your email address when sending mail into the Internet, because no-one would be
able to reply to your mail. In fact, more and more sites refuse mail addresses
with non-existent domain names.
Note: the following information is Postfix version dependent. To find out what
Postfix version you have, execute the command "ppoossttccoonnff mmaaiill__vveerrssiioonn".
SSoolluuttiioonn 11:: PPoossttffiixx vveerrssiioonn 22..22 aanndd llaatteerr
Postfix 2.2 uses the generic(5) address mapping to replace local fantasy email
addresses by valid Internet addresses. This mapping happens ONLY when mail
leaves the machine; not when you send mail between users on the same machine.
The following example presents additional configuration. You need to combine
this with basic configuration information as discussed in the first half of
this document.
1 /etc/postfix/main.cf:
2 smtp_generic_maps = hash:/etc/postfix/generic
3
4 /etc/postfix/generic:
5 his@localdomain.local hisaccount@hisisp.example
6 her@localdomain.local heraccount@herisp.example
7 @localdomain.local hisaccount+local@hisisp.example
When mail is sent to a remote host via SMTP:
* Line 5 replaces his@localdomain.local by his ISP mail address,
* Line 6 replaces her@localdomain.local by her ISP mail address, and
* Line 7 replaces other local addresses by his ISP account, with an address
extension of +local (this example assumes that the ISP supports "+" style
address extensions).
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ggeenneerriicc" whenever you change the
generic table.
SSoolluuttiioonn 22:: PPoossttffiixx vveerrssiioonn 22..11 aanndd eeaarrlliieerr
The solution with older Postfix systems is to use valid Internet addresses
where possible, and to let Postfix map valid Internet addresses to local
fantasy addresses. With this, you can send mail to the Internet and to local
fantasy addresses, including mail to local fantasy addresses that don't have a
valid Internet address of their own.
The following example presents additional configuration. You need to combine
this with basic configuration information as discussed in the first half of
this document.
1 /etc/postfix/main.cf:
2 myhostname = hostname.localdomain
3 mydomain = localdomain
4
5 canonical_maps = hash:/etc/postfix/canonical
6
7 virtual_alias_maps = hash:/etc/postfix/virtual
8
9 /etc/postfix/canonical:
10 your-login-name your-account@your-isp.com
11
12 /etc/postfix/virtual:
13 your-account@your-isp.com your-login-name
Translation:
* Lines 2-3: Substitute your fantasy hostname here. Do not use a domain name
that is already in use by real organizations on the Internet. See RFC 2606
for examples of domain names that are guaranteed not to be owned by anyone.
* Lines 5, 9, 10: This provides the mapping from "your-login-
name@hostname.localdomain" to "your-account@your-isp.com". This part is
required.
* Lines 7, 12, 13: Deliver mail for "your-account@your-isp.com" locally,
instead of sending it to the ISP. This part is not required but is
convenient.
Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files.
To find out what lookup tables Postfix supports, use the command "ppoossttccoonnff --mm".
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ccaannoonniiccaall" whenever you change the
canonical table.
Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//vviirrttuuaall" whenever you change the
virtual table.
EEnnaabblliinngg SSAASSLL aauutthheennttiiccaattiioonn iinn tthhee PPoossttffiixx SSMMTTPP//LLMMTTPP cclliieenntt
This section shows a typical scenario where the Postfix SMTP client sends all
messages via a mail gateway server that requires SASL authentication.
TTrroouubbllee ssoollvviinngg ttiippss::
* If your SASL logins fail with "SASL authentication failure: No worthy
mechs found" in the mail logfile, then see the section "Postfix SMTP/
LMTP client policy - SASL mechanism pprrooppeerrttiieess".
* For a solution to a more obscure class of SASL authentication failures,
see "Postfix SMTP/LMTP client policy - SASL mechanism nnaammeess".
To make the example more readable we introduce it in two parts. The first part
takes care of the basic configuration, while the second part sets up the
username/password information.
/etc/postfix/main.cf:
smtp_sasl_auth_enable = yes
smtp_tls_security_level = encrypt
smtp_sasl_tls_security_options = noanonymous
relayhost = [mail.isp.example]
# Alternative form:
# relayhost = [mail.isp.example]:submission
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
* The smtp_sasl_auth_enable setting enables client-side authentication. We
will configure the client's username and password information in the second
part of the example.
* The smtp_tls_security_level setting ensures that the connection to the
remote smtp server will be encrypted, and smtp_sasl_tls_security_options
removes the prohibition on plaintext passwords.
* The relayhost setting forces the Postfix SMTP to send all remote messages
to the specified mail server instead of trying to deliver them directly to
their destination.
* In the relayhost setting, the "[" and "]" prevent the Postfix SMTP client
from looking up MX (mail exchanger) records for the enclosed name.
* The relayhost destination may also specify a non-default TCP port. For
example, the alternative form [mail.isp.example]:submission tells Postfix
to connect to TCP network port 587, which is reserved for email client
applications.
* The Postfix SMTP client is compatible with SMTP servers that use the non-
standard "AUTH=mmeetthhoodd....." syntax in response to the EHLO command; this
requires no additional Postfix client configuration.
* With the setting "smtp_tls_wrappermode = yes", the Postfix SMTP client
supports the "wrappermode" protocol, which uses TCP port 465 on the SMTP
server (Postfix 3.0 and later).
* With the smtp_sasl_password_maps parameter, we configure the Postfix SMTP
client to send username and password information to the mail gateway
server. As discussed in the next section, the Postfix SMTP client supports
multiple ISP accounts. For this reason the username and password are stored
in a table that contains one username/password combination for each mail
gateway server.
/etc/postfix/sasl_passwd:
# destination credentials
[mail.isp.example] username:password
# Alternative form:
# [mail.isp.example]:submission username:password
IImmppoorrttaanntt
Keep the SASL client password file in /etc/postfix, and make the file
read+write only for root to protect the username/password combinations
against other users. The Postfix SMTP client will still be able to read the
SASL client passwords. It opens the file as user root before it drops
privileges, and before entering an optional chroot jail.
* Use the postmap command whenever you change the /etc/postfix/sasl_passwd
file.
* If you specify the "[" and "]" in the relayhost destination, then you must
use the same form in the smtp_sasl_password_maps file.
* If you specify a non-default TCP Port (such as ":submission" or ":587") in
the relayhost destination, then you must use the same form in the
smtp_sasl_password_maps file.
CCoonnffiigguurriinngg SSeennddeerr--DDeeppeennddeenntt SSAASSLL aauutthheennttiiccaattiioonn
Postfix supports different ISP accounts for different sender addresses (version
2.3 and later). This can be useful when one person uses the same machine for
work and for personal use, or when people with different ISP accounts share the
same Postfix server.
To make this possible, Postfix supports per-sender SASL passwords and per-
sender relay hosts. In the example below, the Postfix SMTP client will search
the SASL password file by sender address before it searches that same file by
destination. Likewise, the Postfix trivial-rewrite(8) daemon will search the
per-sender relayhost file, and use the default relayhost setting only as a
final resort.
/etc/postfix/main.cf:
smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relayhost = [mail.isp.example]
# Alternative form:
# relayhost = [mail.isp.example]:submission
/etc/postfix/sasl_passwd:
# Per-sender authentication; see also /etc/postfix/sender_relay.
user1@example.com username1:password1
user2@example.net username2:password2
# Login information for the default relayhost.
[mail.isp.example] username:password
# Alternative form:
# [mail.isp.example]:submission username:password
/etc/postfix/sender_relay:
# Per-sender provider; see also /etc/postfix/sasl_passwd.
user1@example.com [mail.example.com]:submission
user2@example.net [mail.example.net]
* If you are creative, then you can try to combine the two tables into one
single MySQL database, and configure different Postfix queries to extract
the appropriate information.
* Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb
files. To find out what lookup tables Postfix supports, use the command
"ppoossttccoonnff --mm".
* Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//ssaassll__ppaasssswwdd" whenever you change
the sasl_passwd table.
* Execute the command "ppoossttmmaapp //eettcc//ppoossttffiixx//sseennddeerr__rreellaayy" whenever you change
the sender_relay table.
|