357 lines
14 KiB
HTML
357 lines
14 KiB
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, or to domains that are configured as authorized relay
|
|
destinations. For a description of the default policy, see the
|
|
smtpd_recipient_restrictions parameter in the postconf(5) manual
|
|
page, and the information that is referenced from there. </p>
|
|
|
|
<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 <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.
|
|
smtpd_helo_restrictions = reject_unknown_hostname
|
|
|
|
# Don't accept mail from domains that don't exist.
|
|
smtpd_sender_restrictions = reject_unknown_sender_domain
|
|
|
|
# Whitelisting: local clients may specify any destination. Others may not.
|
|
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
|
|
</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 the 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 last 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> Status </th> <th> Effect
|
|
of REJECT or DEFER result </th> </tr>
|
|
|
|
<tr> <td> smtpd_client_restrictions </td> <td> Optional </td> <td>
|
|
Reject all client commands </td> </tr>
|
|
|
|
<tr> <td> smtpd_helo_restrictions </td> <td> Optional </td> <td>
|
|
Reject HELO/EHLO information </td> </tr>
|
|
|
|
<tr> <td> smtpd_sender_restrictions </td> <td> Optional </td> <td>
|
|
Reject MAIL FROM information </td> </tr>
|
|
|
|
<tr> <td> smtpd_recipient_restrictions </td> <td> Required </td>
|
|
<td> Reject RCPT TO information </td> </tr>
|
|
|
|
<tr> <td> smtpd_data_restrictions </td> <td> Optional </td> <td>
|
|
Reject DATA command </td> </tr>
|
|
|
|
<tr> <td> smtpd_etrn_restrictions </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, recipient, data) restrictions.
|
|
When a restriction list (example: client) evaluates to REJECT or
|
|
DEFER the other restriction lists (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> 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_hostname
|
|
6 reject_unauth_destination
|
|
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. 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> In order to avoid surprises like these with
|
|
smtpd_recipient_restrictions, 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>
|
|
|
|
<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> This is a different safety net
|
|
that changes SMTP server REJECT actions into warnings. Instead of
|
|
rejecting a command, Postfix logs what it would reject. Specify
|
|
"warn_if_reject" in an SMTP access restriction list, before the
|
|
restriction that you want to test without actually rejecting mail.
|
|
</p> </dd>
|
|
|
|
<dt> XCLIENT </dt> <dd> <p> With this Postfix 2.1 feature, authorized
|
|
SMTP clients can impersonate other systems, so that you can do
|
|
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. </p> </dd>
|
|
|
|
</dl>
|
|
|
|
</body>
|
|
|
|
</html>
|