summaryrefslogtreecommitdiffstats
path: root/proto/SMTPD_ACCESS_README.html
diff options
context:
space:
mode:
Diffstat (limited to 'proto/SMTPD_ACCESS_README.html')
-rw-r--r--proto/SMTPD_ACCESS_README.html438
1 files changed, 438 insertions, 0 deletions
diff --git a/proto/SMTPD_ACCESS_README.html b/proto/SMTPD_ACCESS_README.html
new file mode 100644
index 0000000..af73f78
--- /dev/null
+++ b/proto/SMTPD_ACCESS_README.html
@@ -0,0 +1,438 @@
+<!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=us-ascii">
+
+</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 blacklists. 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> Blacklist oriented: some SMTP server access controls
+query blacklists 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 blacklists 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 &lt;dude@example.com&gt;"). </p>
+
+<li> <p> Disallowing addresses that are not enclosed with &lt;&gt;
+(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 &lt; 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
+whitelisting; the fourth example above allows mail from local
+networks 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> &ge;
+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> &lt; 2.10</td> <td> Required </td> </tr>
+
+<tr> <td rowspan="2"> smtpd_relay_restrictions </td> <td> &ge; 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> &lt; 2.10</td> <td> Not available </td>
+</tr>
+
+<tr> <td> smtpd_data_restrictions </td> <td> &ge; 2.0 </td> <td>
+Optional </td> <td>
+Reject DATA command </td> </tr>
+
+<tr> <td> smtpd_end_of_data_restrictions </td> <td> &ge; 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 whitelisting 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 &lt; 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>