diff options
Diffstat (limited to 'proto/SMTPD_ACCESS_README.html')
| -rw-r--r-- | proto/SMTPD_ACCESS_README.html | 440 |
1 files changed, 440 insertions, 0 deletions
diff --git a/proto/SMTPD_ACCESS_README.html b/proto/SMTPD_ACCESS_README.html new file mode 100644 index 0000000..971f6cd --- /dev/null +++ b/proto/SMTPD_ACCESS_README.html @@ -0,0 +1,440 @@ +<!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"> +<link rel='stylesheet' type='text/css' href='postfix-doc.css'> + +</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 +http://www.mail-abuse.org/ 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 smtpd_relay_restrictions parameter in the postconf(5) manual +page, and the information that is referenced from there. </p> + +<blockquote> <p> NOTE: Postfix versions before 2.10 did not have +smtpd_relay_restrictions. They combined the mail relay and spam +blocking policies, under smtpd_recipient_restrictions. 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 SMTPD_POLICY_README document. +Sender/recipient address verification is the subject of the +ADDRESS_VERIFICATION_README 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 RESTRICTION_CLASS_README 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 header_checks and body_checks content +restrictions, as described in the BUILTIN_FILTER_README document. +This happens while Postfix receives mail, before it is stored in +the incoming queue. </p> + +<li> <p> The external before-queue content restrictions, as described +in the SMTPD_PROXY_README document. This happens while Postfix +receives mail, before it is stored in the incoming queue. </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 ("smtpd_helo_required = 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 ("strict_rfc821_envelopes = +no"). </p> + +<ul> + +<li> <p> Disallowing RFC 822 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 ("smtpd_reject_unlisted_sender = 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 ("smtpd_reject_unlisted_recipient = 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 postconf(5) manual page. </p> + +<p> Examples of simple restriction lists are: </p> + +<pre> +/etc/postfix/main.cf: + # Allow connections from trusted networks only. + smtpd_client_restrictions = permit_mynetworks, reject + + # Don't talk to mail systems that don't know their own hostname. + # With Postfix < 2.3, specify reject_unknown_hostname. + smtpd_helo_restrictions = reject_unknown_helo_hostname + + # Don't accept mail from domains that don't exist. + smtpd_sender_restrictions = reject_unknown_sender_domain + + # Spam control: exclude local clients and authenticated clients + # from DNSBL lookups. + smtpd_recipient_restrictions = permit_mynetworks, + permit_sasl_authenticated, + # reject_unauth_destination is not needed here if the mail + # relay policy is specified under smtpd_relay_restrictions + # (available with Postfix 2.10 and later). + reject_unauth_destination + reject_rbl_client zen.spamhaus.org, + reject_rhsbl_reverse_client dbl.spamhaus.org, + reject_rhsbl_helo dbl.spamhaus.org, + reject_rhsbl_sender dbl.spamhaus.org + + # Relay control (Postfix 2.10 and later): local clients and + # authenticated clients may specify any destination domain. + smtpd_relay_restrictions = permit_mynetworks, + permit_sasl_authenticated, + reject_unauth_destination + + # Block clients that speak too early. + smtpd_data_restrictions = reject_unauth_pipelining + + # Enforce mail volume quota via policy service callouts. + smtpd_end_of_data_restrictions = check_policy_service 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 smtpd_relay_restrictions 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> smtpd_client_restrictions </td> <td> All </td> <td> +Optional </td> <td> +Reject all client commands </td> </tr> + +<tr> <td> smtpd_helo_restrictions </td> <td> All </td> <td> Optional +</td> <td> +Reject HELO/EHLO information </td> </tr> + +<tr> <td> smtpd_sender_restrictions </td> <td> All </td> <td> +Optional </td> <td> +Reject MAIL FROM information </td> </tr> + +<tr> <td rowspan="2"> smtpd_recipient_restrictions </td> <td> ≥ +2.10 </td> <td> Required if smtpd_relay_restrictions 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"> smtpd_relay_restrictions </td> <td> ≥ 2.10 +</td> <td> Required if smtpd_recipient_restrictions 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> smtpd_data_restrictions </td> <td> ≥ 2.0 </td> <td> +Optional </td> <td> +Reject DATA command </td> </tr> + +<tr> <td> smtpd_end_of_data_restrictions </td> <td> ≥ 2.2 </td> +<td> Optional </td> <td> +Reject END-OF-DATA command </td> </tr> + +<tr> <td> smtpd_etrn_restrictions </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 $myhostname..." 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 smtpd_delay_reject 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 smtpd_delay_reject 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 smtpd_recipient_restrictions list. +Unfortunately, this can result in too permissive access. How is +this possible? </p> + +<p> The purpose of the smtpd_recipient_restrictions 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 +smtpd_relay_restrictions. They combined the mail relay and spam +blocking policies, under smtpd_recipient_restrictions. 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/main.cf: +2 smtpd_recipient_restrictions = +3 permit_mynetworks +4 check_helo_access hash:/etc/postfix/helo_access +5 reject_unknown_helo_hostname +6 <b>reject_unauth_destination</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 +reject_unknown_hostname). 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 +smtpd_recipient_restrictions 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 reject_unauth_destination restriction, not +before. In the above example, the HELO based restrictions should +be placed AFTER reject_unauth_destination, or better, the HELO +based restrictions should be placed under smtpd_helo_restrictions +where they can do no harm. </p> + +<pre> +1 /etc/postfix/main.cf: +2 smtpd_recipient_restrictions = +3 permit_mynetworks +4 <b>reject_unauth_destination</b> +5 check_helo_access hash:/etc/postfix/helo_access +6 reject_unknown_helo_hostname +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 smtpd_relay_restrictions, +and the spam blocking policy under smtpd_recipient_restrictions. +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> soft_bounce </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 "soft_bounce = yes" in the main.cf file to prevent +the Postfix SMTP server from rejecting mail permanently, by changing +all 5xx SMTP reply codes into 4xx. </p> </dd> + +<dt> warn_if_reject </dt> <dd> <p> When placed before a reject-type +restriction, access table query, or check_policy_service 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 "defer_if_permit" +actions that would normally prevent mail from being accepted by +some later access restriction). This feature has no effect on +defer_if_reject 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 XCLIENT_README +document. <br> This feature is available in Postfix 2.1. </p> +</dd> + +</dl> + +</body> + +</html> |