summaryrefslogtreecommitdiffstats
path: root/html/SMTPD_ACCESS_README.html
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--html/SMTPD_ACCESS_README.html438
1 files changed, 438 insertions, 0 deletions
diff --git a/html/SMTPD_ACCESS_README.html b/html/SMTPD_ACCESS_README.html
new file mode 100644
index 0000000..d77d3bc
--- /dev/null
+++ b/html/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
+<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> 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 <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="http://tools.ietf.org/html/rfc822">RFC 822</a> 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 ("<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 &lt; 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
+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> <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> &ge;
+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> &lt; 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> &ge; 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> &lt; 2.10</td> <td> Not available </td>
+</tr>
+
+<tr> <td> <a href="postconf.5.html#smtpd_data_restrictions">smtpd_data_restrictions</a> </td> <td> &ge; 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> &ge; 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 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 <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 &lt; 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>