dist/proto/SMTPD_ACCESS_README.html

<!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>