1<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" 2 "http://www.w3.org/TR/html4/loose.dtd"> 3 4<html> 5 6<head> 7 8<title>Postfix SMTP relay and access control </title> 9 10<meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> 11 12</head> 13 14<body> 15 16<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix 17SMTP relay and access control </h1> 18 19<hr> 20 21<h2> Introduction </h2> 22 23<p> The Postfix SMTP server receives mail from the network and is 24exposed to the big bad world of junk email and viruses. This document 25introduces the built-in and external methods that control what SMTP 26mail Postfix will accept, what mistakes to avoid, and how to test 27your configuration. </p> 28 29<p> Topics covered in this document: </p> 30 31<ul> 32 33<li> <a href="#relay"> Relay control, junk mail control, and per-user 34policies </a> 35 36<li> <a href="#global"> Restrictions that apply to all SMTP mail 37</a> 38 39<li> <a href="#lists"> Getting selective with SMTP access restriction 40lists </a> 41 42<li> <a href="#timing"> Delayed evaluation of SMTP access restriction lists </a> 43 44<li> <a href="#danger"> Dangerous use of smtpd_recipient_restrictions 45</a> 46 47<li> <a href="#testing"> SMTP access rule testing </a> 48 49</ul> 50 51<h2> <a name="relay"> Relay control, junk mail control, and per-user 52policies </a> </h2> 53 54<p> In a distant past, the Internet was a friendly environment. 55Mail servers happily forwarded mail on behalf of anyone towards 56any destination. On today's Internet, spammers abuse servers that 57forward mail from arbitrary systems, and abused systems end up on 58anti-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> 60 61<p> By default, Postfix has a moderately restrictive approach to 62mail relaying. Postfix forwards mail only from clients in trusted 63networks, from clients that have authenticated with SASL, or to 64domains that are configured as authorized relay 65destinations. For a description of the default mail relay policy, 66see the <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> parameter in the <a href="postconf.5.html">postconf(5)</a> manual 67page, and the information that is referenced from there. </p> 68 69<blockquote> <p> NOTE: Postfix versions before 2.10 did not have 70<a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a>. They combined the mail relay and spam 71blocking policies, under <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a>. This could 72lead to unexpected results. For example, a permissive spam blocking 73policy could unexpectedly result in a permissive mail relay policy. 74An example of this is documented under "<a href="#danger">Dangerous 75use of smtpd_recipient_restrictions</a>". </p> </blockquote> 76 77<p> Most of the Postfix SMTP server access controls are targeted 78at stopping junk email. </p> 79 80<ul> 81 82<li> <p> Protocol oriented: some SMTP server access controls block 83mail by being very strict with respect to the SMTP protocol; these 84catch poorly implemented and/or poorly configured junk email 85software, as well as email worms that come with their own non-standard 86SMTP client implementations. Protocol-oriented access controls 87become less useful over time as spammers and worm writers learn to 88read RFC documents. </p> 89 90<li> <p> Blacklist oriented: some SMTP server access controls 91query blacklists with known to be bad sites such as open mail 92relays, open web proxies, and home computers that have been 93compromised and that are under remote control by criminals. The 94effectiveness of these blacklists depends on how complete and how 95up to date they are. </p> 96 97<li> <p> Threshold oriented: some SMTP server access controls attempt 98to raise the bar by either making the client do more work (greylisting) 99or by asking for a second opinion (SPF and sender/recipient address 100verification). The greylisting and SPF policies are implemented 101externally, and are the subject of the <a href="SMTPD_POLICY_README.html">SMTPD_POLICY_README</a> document. 102Sender/recipient address verification is the subject of the 103<a href="ADDRESS_VERIFICATION_README.html">ADDRESS_VERIFICATION_README</a> document. </p> 104 105</ul> 106 107<p> Unfortunately, all junk mail controls have the possibility of 108falsely rejecting legitimate mail. This can be a problem for sites 109with many different types of users. For some users it is unacceptable 110when any junk email slips through, while for other users the world 111comes to an end when a single legitimate email message is blocked. 112Because there is no single policy that is "right" for all users, 113Postfix supports different SMTP access restrictions for different 114users. This is described in the <a href="RESTRICTION_CLASS_README.html">RESTRICTION_CLASS_README</a> document. 115</p> 116 117<h2> <a name="global"> Restrictions that apply to all SMTP mail </a> </h2> 118 119<p> Besides the restrictions that can be made configurable per 120client or per user as described in the next section, Postfix 121implements a few restrictions that apply to all SMTP mail. </p> 122 123<ul> 124 125<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 126restrictions, as described in the <a href="BUILTIN_FILTER_README.html">BUILTIN_FILTER_README</a> document. 127This happens while Postfix receives mail, before it is stored in 128the <a href="QSHAPE_README.html#incoming_queue">incoming queue</a>. </p> 129 130<li> <p> The external before-queue content restrictions, as described 131in the <a href="SMTPD_PROXY_README.html">SMTPD_PROXY_README</a> document. This happens while Postfix 132receives mail, before it is stored in the <a href="QSHAPE_README.html#incoming_queue">incoming queue</a>. </p> 133 134<li> <p> Requiring that the client sends the HELO or EHLO command 135before sending the MAIL FROM or ETRN command. This may cause problems 136with home-grown applications that send mail. For this reason, the 137requirement is disabled by default ("<a href="postconf.5.html#smtpd_helo_required">smtpd_helo_required</a> = no"). 138</p> 139 140<li> <p> Disallowing illegal syntax in MAIL FROM or RCPT TO commands. 141This may cause problems with home-grown applications that send 142mail, and with ancient PC mail clients. For this reason, the 143requirement is disabled by default ("<a href="postconf.5.html#strict_rfc821_envelopes">strict_rfc821_envelopes</a> = 144no"). </p> 145 146<ul> 147 148<li> <p> Disallowing <a href="http://tools.ietf.org/html/rfc822">RFC 822</a> address syntax (example: "MAIL FROM: the 149dude <dude@example.com>"). </p> 150 151<li> <p> Disallowing addresses that are not enclosed with <> 152(example: "MAIL FROM: dude@example.com"). </p> 153 154</ul> 155 156<li> <p> Rejecting mail from a non-existent sender address. This form 157of egress filtering helps to slow down worms and other malware, but 158may cause problems with home-grown software that sends out mail 159software with an unreplyable address. For this reason the requirement 160is disabled by default ("<a href="postconf.5.html#smtpd_reject_unlisted_sender">smtpd_reject_unlisted_sender</a> = no"). </p> 161 162<li> <p> Rejecting mail for a non-existent recipient address. This 163form of ingress filtering helps to keep the mail queue free of 164undeliverable MAILER-DAEMON messages. This requirement is enabled 165by default ("<a href="postconf.5.html#smtpd_reject_unlisted_recipient">smtpd_reject_unlisted_recipient</a> = yes"). </p> 166 167</ul> 168 169<h2> <a name="lists"> Getting selective with SMTP access restriction 170lists </a> </h2> 171 172<p> Postfix allows you to specify lists of access restrictions for 173each stage of the SMTP conversation. Individual restrictions are 174described in the <a href="postconf.5.html">postconf(5)</a> manual page. </p> 175 176<p> Examples of simple restriction lists are: </p> 177 178<pre> 179/etc/postfix/<a href="postconf.5.html">main.cf</a>: 180 # Allow connections from trusted networks only. 181 <a href="postconf.5.html#smtpd_client_restrictions">smtpd_client_restrictions</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>, reject 182 183 # Don't talk to mail systems that don't know their own hostname. 184 # With Postfix < 2.3, specify <a href="postconf.5.html#reject_unknown_helo_hostname">reject_unknown_hostname</a>. 185 <a href="postconf.5.html#smtpd_helo_restrictions">smtpd_helo_restrictions</a> = <a href="postconf.5.html#reject_unknown_helo_hostname">reject_unknown_helo_hostname</a> 186 187 # Don't accept mail from domains that don't exist. 188 <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> 189 190 # Relay control (Postfix 2.10 and later): local clients and 191 # authenticated clients may specify any destination domain. 192 <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>, 193 <a href="postconf.5.html#permit_sasl_authenticated">permit_sasl_authenticated</a>, 194 <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a> 195 196 # Spam control: exclude local clients and authenticated clients 197 # from DNSBL lookups. 198 <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>, 199 <a href="postconf.5.html#permit_sasl_authenticated">permit_sasl_authenticated</a>, 200 # <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a> is not needed here if the mail 201 # relay policy is specified under <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> 202 # (available with Postfix 2.10 and later). 203 <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a> 204 <a href="postconf.5.html#reject_rbl_client">reject_rbl_client</a> zen.spamhaus.org, 205 <a href="postconf.5.html#reject_rhsbl_helo">reject_rhsbl_helo</a> dbl.spamhaus.org, 206 <a href="postconf.5.html#reject_rhsbl_sender">reject_rhsbl_sender</a> dbl.spamhaus.org 207 208 # Block clients that speak too early. 209 <a href="postconf.5.html#smtpd_data_restrictions">smtpd_data_restrictions</a> = <a href="postconf.5.html#reject_unauth_pipelining">reject_unauth_pipelining</a> 210 211 # Enforce mail volume quota via policy service callouts. 212 <a href="postconf.5.html#smtpd_end_of_data_restrictions">smtpd_end_of_data_restrictions</a> = <a href="postconf.5.html#check_policy_service">check_policy_service</a> unix:private/policy 213</pre> 214 215<p> Each restriction list is evaluated from left to right until 216some restriction produces a result of PERMIT, REJECT or DEFER (try 217again later). The end of the list is equivalent to a PERMIT result. 218By placing a PERMIT restriction before a REJECT restriction you 219can make exceptions for specific clients or users. This is called 220whitelisting; the fourth example above allows mail from local 221networks but otherwise rejects mail to arbitrary destinations. </p> 222 223<p> The table below summarizes the purpose of each SMTP access 224restriction list. All lists use the exact same syntax; they differ 225only in the time of evaluation and in the effect of a REJECT or 226DEFER result. </p> 227 228<blockquote> 229 230<table border="1"> 231 232<tr> <th> Restriction list name </th> <th> Version </th> <th> Status 233</th> <th> Effect 234of REJECT or DEFER result </th> </tr> 235 236<tr> <td> <a href="postconf.5.html#smtpd_client_restrictions">smtpd_client_restrictions</a> </td> <td> All </td> <td> 237Optional </td> <td> 238Reject all client commands </td> </tr> 239 240<tr> <td> <a href="postconf.5.html#smtpd_helo_restrictions">smtpd_helo_restrictions</a> </td> <td> All </td> <td> Optional 241</td> <td> 242Reject HELO/EHLO information </td> </tr> 243 244<tr> <td> <a href="postconf.5.html#smtpd_sender_restrictions">smtpd_sender_restrictions</a> </td> <td> All </td> <td> 245Optional </td> <td> 246Reject MAIL FROM information </td> </tr> 247 248<tr> <td rowspan="2"> <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> </td> <td> ≥ 2.10 249</td> <td> Required if <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> does not enforce 250relay policy</td> 251<td rowspan="2"> Reject RCPT TO information </td> </tr> 252 253<tr> <td> < 2.10</td> <td> Not available </td> 254</tr> 255 256<tr> <td rowspan="2"> <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> </td> <td> ≥ 2572.10 </td> <td> Required if <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> does not enforce 258relay policy</td> 259<td rowspan="2"> Reject RCPT TO information </td> </tr> 260 261<tr> <td> < 2.10</td> <td> Required </td> </tr> 262 263<tr> <td> <a href="postconf.5.html#smtpd_data_restrictions">smtpd_data_restrictions</a> </td> <td> ≥ 2.0 </td> <td> 264Optional </td> <td> 265Reject DATA command </td> </tr> 266 267<tr> <td> <a href="postconf.5.html#smtpd_end_of_data_restrictions">smtpd_end_of_data_restrictions</a> </td> <td> ≥ 2.2 </td> 268<td> Optional </td> <td> 269Reject END-OF-DATA command </td> </tr> 270 271<tr> <td> <a href="postconf.5.html#smtpd_etrn_restrictions">smtpd_etrn_restrictions</a> </td> <td> All </td> <td> Optional 272</td> <td> 273Reject ETRN command </td> </tr> 274 275</table> 276 277</blockquote> 278 279<h2> <a name="timing"> Delayed evaluation of SMTP access restriction lists 280</a> </h2> 281 282<p> Early Postfix versions evaluated SMTP access restrictions lists 283as early as possible. The client restriction list was evaluated 284before Postfix sent the "220 $<a href="postconf.5.html#myhostname">myhostname</a>..." greeting banner to 285the SMTP client, the helo restriction list was evaluated before 286Postfix replied to the HELO (EHLO) command, the sender restriction 287list was evaluated before Postfix replied to the MAIL FROM command, 288and so on. This approach turned out to be difficult to use. </p> 289 290<p> Current Postfix versions postpone the evaluation of client, 291helo and sender restriction lists until the RCPT TO or ETRN command. 292This behavior is controlled by the <a href="postconf.5.html#smtpd_delay_reject">smtpd_delay_reject</a> parameter. 293Restriction lists are still evaluated in the proper order of (client, 294helo, etrn) or (client, helo, sender, relay, recipient, data, or 295end-of-data) restrictions. 296When a restriction list (example: client) evaluates to REJECT or 297DEFER the restriction lists that follow (example: helo, sender, etc.) 298are skipped. </p> 299 300<p> Around the time that <a href="postconf.5.html#smtpd_delay_reject">smtpd_delay_reject</a> was introduced, Postfix 301was also changed to support mixed restriction lists that combine 302information about the client, helo, sender and recipient or etrn 303command. </p> 304 305<p> Benefits of delayed restriction evaluation, and of restriction 306mixing: </p> 307 308<ul> 309 310<li> <p> Some SMTP clients do not expect a negative reply early in 311the SMTP session. When the bad news is postponed until the RCPT TO 312reply, the client goes away as it is supposed to, instead of hanging 313around until a timeout happens, or worse, going into an endless 314connect-reject-connect loop. </p> 315 316<li> <p> Postfix can log more useful information. For example, when 317Postfix rejects a client name or address and delays the action 318until the RCPT TO command, it can log the sender and the recipient 319address. This is more useful than logging only the client hostname 320and IP address and not knowing whose mail was being blocked. </p> 321 322<li> <p> Mixing is needed for complex whitelisting policies. For 323example, in order to reject local sender addresses in mail from 324non-local clients, you need to be able to mix restrictions on client 325information with restrictions on sender information in the same 326restriction list. Without this ability, many per-user access 327restrictions would be impossible to express. </p> 328 329</ul> 330 331<h2> <a name="danger"> Dangerous use of smtpd_recipient_restrictions </a> </h2> 332 333<p> By now the reader may wonder why we need smtpd client, helo 334or sender restrictions, when their evaluation is postponed until 335the RCPT TO or ETRN command. Some people recommend placing ALL the 336access restrictions in the <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> list. 337Unfortunately, this can result in too permissive access. How is 338this possible? </p> 339 340<p> The purpose of the <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> feature is to 341control how Postfix replies to the RCPT TO command. If the restriction 342list evaluates to REJECT or DEFER, the recipient address is rejected; 343no surprises here. If the result is PERMIT, then the recipient 344address is accepted. And this is where surprises can happen. </p> 345 346<p> The problem is that Postfix versions before 2.10 did not have 347<a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a>. They combined the mail relay and spam 348blocking policies, under <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a>. The result 349is that a permissive spam blocking policy could unexpectedly result 350in a permissive mail relay policy. </p> 351 352<p> Here is an example that shows when a PERMIT result can result 353in too much access permission: </p> 354 355<pre> 3561 /etc/postfix/<a href="postconf.5.html">main.cf</a>: 3572 <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> = 3583 <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a> 3594 <a href="postconf.5.html#check_helo_access">check_helo_access</a> <a href="DATABASE_README.html#types">hash</a>:/etc/postfix/helo_access 3605 <a href="postconf.5.html#reject_unknown_helo_hostname">reject_unknown_helo_hostname</a> 3616 <b><a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a></b> 3627 3638 /etc/postfix/helo_access: 3649 localhost.localdomain PERMIT 365</pre> 366 367<p> Line 5 rejects mail from hosts that don't specify a proper 368hostname in the HELO command (with Postfix < 2.3, specify 369<a href="postconf.5.html#reject_unknown_helo_hostname">reject_unknown_hostname</a>). Lines 4 and 9 make an exception to 370allow mail from some machine that announces itself with "HELO 371localhost.localdomain". </p> 372 373<p> The problem with this configuration is that 374<a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> evaluates to PERMIT for EVERY host 375that announces itself as "localhost.localdomain", making Postfix 376an open relay for all such hosts. </p> 377 378<p> With Postfix before version 2.10 you should place non-recipient 379restrictions AFTER the <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a> restriction, not 380before. In the above example, the HELO based restrictions should 381be placed AFTER <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a>, or better, the HELO 382based restrictions should be placed under <a href="postconf.5.html#smtpd_helo_restrictions">smtpd_helo_restrictions</a> 383where they can do no harm. </p> 384 385<pre> 3861 /etc/postfix/<a href="postconf.5.html">main.cf</a>: 3872 <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> = 3883 <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a> 3894 <b><a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a></b> 3905 <a href="postconf.5.html#check_helo_access">check_helo_access</a> <a href="DATABASE_README.html#types">hash</a>:/etc/postfix/helo_access 3916 <a href="postconf.5.html#reject_unknown_helo_hostname">reject_unknown_helo_hostname</a> 3927 3938 /etc/postfix/helo_access: 3949 localhost.localdomain PERMIT 395</pre> 396 397<p> The above mistake will not happen with Postfix 2.10 and later, 398when the relay policy is specified under <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a>, 399and the spam blocking policy under <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a>. 400Then, a permissive spam blocking policy will not result in a 401permissive mail relay policy. </p> 402 403<h2> <a name="testing"> SMTP access rule testing </a> </h2> 404 405<p> Postfix has several features that aid in SMTP access rule 406testing: </p> 407 408<dl> 409 410<dt> <a href="postconf.5.html#soft_bounce">soft_bounce</a> </dt> <dd> <p> This is a safety net that changes 411SMTP server REJECT actions into DEFER (try again later) actions. 412This keeps mail queued that would otherwise be returned to the 413sender. Specify "<a href="postconf.5.html#soft_bounce">soft_bounce</a> = yes" in the <a href="postconf.5.html">main.cf</a> file to prevent 414the Postfix SMTP server from rejecting mail permanently, by changing 415all 5xx SMTP reply codes into 4xx. </p> </dd> 416 417<dt> <a href="postconf.5.html#warn_if_reject">warn_if_reject</a> </dt> <dd> <p> When placed before a reject-type 418restriction, access table query, or <a href="postconf.5.html#check_policy_service">check_policy_service</a> query, 419this logs a "reject_warning" message instead of rejecting a request 420(when a reject-type restriction fails due to a temporary error, 421this logs a "reject_warning" message for any implicit "<a href="postconf.5.html#defer_if_permit">defer_if_permit</a>" 422actions that would normally prevent mail from being accepted by 423some later access restriction). This feature has no effect on 424<a href="postconf.5.html#defer_if_reject">defer_if_reject</a> restrictions. </p> </dd> 425 426<dt> XCLIENT </dt> <dd> <p> With this feature, an authorized SMTP 427client can impersonate other systems and perform realistic SMTP 428access rule tests. Examples of how to impersonate other systems 429for access rule testing are given at the end of the <a href="XCLIENT_README.html">XCLIENT_README</a> 430document. <br> This feature is available in Postfix 2.1. </p> 431</dd> 432 433</dl> 434 435</body> 436 437</html> 438