440 lines
22 KiB
HTML
440 lines
22 KiB
HTML
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"https://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=utf-8">
|
|
<link rel='stylesheet' type='text/css' href='postfix-doc.css'>
|
|
|
|
</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 denylists. See, for example, the information on
|
|
<a href="https://www.spamhaus.org/">https://www.spamhaus.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> Denylist oriented: some SMTP server access controls
|
|
query denylists 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 denylists 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="https://tools.ietf.org/html/rfc822">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>
|
|
|
|
# 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
|
|
allowlisting; the <a href="postconf.5.html#smtpd_relay_restrictions">smtpd_relay_restrictions</a> example above allows mail from local
|
|
networks, and from SASL authenticated clients, 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> ≥
|
|
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> < 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> ≥ 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> < 2.10</td> <td> Not available </td>
|
|
</tr>
|
|
|
|
<tr> <td> <a href="postconf.5.html#smtpd_data_restrictions">smtpd_data_restrictions</a> </td> <td> ≥ 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> ≥ 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 allowlisting 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 < 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>
|