1
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
2
"http://www.w3.org/TR/html4/loose.dtd">
8
<title>Postfix SMTP relay and access control </title>
10
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
16
<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix
17
SMTP relay and access control </h1>
21
<h2> Introduction </h2>
23
<p> The Postfix SMTP server receives mail from the network and is
24
exposed to the big bad world of junk email and viruses. This document
25
introduces the built-in and external methods that control what SMTP
26
mail Postfix will accept, what mistakes to avoid, and how to test
27
your configuration. </p>
29
<p> Topics covered in this document: </p>
33
<li> <a href="#relay"> Relay control, junk mail control, and per-user
36
<li> <a href="#global"> Restrictions that apply to all SMTP mail
39
<li> <a href="#lists"> Getting selective with SMTP access restriction
42
<li> <a href="#timing"> Delayed evaluation of SMTP access restriction lists </a>
44
<li> <a href="#danger"> Dangerous use of smtpd_recipient_restrictions
47
<li> <a href="#testing"> SMTP access rule testing </a>
51
<h2> <a name="relay"> Relay control, junk mail control, and per-user
54
<p> In a distant past, the Internet was a friendly environment.
55
Mail servers happily forwarded mail on behalf of anyone towards
56
any destination. On today's Internet, spammers abuse servers that
57
forward mail from arbitrary systems, and abused systems end up on
58
anti-spammer blacklists. See, for example, the information on
59
<a href="http://www.mail-abuse.org/">http://www.mail-abuse.org/</a> and other websites. </p>
61
<p> By default, Postfix has a moderately restrictive approach to
62
mail relaying. Postfix forwards mail only from clients in trusted
63
networks, or to domains that are configured as authorized relay
64
destinations. For a description of the default policy, see the
65
<a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> parameter in the <a href="postconf.5.html">postconf(5)</a> manual
66
page, and the information that is referenced from there. </p>
68
<p> Most of the Postfix SMTP server access controls are targeted
69
at stopping junk email. </p>
73
<li> <p> Protocol oriented: some SMTP server access controls block
74
mail by being very strict with respect to the SMTP protocol; these
75
catch poorly implemented and/or poorly configured junk email
76
software, as well as email worms that come with their own non-standard
77
SMTP client implementations. Protocol-oriented access controls
78
become less useful over time as spammers and worm writers learn to
79
read RFC documents. </p>
81
<li> <p> Blacklist oriented: some SMTP server access controls
82
query blacklists with known to be bad sites such as open mail
83
relays, open web proxies, and home computers that have been
84
compromised and that are under remote control by criminals. The
85
effectiveness of these blacklists depends on how complete and how
86
up to date they are. </p>
88
<li> <p> Threshold oriented: some SMTP server access controls attempt
89
to raise the bar by either making the client do more work (greylisting)
90
or by asking for a second opinion (SPF and sender/recipient address
91
verification). The greylisting and SPF policies are implemented
92
externally, and are the subject of the <a href="SMTPD_POLICY_README.html">SMTPD_POLICY_README</a> document.
93
Sender/recipient address verification is the subject of the
94
<a href="ADDRESS_VERIFICATION_README.html">ADDRESS_VERIFICATION_README</a> document. </p>
98
<p> Unfortunately, all junk mail controls have the possibility of
99
falsely rejecting legitimate mail. This can be a problem for sites
100
with many different types of users. For some users it is unacceptable
101
when any junk email slips through, while for other users the world
102
comes to an end when a single legitimate email message is blocked.
103
Because there is no single policy that is "right" for all users,
104
Postfix supports different SMTP access restrictions for different
105
users. This is described in the <a href="RESTRICTION_CLASS_README.html">RESTRICTION_CLASS_README</a> document.
108
<h2> <a name="global"> Restrictions that apply to all SMTP mail </a> </h2>
110
<p> Besides the restrictions that can be made configurable per
111
client or per user as described in the next section, Postfix
112
implements a few restrictions that apply to all SMTP mail. </p>
116
<li> <p> The built-in <a href="postconf.5.html#header_checks">header_checks</a> and <a href="postconf.5.html#body_checks">body_checks</a> content
117
restrictions, as described in the <a href="BUILTIN_FILTER_README.html">BUILTIN_FILTER_README</a> document.
118
This happens while Postfix receives mail, before it is stored in
119
the <a href="QSHAPE_README.html#incoming_queue">incoming queue</a>. </p>
121
<li> <p> The external before-queue content restrictions, as described
122
in the <a href="SMTPD_PROXY_README.html">SMTPD_PROXY_README</a> document. This happens while Postfix
123
receives mail, before it is stored in the <a href="QSHAPE_README.html#incoming_queue">incoming queue</a>. </p>
125
<li> <p> Requiring that the client sends the HELO or EHLO command
126
before sending the MAIL FROM or ETRN command. This may cause problems
127
with home-grown applications that send mail. For this reason, the
128
requirement is disabled by default ("<a href="postconf.5.html#smtpd_helo_required">smtpd_helo_required</a> = no").
131
<li> <p> Disallowing illegal syntax in MAIL FROM or RCPT TO commands.
132
This may cause problems with home-grown applications that send
133
mail, and with ancient PC mail clients. For this reason, the
134
requirement is disabled by default ("<a href="postconf.5.html#strict_rfc821_envelopes">strict_rfc821_envelopes</a> =
139
<li> <p> Disallowing <a href="http://www.faqs.org/rfcs/rfc822.html">RFC 822</a> address syntax (example: "MAIL FROM: the
140
dude <dude@example.com>"). </p>
142
<li> <p> Disallowing addresses that are not enclosed with <>
143
(example: "MAIL FROM: dude@example.com"). </p>
147
<li> <p> Rejecting mail from a non-existent sender address. This form
148
of egress filtering helps to slow down worms and other malware, but
149
may cause problems with home-grown software that sends out mail
150
software with an unreplyable address. For this reason the requirement
151
is disabled by default ("<a href="postconf.5.html#smtpd_reject_unlisted_sender">smtpd_reject_unlisted_sender</a> = no"). </p>
153
<li> <p> Rejecting mail for a non-existent recipient address. This
154
form of ingress filtering helps to keep the mail queue free of
155
undeliverable MAILER-DAEMON messages. This requirement is enabled
156
by default ("<a href="postconf.5.html#smtpd_reject_unlisted_recipient">smtpd_reject_unlisted_recipient</a> = yes"). </p>
160
<h2> <a name="lists"> Getting selective with SMTP access restriction
163
<p> Postfix allows you to specify lists of access restrictions for
164
each stage of the SMTP conversation. Individual restrictions are
165
described in the <a href="postconf.5.html">postconf(5)</a> manual page. </p>
167
<p> Examples of simple restriction lists are: </p>
170
/etc/postfix/main.cf:
171
# Allow connections from trusted networks only.
172
<a href="postconf.5.html#smtpd_client_restrictions">smtpd_client_restrictions</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>, reject
174
# Don't talk to mail systems that don't know their own hostname.
175
<a href="postconf.5.html#smtpd_helo_restrictions">smtpd_helo_restrictions</a> = <a href="postconf.5.html#reject_unknown_hostname">reject_unknown_hostname</a>
177
# Don't accept mail from domains that don't exist.
178
<a href="postconf.5.html#smtpd_sender_restrictions">smtpd_sender_restrictions</a> = <a href="postconf.5.html#reject_unknown_sender_domain">reject_unknown_sender_domain</a>
180
# Whitelisting: local clients may specify any destination. Others may not.
181
<a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>, <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a>
184
<p> Each restriction list is evaluated from left to right until
185
some restriction produces a result of PERMIT, REJECT or DEFER (try
186
again later). The end of the list is equivalent to a PERMIT result.
187
By placing a PERMIT restriction before a REJECT restriction you
188
can make exceptions for specific clients or users. This is called
189
whitelisting; the last example above allows mail from local networks
190
but otherwise rejects mail to arbitrary destinations. </p>
192
<p> The table below summarizes the purpose of each SMTP access
193
restriction list. All lists use the exact same syntax; they differ
194
only in the time of evaluation and in the effect of a REJECT or
201
<tr> <th> Restriction list name </th> <th> Status </th> <th> Effect
202
of REJECT or DEFER result </th> </tr>
204
<tr> <td> <a href="postconf.5.html#smtpd_client_restrictions">smtpd_client_restrictions</a> </td> <td> Optional </td> <td>
205
Reject all client commands </td> </tr>
207
<tr> <td> <a href="postconf.5.html#smtpd_helo_restrictions">smtpd_helo_restrictions</a> </td> <td> Optional </td> <td>
208
Reject HELO/EHLO information </td> </tr>
210
<tr> <td> <a href="postconf.5.html#smtpd_sender_restrictions">smtpd_sender_restrictions</a> </td> <td> Optional </td> <td>
211
Reject MAIL FROM information </td> </tr>
213
<tr> <td> <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> </td> <td> Required </td>
214
<td> Reject RCPT TO information </td> </tr>
216
<tr> <td> <a href="postconf.5.html#smtpd_data_restrictions">smtpd_data_restrictions</a> </td> <td> Optional </td> <td>
217
Reject DATA command </td> </tr>
219
<tr> <td> <a href="postconf.5.html#smtpd_etrn_restrictions">smtpd_etrn_restrictions</a> </td> <td> Optional </td> <td>
220
Reject ETRN command </td> </tr>
226
<h2> <a name="timing"> Delayed evaluation of SMTP access restriction lists
229
<p> Early Postfix versions evaluated SMTP access restrictions lists
230
as early as possible. The client restriction list was evaluated
231
before Postfix sent the "220 $<a href="postconf.5.html#myhostname">myhostname</a>..." greeting banner to
232
the SMTP client, the helo restriction list was evaluated before
233
Postfix replied to the HELO (EHLO) command, the sender restriction
234
list was evaluated before Postfix replied to the MAIL FROM command,
235
and so on. This approach turned out to be difficult to use. </p>
237
<p> Current Postfix versions postpone the evaluation of client,
238
helo and sender restriction lists until the RCPT TO or ETRN command.
239
This behavior is controlled by the <a href="postconf.5.html#smtpd_delay_reject">smtpd_delay_reject</a> parameter.
240
Restriction lists are still evaluated in the proper order of (client,
241
helo, etrn) or (client, helo, sender, recipient, data) restrictions.
242
When a restriction list (example: client) evaluates to REJECT or
243
DEFER the other restriction lists (example: helo, sender, etc.)
246
<p> Around the time that <a href="postconf.5.html#smtpd_delay_reject">smtpd_delay_reject</a> was introduced, Postfix
247
was also changed to support mixed restriction lists that combine
248
information about the client, helo, sender and recipient or etrn
251
<p> Benefits of delayed restriction evaluation, and of restriction
256
<li> <p> Some SMTP clients do not expect a negative reply early in
257
the SMTP session. When the bad news is postponed until the RCPT TO
258
reply, the client goes away as it is supposed to, instead of hanging
259
around until a timeout happens, or worse, going into an endless
260
connect-reject-connect loop. </p>
262
<li> <p> Postfix can log more useful information. For example, when
263
Postfix rejects a client name or address and delays the action
264
until the RCPT TO command, it can log the sender and the recipient
265
address. This is more useful than logging only the client hostname
266
and IP address and not knowing whose mail was being blocked. </p>
268
<li> <p> Mixing is needed for complex whitelisting policies. For
269
example, in order to reject local sender addresses in mail from
270
non-local clients, you need to be able to mix restrictions on client
271
information with restrictions on sender information in the same
272
restriction list. Without this ability, many per-user access
273
restrictions would be impossible to express. </p>
277
<h2> <a name="danger"> Dangerous use of smtpd_recipient_restrictions </a> </h2>
279
<p> By now the reader may wonder why we need smtpd client, helo
280
or sender restrictions, when their evaluation is postponed until
281
the RCPT TO or ETRN command. Some people recommend placing ALL the
282
access restrictions in the <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> list.
283
Unfortunately, this can result in too permissive access. How is
286
<p> The purpose of the <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> feature is to
287
control how Postfix replies to the RCPT TO command. If the restriction
288
list evaluates to REJECT or DEFER, the recipient address is rejected;
289
no surprises here. If the result is PERMIT, then the recipient
290
address is accepted. And this is where surprises can happen. </p>
292
<p> Here is an example that shows when a PERMIT result can result
293
in too much access permission: </p>
296
1 /etc/postfix/main.cf:
297
2 <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> =
298
3 <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>
299
4 <a href="postconf.5.html#check_helo_access">check_helo_access</a> hash:/etc/postfix/helo_access
300
5 <a href="postconf.5.html#reject_unknown_hostname">reject_unknown_hostname</a>
301
6 <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a>
303
8 /etc/postfix/helo_access:
304
9 localhost.localdomain PERMIT
307
<p> Line 5 rejects mail from hosts that don't specify a proper
308
hostname in the HELO command. Lines 4 and 9 make an exception to
309
allow mail from some machine that announces itself with "HELO
310
localhost.localdomain". </p>
312
<p> The problem with this configuration is that
313
<a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> evaluates to PERMIT for EVERY host
314
that announces itself as "localhost.localdomain", making Postfix
315
an open relay for all such hosts. </p>
317
<p> In order to avoid surprises like these with
318
<a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a>, you should place non-recipient
319
restrictions AFTER the <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a> restriction, not
320
before. In the above example, the HELO based restrictions should
321
be placed AFTER <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a>, or better, the HELO
322
based restrictions should be placed under <a href="postconf.5.html#smtpd_helo_restrictions">smtpd_helo_restrictions</a>
323
where they can do no harm. </p>
325
<h2> <a name="testing"> SMTP access rule testing </a> </h2>
327
<p> Postfix has several features that aid in SMTP access rule
332
<dt> <a href="postconf.5.html#soft_bounce">soft_bounce</a> </dt> <dd> <p> This is a safety net that changes
333
SMTP server REJECT actions into DEFER (try again later) actions.
334
This keeps mail queued that would otherwise be returned to the
335
sender. Specify "<a href="postconf.5.html#soft_bounce">soft_bounce</a> = yes" in the main.cf file to prevent
336
the Postfix SMTP server from rejecting mail permanently, by changing
337
all 5xx SMTP reply codes into 4xx. </p> </dd>
339
<dt> <a href="postconf.5.html#warn_if_reject">warn_if_reject</a> </dt> <dd> <p> This is a different safety net
340
that changes SMTP server REJECT actions into warnings. Instead of
341
rejecting a command, Postfix logs what it would reject. Specify
342
"<a href="postconf.5.html#warn_if_reject">warn_if_reject</a>" in an SMTP access restriction list, before the
343
restriction that you want to test without actually rejecting mail.
346
<dt> XCLIENT </dt> <dd> <p> With this Postfix 2.1 feature, authorized
347
SMTP clients can impersonate other systems, so that you can do
348
realistic SMTP access rule tests. Examples of how to impersonate
349
other systems for access rule testing are given at the end of the
350
<a href="XCLIENT_README.html">XCLIENT_README</a> document. </p> </dd>
added
removed
html/SMTPD_ACCESS_README.html
