diff options
Diffstat (limited to 'html/SMTPD_ACCESS_README.html')
| -rw-r--r-- | html/SMTPD_ACCESS_README.html | 439 |
1 files changed, 439 insertions, 0 deletions
diff --git a/html/SMTPD_ACCESS_README.html b/html/SMTPD_ACCESS_README.html new file mode 100644 index 0000000..478d153 --- /dev/null +++ b/html/SMTPD_ACCESS_README.html @@ -0,0 +1,439 @@ +<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" + "http://www.w3.org/TR/html4/loose.dtd"> + +<html> + +<head> + +<title>Postfix SMTP relay and access control </title> + +<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> + +</head> + +<body> + +<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix +SMTP relay and access control </h1> + +<hr> + +<h2> Introduction </h2> + +<p> The Postfix SMTP server receives mail from the network and is +exposed to the big bad world of junk email and viruses. This document +introduces the built-in and external methods that control what SMTP +mail Postfix will accept, what mistakes to avoid, and how to test +your configuration. </p> + +<p> Topics covered in this document: </p> + +<ul> + +<li> <a href="#relay"> Relay control, junk mail control, and per-user +policies </a> + +<li> <a href="#global"> Restrictions that apply to all SMTP mail +</a> + +<li> <a href="#lists"> Getting selective with SMTP access restriction +lists </a> + +<li> <a href="#timing"> Delayed evaluation of SMTP access restriction lists </a> + +<li> <a href="#danger"> Dangerous use of smtpd_recipient_restrictions +</a> + +<li> <a href="#testing"> SMTP access rule testing </a> + +</ul> + +<h2> <a name="relay"> Relay control, junk mail control, and per-user +policies </a> </h2> + +<p> In a distant past, the Internet was a friendly environment. +Mail servers happily forwarded mail on behalf of anyone towards +any destination. On today's Internet, spammers abuse servers that +forward mail from arbitrary systems, and abused systems end up on +anti-spammer denylists. See, for example, the information on +<a href="http://www.mail-abuse.org/">http://www.mail-abuse.org/</a> and other websites. </p> + +<p> By default, Postfix has a moderately restrictive approach to +mail relaying. Postfix forwards mail only from clients in trusted +networks, from clients that have authenticated with SASL, or to +domains that are configured as authorized relay +destinations. For a description of the default mail relay policy, +see 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 +page, and the information that is referenced from there. </p> + +<blockquote> <p> NOTE: Postfix versions before 2.10 did not have +<a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a>. They combined the mail relay and spam +blocking policies, under <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a>. This could +lead to unexpected results. For example, a permissive spam blocking +policy could unexpectedly result in a permissive mail relay policy. +An example of this is documented under "<a href="#danger">Dangerous +use of smtpd_recipient_restrictions</a>". </p> </blockquote> + +<p> Most of the Postfix SMTP server access controls are targeted +at stopping junk email. </p> + +<ul> + +<li> <p> Protocol oriented: some SMTP server access controls block +mail by being very strict with respect to the SMTP protocol; these +catch poorly implemented and/or poorly configured junk email +software, as well as email worms that come with their own non-standard +SMTP client implementations. Protocol-oriented access controls +become less useful over time as spammers and worm writers learn to +read RFC documents. </p> + +<li> <p> Denylist oriented: some SMTP server access controls +query denylists with known to be bad sites such as open mail +relays, open web proxies, and home computers that have been +compromised and that are under remote control by criminals. The +effectiveness of these denylists depends on how complete and how +up to date they are. </p> + +<li> <p> Threshold oriented: some SMTP server access controls attempt +to raise the bar by either making the client do more work (greylisting) +or by asking for a second opinion (SPF and sender/recipient address +verification). The greylisting and SPF policies are implemented +externally, and are the subject of the <a href="SMTPD_POLICY_README.html">SMTPD_POLICY_README</a> document. +Sender/recipient address verification is the subject of the +<a href="ADDRESS_VERIFICATION_README.html">ADDRESS_VERIFICATION_README</a> document. </p> + +</ul> + +<p> Unfortunately, all junk mail controls have the possibility of +falsely rejecting legitimate mail. This can be a problem for sites +with many different types of users. For some users it is unacceptable +when any junk email slips through, while for other users the world +comes to an end when a single legitimate email message is blocked. +Because there is no single policy that is "right" for all users, +Postfix supports different SMTP access restrictions for different +users. This is described in the <a href="RESTRICTION_CLASS_README.html">RESTRICTION_CLASS_README</a> document. +</p> + +<h2> <a name="global"> Restrictions that apply to all SMTP mail </a> </h2> + +<p> Besides the restrictions that can be made configurable per +client or per user as described in the next section, Postfix +implements a few restrictions that apply to all SMTP mail. </p> + +<ul> + +<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 +restrictions, as described in the <a href="BUILTIN_FILTER_README.html">BUILTIN_FILTER_README</a> document. +This happens while Postfix receives mail, before it is stored in +the <a href="QSHAPE_README.html#incoming_queue">incoming queue</a>. </p> + +<li> <p> The external before-queue content restrictions, as described +in the <a href="SMTPD_PROXY_README.html">SMTPD_PROXY_README</a> document. This happens while Postfix +receives mail, before it is stored in the <a href="QSHAPE_README.html#incoming_queue">incoming queue</a>. </p> + +<li> <p> Requiring that the client sends the HELO or EHLO command +before sending the MAIL FROM or ETRN command. This may cause problems +with home-grown applications that send mail. For this reason, the +requirement is disabled by default ("<a href="postconf.5.html#smtpd_helo_required">smtpd_helo_required</a> = no"). +</p> + +<li> <p> Disallowing illegal syntax in MAIL FROM or RCPT TO commands. +This may cause problems with home-grown applications that send +mail, and with ancient PC mail clients. For this reason, the +requirement is disabled by default ("<a href="postconf.5.html#strict_rfc821_envelopes">strict_rfc821_envelopes</a> = +no"). </p> + +<ul> + +<li> <p> Disallowing <a href="https://tools.ietf.org/html/rfc822">RFC 822</a> address syntax (example: "MAIL FROM: the +dude <dude@example.com>"). </p> + +<li> <p> Disallowing addresses that are not enclosed with <> +(example: "MAIL FROM: dude@example.com"). </p> + +</ul> + +<li> <p> Rejecting mail from a non-existent sender address. This form +of egress filtering helps to slow down worms and other malware, but +may cause problems with home-grown software that sends out mail +software with an unreplyable address. For this reason the requirement +is disabled by default ("<a href="postconf.5.html#smtpd_reject_unlisted_sender">smtpd_reject_unlisted_sender</a> = no"). </p> + +<li> <p> Rejecting mail for a non-existent recipient address. This +form of ingress filtering helps to keep the mail queue free of +undeliverable MAILER-DAEMON messages. This requirement is enabled +by default ("<a href="postconf.5.html#smtpd_reject_unlisted_recipient">smtpd_reject_unlisted_recipient</a> = yes"). </p> + +</ul> + +<h2> <a name="lists"> Getting selective with SMTP access restriction +lists </a> </h2> + +<p> Postfix allows you to specify lists of access restrictions for +each stage of the SMTP conversation. Individual restrictions are +described in the <a href="postconf.5.html">postconf(5)</a> manual page. </p> + +<p> Examples of simple restriction lists are: </p> + +<pre> +/etc/postfix/<a href="postconf.5.html">main.cf</a>: + # Allow connections from trusted networks only. + <a href="postconf.5.html#smtpd_client_restrictions">smtpd_client_restrictions</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>, reject + + # Don't talk to mail systems that don't know their own hostname. + # With Postfix < 2.3, specify <a href="postconf.5.html#reject_unknown_helo_hostname">reject_unknown_hostname</a>. + <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> + + # Don't accept mail from domains that don't exist. + <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> + + # Spam control: exclude local clients and authenticated clients + # from DNSBL lookups. + <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#permit_sasl_authenticated">permit_sasl_authenticated</a>, + # <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a> is not needed here if the mail + # relay policy is specified under <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> + # (available with Postfix 2.10 and later). + <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a> + <a href="postconf.5.html#reject_rbl_client">reject_rbl_client</a> zen.spamhaus.org, + <a href="postconf.5.html#reject_rhsbl_reverse_client">reject_rhsbl_reverse_client</a> dbl.spamhaus.org, + <a href="postconf.5.html#reject_rhsbl_helo">reject_rhsbl_helo</a> dbl.spamhaus.org, + <a href="postconf.5.html#reject_rhsbl_sender">reject_rhsbl_sender</a> dbl.spamhaus.org + + # Relay control (Postfix 2.10 and later): local clients and + # authenticated clients may specify any destination domain. + <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>, + <a href="postconf.5.html#permit_sasl_authenticated">permit_sasl_authenticated</a>, + <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a> + + # Block clients that speak too early. + <a href="postconf.5.html#smtpd_data_restrictions">smtpd_data_restrictions</a> = <a href="postconf.5.html#reject_unauth_pipelining">reject_unauth_pipelining</a> + + # Enforce mail volume quota via policy service callouts. + <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 +</pre> + +<p> Each restriction list is evaluated from left to right until +some restriction produces a result of PERMIT, REJECT or DEFER (try +again later). The end of each list is equivalent to a PERMIT result. +By placing a PERMIT restriction before a REJECT restriction you +can make exceptions for specific clients or users. This is called +allowlisting; the <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> example above allows mail from local +networks, and from SASL authenticated clients, but otherwise rejects mail +to arbitrary destinations. </p> + +<p> The table below summarizes the purpose of each SMTP access +restriction list. All lists use the exact same syntax; they differ +only in the time of evaluation and in the effect of a REJECT or +DEFER result. </p> + +<blockquote> + +<table border="1"> + +<tr> <th> Restriction list name </th> <th> Version </th> <th> Status +</th> <th> Effect +of REJECT or DEFER result </th> </tr> + +<tr> <td> <a href="postconf.5.html#smtpd_client_restrictions">smtpd_client_restrictions</a> </td> <td> All </td> <td> +Optional </td> <td> +Reject all client commands </td> </tr> + +<tr> <td> <a href="postconf.5.html#smtpd_helo_restrictions">smtpd_helo_restrictions</a> </td> <td> All </td> <td> Optional +</td> <td> +Reject HELO/EHLO information </td> </tr> + +<tr> <td> <a href="postconf.5.html#smtpd_sender_restrictions">smtpd_sender_restrictions</a> </td> <td> All </td> <td> +Optional </td> <td> +Reject MAIL FROM information </td> </tr> + +<tr> <td rowspan="2"> <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> </td> <td> ≥ +2.10 </td> <td> Required if <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> does not enforce +relay policy</td> +<td rowspan="2"> Reject RCPT TO information </td> </tr> + +<tr> <td> < 2.10</td> <td> Required </td> </tr> + +<tr> <td rowspan="2"> <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> </td> <td> ≥ 2.10 +</td> <td> Required if <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> does not enforce +relay policy</td> +<td rowspan="2"> Reject RCPT TO information </td> </tr> + +<tr> <td> < 2.10</td> <td> Not available </td> +</tr> + +<tr> <td> <a href="postconf.5.html#smtpd_data_restrictions">smtpd_data_restrictions</a> </td> <td> ≥ 2.0 </td> <td> +Optional </td> <td> +Reject DATA command </td> </tr> + +<tr> <td> <a href="postconf.5.html#smtpd_end_of_data_restrictions">smtpd_end_of_data_restrictions</a> </td> <td> ≥ 2.2 </td> +<td> Optional </td> <td> +Reject END-OF-DATA command </td> </tr> + +<tr> <td> <a href="postconf.5.html#smtpd_etrn_restrictions">smtpd_etrn_restrictions</a> </td> <td> All </td> <td> Optional +</td> <td> +Reject ETRN command </td> </tr> + +</table> + +</blockquote> + +<h2> <a name="timing"> Delayed evaluation of SMTP access restriction lists +</a> </h2> + +<p> Early Postfix versions evaluated SMTP access restrictions lists +as early as possible. The client restriction list was evaluated +before Postfix sent the "220 $<a href="postconf.5.html#myhostname">myhostname</a>..." greeting banner to +the SMTP client, the helo restriction list was evaluated before +Postfix replied to the HELO (EHLO) command, the sender restriction +list was evaluated before Postfix replied to the MAIL FROM command, +and so on. This approach turned out to be difficult to use. </p> + +<p> Current Postfix versions postpone the evaluation of client, +helo and sender restriction lists until the RCPT TO or ETRN command. +This behavior is controlled by the <a href="postconf.5.html#smtpd_delay_reject">smtpd_delay_reject</a> parameter. +Restriction lists are still evaluated in the proper order of (client, +helo, etrn) or (client, helo, sender, relay, recipient, data, or +end-of-data) restrictions. +When a restriction list (example: client) evaluates to REJECT or +DEFER the restriction lists that follow (example: helo, sender, etc.) +are skipped. </p> + +<p> Around the time that <a href="postconf.5.html#smtpd_delay_reject">smtpd_delay_reject</a> was introduced, Postfix +was also changed to support mixed restriction lists that combine +information about the client, helo, sender and recipient or etrn +command. </p> + +<p> Benefits of delayed restriction evaluation, and of restriction +mixing: </p> + +<ul> + +<li> <p> Some SMTP clients do not expect a negative reply early in +the SMTP session. When the bad news is postponed until the RCPT TO +reply, the client goes away as it is supposed to, instead of hanging +around until a timeout happens, or worse, going into an endless +connect-reject-connect loop. </p> + +<li> <p> Postfix can log more useful information. For example, when +Postfix rejects a client name or address and delays the action +until the RCPT TO command, it can log the sender and the recipient +address. This is more useful than logging only the client hostname +and IP address and not knowing whose mail was being blocked. </p> + +<li> <p> Mixing is needed for complex allowlisting policies. For +example, in order to reject local sender addresses in mail from +non-local clients, you need to be able to mix restrictions on client +information with restrictions on sender information in the same +restriction list. Without this ability, many per-user access +restrictions would be impossible to express. </p> + +</ul> + +<h2> <a name="danger"> Dangerous use of smtpd_recipient_restrictions </a> </h2> + +<p> By now the reader may wonder why we need smtpd client, helo +or sender restrictions, when their evaluation is postponed until +the RCPT TO or ETRN command. Some people recommend placing ALL the +access restrictions in the <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> list. +Unfortunately, this can result in too permissive access. How is +this possible? </p> + +<p> The purpose of the <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> feature is to +control how Postfix replies to the RCPT TO command. If the restriction +list evaluates to REJECT or DEFER, the recipient address is rejected; +no surprises here. If the result is PERMIT, then the recipient +address is accepted. And this is where surprises can happen. </p> + +<p> The problem is that Postfix versions before 2.10 did not have +<a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a>. They combined the mail relay and spam +blocking policies, under <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a>. The result +is that a permissive spam blocking policy could unexpectedly result +in a permissive mail relay policy. </p> + +<p> Here is an example that shows when a PERMIT result can result +in too much access permission: </p> + +<pre> +1 /etc/postfix/<a href="postconf.5.html">main.cf</a>: +2 <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> = +3 <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a> +4 <a href="postconf.5.html#check_helo_access">check_helo_access</a> <a href="DATABASE_README.html#types">hash</a>:/etc/postfix/helo_access +5 <a href="postconf.5.html#reject_unknown_helo_hostname">reject_unknown_helo_hostname</a> +6 <b><a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a></b> +7 +8 /etc/postfix/helo_access: +9 localhost.localdomain PERMIT +</pre> + +<p> Line 5 rejects mail from hosts that don't specify a proper +hostname in the HELO command (with Postfix < 2.3, specify +<a href="postconf.5.html#reject_unknown_helo_hostname">reject_unknown_hostname</a>). Lines 4 and 9 make an exception to +allow mail from some machine that announces itself with "HELO +localhost.localdomain". </p> + +<p> The problem with this configuration is that +<a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> evaluates to PERMIT for EVERY host +that announces itself as "localhost.localdomain", making Postfix +an open relay for all such hosts. </p> + +<p> With Postfix before version 2.10 you should place non-recipient +restrictions AFTER the <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a> restriction, not +before. In the above example, the HELO based restrictions should +be placed AFTER <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a>, or better, the HELO +based restrictions should be placed under <a href="postconf.5.html#smtpd_helo_restrictions">smtpd_helo_restrictions</a> +where they can do no harm. </p> + +<pre> +1 /etc/postfix/<a href="postconf.5.html">main.cf</a>: +2 <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> = +3 <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a> +4 <b><a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a></b> +5 <a href="postconf.5.html#check_helo_access">check_helo_access</a> <a href="DATABASE_README.html#types">hash</a>:/etc/postfix/helo_access +6 <a href="postconf.5.html#reject_unknown_helo_hostname">reject_unknown_helo_hostname</a> +7 +8 /etc/postfix/helo_access: +9 localhost.localdomain PERMIT +</pre> + +<p> The above mistake will not happen with Postfix 2.10 and later, +when the relay policy is specified under <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a>, +and the spam blocking policy under <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a>. +Then, a permissive spam blocking policy will not result in a +permissive mail relay policy. </p> + +<h2> <a name="testing"> SMTP access rule testing </a> </h2> + +<p> Postfix has several features that aid in SMTP access rule +testing: </p> + +<dl> + +<dt> <a href="postconf.5.html#soft_bounce">soft_bounce</a> </dt> <dd> <p> This is a safety net that changes +SMTP server REJECT actions into DEFER (try again later) actions. +This keeps mail queued that would otherwise be returned to the +sender. 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 +the Postfix SMTP server from rejecting mail permanently, by changing +all 5xx SMTP reply codes into 4xx. </p> </dd> + +<dt> <a href="postconf.5.html#warn_if_reject">warn_if_reject</a> </dt> <dd> <p> When placed before a reject-type +restriction, access table query, or <a href="postconf.5.html#check_policy_service">check_policy_service</a> query, +this logs a "reject_warning" message instead of rejecting a request +(when a reject-type restriction fails due to a temporary error, +this logs a "reject_warning" message for any implicit "<a href="postconf.5.html#defer_if_permit">defer_if_permit</a>" +actions that would normally prevent mail from being accepted by +some later access restriction). This feature has no effect on +<a href="postconf.5.html#defer_if_reject">defer_if_reject</a> restrictions. </p> </dd> + +<dt> XCLIENT </dt> <dd> <p> With this feature, an authorized SMTP +client can impersonate other systems and perform realistic SMTP +access rule tests. Examples of how to impersonate other systems +for access rule testing are given at the end of the <a href="XCLIENT_README.html">XCLIENT_README</a> +document. <br> This feature is available in Postfix 2.1. </p> +</dd> + +</dl> + +</body> + +</html> |