369 lines
17 KiB
HTML
369 lines
17 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
|
|
<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, or to domains that are configured as authorized relay
|
|
destinations. For a description of the default policy, see the
|
|
<a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> parameter in the <a href="postconf.5.html">postconf(5)</a> 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 <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://www.faqs.org/rfcs/rfc822.html">RFC 822</a> 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 ("<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 < 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>
|
|
|
|
# Whitelisting: local clients may specify any destination. Others may not.
|
|
<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#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 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> <a href="postconf.5.html#smtpd_client_restrictions">smtpd_client_restrictions</a> </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> 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> Optional </td> <td>
|
|
Reject MAIL FROM information </td> </tr>
|
|
|
|
<tr> <td> <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> </td> <td> Required </td>
|
|
<td> Reject RCPT TO information </td> </tr>
|
|
|
|
<tr> <td> <a href="postconf.5.html#smtpd_data_restrictions">smtpd_data_restrictions</a> </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> 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> 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, recipient, data, or end-of-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 <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> 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> hash:/etc/postfix/helo_access
|
|
5 <a href="postconf.5.html#reject_unknown_helo_hostname">reject_unknown_helo_hostname</a>
|
|
6 <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a>
|
|
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
|
|
<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> In order to avoid surprises like these with
|
|
<a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a>, 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>
|
|
|
|
<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> 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
|
|
"<a href="postconf.5.html#warn_if_reject">warn_if_reject</a>" 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
|
|
<a href="XCLIENT_README.html">XCLIENT_README</a> document. </p> </dd>
|
|
|
|
</dl>
|
|
|
|
</body>
|
|
|
|
</html>
|