608 lines
26 KiB
HTML
608 lines
26 KiB
HTML
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/html4/loose.dtd">
|
|
|
|
<html>
|
|
|
|
<head>
|
|
|
|
<title>Postfix Address Verification </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 Address Verification Howto</h1>
|
|
|
|
<hr>
|
|
|
|
<h2>WARNING </h2>
|
|
|
|
<p> Recipient address verification may cause an increased load on
|
|
down-stream servers in the case of a dictionary attack or a flood
|
|
of backscatter bounces. Sender address verification may cause your
|
|
site to be blacklisted by some providers. See also the "<a
|
|
href="#limitations">Limitations</a>" section below for more. </p>
|
|
|
|
<h2><a name="summary">What Postfix address verification can do for you</a></h2>
|
|
|
|
<p> Address verification is a feature that allows the Postfix SMTP
|
|
server to block a sender (MAIL FROM) or recipient (RCPT TO) address
|
|
until the address has been verified to be deliverable. </p>
|
|
|
|
<p> The technique has obvious uses to reject junk mail
|
|
with an unreplyable sender address. </p>
|
|
|
|
<p> The technique is also useful to block mail for undeliverable
|
|
recipients, for example on a mail <a href="postconf.5.html#relayhost">relay host</a> that does not have a
|
|
list of all the valid recipient addresses. This prevents undeliverable
|
|
junk mail from entering the queue, so that Postfix doesn't have to
|
|
waste resources trying to send MAILER-DAEMON messages back. </p>
|
|
|
|
<p> This feature is available in Postfix version 2.1 and later. </p>
|
|
|
|
<p> Topics covered in this document: </p>
|
|
|
|
<ul>
|
|
|
|
<li><a href="#how"> How address verification works</a>
|
|
|
|
<li><a href="#limitations">Limitations of address verification</a>
|
|
|
|
<li><a href="#recipient">Recipient address verification</a>
|
|
|
|
<li><a href="#forged_sender">Sender address verification for mail
|
|
from frequently forged domains</a>
|
|
|
|
<li><a href="#sender_always">Sender address verification for all
|
|
email</a>
|
|
|
|
<li><a href="#caching">Address verification database</a>
|
|
|
|
<li><a href="#dirty_secret">Managing the address verification
|
|
database</a>
|
|
|
|
<li><a href="#probe_routing">Controlling the routing of address
|
|
verification probes</a>
|
|
|
|
<li><a href="#forced_examples">Forced probe routing examples</a>
|
|
|
|
<li><a href="#forced_limitations">Limitations of forced probe routing</a>
|
|
|
|
</ul>
|
|
|
|
<h2><a name="how">How address verification works</a></h2>
|
|
|
|
<p> A Postfix MTA verifies a sender or recipient address by probing
|
|
the nearest
|
|
MTA for that address, without actually delivering mail. The nearest
|
|
MTA could be the Postfix MTA itself, or it could be a remote MTA
|
|
(SMTP
|
|
interruptus). Probe messages are like normal mail, except that
|
|
they are never delivered, deferred or bounced; probe messages are
|
|
always discarded. </p>
|
|
|
|
<blockquote>
|
|
|
|
<table border="0">
|
|
|
|
<tr>
|
|
|
|
<td rowspan="2" colspan="5" align="center" valign="middle">
|
|
</td>
|
|
|
|
<td rowspan="3" align="center" valign="bottom"> <tt> -> </tt>
|
|
</td>
|
|
|
|
<td rowspan="3" align="center" valign="middle"> probe<br>
|
|
message </td>
|
|
|
|
<td rowspan="3" align="center" valign="middle"> <tt> -> </tt>
|
|
</td>
|
|
|
|
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
|
|
Postfix<br> mail<br> queue </td>
|
|
|
|
</tr>
|
|
|
|
<tr> <td> </td> </tr>
|
|
|
|
<tr>
|
|
|
|
<td rowspan="3" align="center" valign="middle"> Internet </td>
|
|
|
|
<td rowspan="3" align="center" valign="middle"> <tt> -> </tt>
|
|
</td>
|
|
|
|
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
|
|
<a href="smtpd.8.html">Postfix<br> SMTP<br> server</a> </td>
|
|
|
|
<td rowspan="3" align="center" valign="middle"> <tt> <->
|
|
</tt> </td>
|
|
|
|
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
|
|
<a href="verify.8.html">Postfix<br> verify<br> server</a>
|
|
</td>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td rowspan="1" colspan="3"> </td>
|
|
|
|
<td rowspan="1" align="center" valign="middle"> <tt> |</tt><br>
|
|
<tt> v</tt> </td>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td rowspan="3" align="center" valign="top"> <tt> <- </tt>
|
|
</td>
|
|
|
|
<td rowspan="3" align="center" valign="middle"> probe<br>
|
|
status </td>
|
|
|
|
<td rowspan="3" align="center" valign="middle"> <tt> <- </tt>
|
|
</td>
|
|
|
|
<td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle">
|
|
Postfix<br> delivery<br> agents </td>
|
|
|
|
<td rowspan="3" align="left" valign="middle"> <tt>-></tt>
|
|
Local<br> <tt>-></tt> Remote</td>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td rowspan="3" colspan="4" align="center" valign="middle">
|
|
</td>
|
|
|
|
<td rowspan="3" align="center" valign="middle"> <tt>
|
|
^</tt><br> <tt> |</tt><br> <tt> v</tt> </td>
|
|
|
|
</tr>
|
|
|
|
<tr> <td> </td> </tr>
|
|
|
|
<tr> <td colspan="4"> </td> </tr>
|
|
|
|
<tr>
|
|
|
|
<td colspan="4" align="center" valign="middle"> </td>
|
|
|
|
<td bgcolor="#f0f0ff" align="center" valign="middle">
|
|
Address<br> verification<br> database </td>
|
|
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
</blockquote>
|
|
|
|
<p> With Postfix address verification turned on, normal mail will
|
|
suffer only a short delay of up to 6 seconds while an address is
|
|
being verified for the first time. Once an address status is known,
|
|
the status is cached and Postfix replies immediately. </p>
|
|
|
|
<p> When verification takes too long the Postfix SMTP server defers
|
|
the sender or recipient address with a 450 reply. Normal mail
|
|
clients will connect again after some delay. The address verification
|
|
delay is configurable with the <a href="postconf.5.html">main.cf</a> <a href="postconf.5.html#address_verify_poll_count">address_verify_poll_count</a>
|
|
and <a href="postconf.5.html#address_verify_poll_delay">address_verify_poll_delay</a> parameters. See <a href="postconf.5.html">postconf(5)</a> for
|
|
details. </p>
|
|
|
|
<h2><a name="limitations">Limitations of address verification</a></h2>
|
|
|
|
<ul>
|
|
|
|
<li> <p> When verifying a remote address, Postfix probes the nearest
|
|
MTA for that address, without actually delivering mail to it. If
|
|
the nearest MTA accepts the address, then Postfix assumes that the
|
|
address is deliverable. In reality, mail for a remote address can
|
|
bounce AFTER the nearest MTA accepts the recipient address, or AFTER
|
|
the nearest MTA accepts the message content. </p>
|
|
|
|
<li> <p> Some sites may blacklist you when you are probing them
|
|
too often (a probe is an SMTP session that does not deliver mail),
|
|
or when you are probing them too often for a non-existent address.
|
|
This is one reason why you should use sender address verification
|
|
sparingly, if at all, when your site receives lots of email. </p>
|
|
|
|
<li> <p> Normally, address verification probe messages follow the
|
|
same path as regular mail. However, some sites send mail to the
|
|
Internet via an intermediate <a href="postconf.5.html#relayhost">relayhost</a>; this breaks address
|
|
verification. See below, section <a href="#probe_routing">"Controlling
|
|
the routing of address verification probes"</a>, for how to override
|
|
mail routing and for possible limitations when you have to do this.
|
|
</p>
|
|
|
|
<li> <p> Postfix assumes that an address is undeliverable when the
|
|
nearest MTA for the address rejects the probe, regardless of the
|
|
reason for rejection (client rejected, HELO rejected, MAIL FROM
|
|
rejected, etc.). Thus, Postfix rejects an address when the nearest
|
|
MTA for that address rejects mail from your machine for any reason.
|
|
This is not a limitation, but it is mentioned here just in case
|
|
people believe that it is a limitation. </p>
|
|
|
|
<li> <p> Unfortunately, some sites do not reject
|
|
unknown addresses in reply to the RCPT TO command, but report a
|
|
delivery failure in response to end of DATA after a message is
|
|
transferred. Postfix address verification does not work with such
|
|
sites. </p>
|
|
|
|
<li> <p> By default, Postfix probe messages have a sender address
|
|
"double-bounce@$<a href="postconf.5.html#myorigin">myorigin</a>" (with Postfix versions before 2.5, the
|
|
default
|
|
is "postmaster@$<a href="postconf.5.html#myorigin">myorigin</a>"). This is SAFE because the Postfix SMTP
|
|
server does not reject mail for this address. </p>
|
|
|
|
<p> You can change the probe sender address into the null address
|
|
("<a href="postconf.5.html#address_verify_sender">address_verify_sender</a>
|
|
="). This is UNSAFE because address probes will fail with
|
|
mis-configured sites that reject MAIL FROM: <>, while
|
|
probes from "double-bounce@$<a href="postconf.5.html#myorigin">myorigin</a>" would succeed. </p>
|
|
|
|
</ul>
|
|
|
|
<h2><a name="recipient">Recipient address verification</a></h2>
|
|
|
|
<p> As mentioned earlier, recipient address verification is
|
|
useful to block mail for undeliverable recipients on a mail relay
|
|
host that does not have a list of all valid recipient addresses.
|
|
This can help to prevent the mail queue from filling up with
|
|
MAILER-DAEMON messages. </p>
|
|
|
|
<p> Recipient address verification is relatively straightforward
|
|
and there are no surprises. If a recipient probe fails, then Postfix
|
|
rejects mail for the recipient address. If a recipient probe
|
|
succeeds, then Postfix accepts mail for the recipient address.
|
|
However, recipient address verification probes can increase the
|
|
load on down-stream MTAs when you're being flooded by backscatter
|
|
bounces, or when some spammer is mounting a dictionary attack. </p>
|
|
|
|
<p> By default, address verification results are saved in a <a
|
|
href="#caching">persistent database</a> (Postfix version 2.7 and
|
|
later; with earlier versions, specify the database in <a href="postconf.5.html">main.cf</a> as
|
|
described later). The persistent database helps to avoid probing
|
|
the same address repeatedly. </p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
|
|
<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>
|
|
...
|
|
<a href="postconf.5.html#reject_unknown_recipient_domain">reject_unknown_recipient_domain</a>
|
|
<a href="postconf.5.html#reject_unverified_recipient">reject_unverified_recipient</a>
|
|
...
|
|
# Postfix 2.6 and later privacy feature.
|
|
# <a href="postconf.5.html#unverified_recipient_reject_reason">unverified_recipient_reject_reason</a> = Address lookup failed
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p> The "<a href="postconf.5.html#reject_unknown_recipient_domain">reject_unknown_recipient_domain</a>" restriction blocks mail
|
|
for non-existent domains. Putting this before "<a href="postconf.5.html#reject_unverified_recipient">reject_unverified_recipient</a>"
|
|
avoids the overhead of generating unnecessary probe messages. </p>
|
|
|
|
<p> The <a href="postconf.5.html#unverified_recipient_reject_code">unverified_recipient_reject_code</a> parameter (default 450)
|
|
specifies the numerical Postfix SMTP server reply code when a
|
|
recipient address is known to
|
|
bounce. Change this setting into 550 when you trust Postfix's
|
|
judgments. </p>
|
|
|
|
<p> The following features are available in Postfix 2.6 and later.
|
|
</p>
|
|
|
|
<p> The <a href="postconf.5.html#unverified_recipient_defer_code">unverified_recipient_defer_code</a> parameter (default 450)
|
|
specifies the numerical Postfix SMTP server reply code when a
|
|
recipient address probe fails with some temporary error. Some sites
|
|
insist on changing this into 250. NOTE: This change turns MX servers
|
|
into backscatter sources when the load is high. </p>
|
|
|
|
<p> The <a href="postconf.5.html#unverified_recipient_reject_reason">unverified_recipient_reject_reason</a> parameter (default:
|
|
empty) specifies fixed text that Postfix will send to remote SMTP
|
|
clients, instead of sending actual address verification details.
|
|
Do not specify the SMTP status code or enhanced status code. </p>
|
|
|
|
<p> The <a href="postconf.5.html#unverified_recipient_tempfail_action">unverified_recipient_tempfail_action</a> parameter (default:
|
|
<a href="postconf.5.html#defer_if_permit">defer_if_permit</a>) specifies the Postfix SMTP server action when a
|
|
recipient address verification probe fails with some temporary
|
|
error. </p>
|
|
|
|
<h2><a name="forged_sender">Sender address verification for mail from frequently forged domains</a></h2>
|
|
|
|
<p> Only for very small sites, it is relatively safe to turn on
|
|
sender address verification for specific domains that often appear
|
|
in forged email. </p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
|
|
<a href="postconf.5.html#smtpd_sender_restrictions">smtpd_sender_restrictions</a> = hash:/etc/postfix/sender_access
|
|
<a href="postconf.5.html#unverified_sender_reject_code">unverified_sender_reject_code</a> = 550
|
|
# Postfix 2.6 and later.
|
|
# <a href="postconf.5.html#unverified_sender_defer_code">unverified_sender_defer_code</a> = 250
|
|
|
|
# Default setting for Postfix 2.7 and later.
|
|
# Note 1: Be sure to read the "<a href="#caching">Caching</a>" section below!
|
|
# Note 2: Avoid hash files here. Use btree instead.
|
|
<a href="postconf.5.html#address_verify_map">address_verify_map</a> = btree:/var/db/postfix/verify
|
|
|
|
/etc/postfix/sender_access:
|
|
# Don't do this when you handle lots of email.
|
|
aol.com <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>
|
|
hotmail.com <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>
|
|
bigfoot.com <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>
|
|
... etcetera ...
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p> At some point in cyberspace/time, a list of frequently forged
|
|
MAIL FROM domains could be found at
|
|
<a href="http://www.monkeys.com/anti-spam/filtering/sender-domain-validate.in">http://www.monkeys.com/anti-spam/filtering/sender-domain-validate.in</a>. </p>
|
|
|
|
<p> NOTE: One of the first things you might want to do is to turn
|
|
on sender address verification for all your own domains. </p>
|
|
|
|
<h2><a name="sender_always">Sender address verification for all
|
|
email</a></h2>
|
|
|
|
<p> Unfortunately, sender address verification cannot simply be
|
|
turned on for all email - you are likely to lose legitimate mail
|
|
from mis-configured systems. You almost certainly will have to set
|
|
up white lists for specific addresses, or even for entire domains.
|
|
</p>
|
|
|
|
<p> To find out how sender address verification would affect your
|
|
mail, specify "<a href="postconf.5.html#warn_if_reject">warn_if_reject</a> <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>" so that
|
|
you can see what mail would be blocked: </p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
|
|
<a href="postconf.5.html#smtpd_sender_restrictions">smtpd_sender_restrictions</a> =
|
|
<a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>
|
|
...
|
|
<a href="postconf.5.html#check_sender_access">check_sender_access</a> hash:/etc/postfix/sender_access
|
|
<a href="postconf.5.html#reject_unknown_sender_domain">reject_unknown_sender_domain</a>
|
|
<a href="postconf.5.html#warn_if_reject">warn_if_reject</a> <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>
|
|
...
|
|
# Postfix 2.6 and later.
|
|
# <a href="postconf.5.html#unverified_sender_reject_reason">unverified_sender_reject_reason</a> = Address verification failed
|
|
|
|
# Default setting for Postfix 2.7 and later.
|
|
# Note 1: Be sure to read the "<a href="#caching">Caching</a>" section below!
|
|
# Note 2: Avoid hash files here. Use btree instead.
|
|
<a href="postconf.5.html#address_verify_map">address_verify_map</a> = btree:/var/db/postfix/verify
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p> This is also a good way to populate your cache with address
|
|
verification results before you start to actually reject mail. </p>
|
|
|
|
<p> The sender_access restriction is needed to whitelist domains
|
|
or addresses that are known to be OK. Although Postfix will not
|
|
mark a known-to-be-good address as bad after a probe fails, it is
|
|
better to be safe than sorry. </p>
|
|
|
|
<p> NOTE: You will have to whitelist sites such as securityfocus.com
|
|
and other sites that operate mailing lists that use a different
|
|
sender address for each posting (VERP). Such addresses pollute
|
|
the address verification cache quickly, and generate unnecessary
|
|
sender verification probes. </p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
/etc/postfix/sender_access
|
|
securityfocus.com OK
|
|
...
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p> The "<a href="postconf.5.html#reject_unknown_sender_domain">reject_unknown_sender_domain</a>" restriction blocks mail from
|
|
non-existent domains. Putting this before "<a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>"
|
|
avoids the overhead of generating unnecessary probe messages. </p>
|
|
|
|
<p> The <a href="postconf.5.html#unverified_sender_reject_code">unverified_sender_reject_code</a> parameter (default 450)
|
|
specifies the numerical Postfix server reply code when a sender
|
|
address is known to
|
|
bounce. Change this setting into 550 when you trust Postfix's
|
|
judgments. </p>
|
|
|
|
<p> The following features are available in Postfix 2.6 and later.
|
|
</p>
|
|
|
|
<p> The <a href="postconf.5.html#unverified_sender_defer_code">unverified_sender_defer_code</a> parameter (default 450) specifies
|
|
the numerical Postfix SMTP server reply code when a sender address
|
|
verification probe fails with some temporary error. Specify a valid
|
|
2xx or 4xx code. </p>
|
|
|
|
<p> The <a href="postconf.5.html#unverified_sender_reject_reason">unverified_sender_reject_reason</a> parameter (default:
|
|
empty) specifies fixed text that Postfix will send to remote SMTP
|
|
clients, instead of sending actual addres verification details.
|
|
Do not specify the SMTP status code or enhanced status code. </p>
|
|
|
|
<p> The <a href="postconf.5.html#unverified_sender_tempfail_action">unverified_sender_tempfail_action</a> parameter (default:
|
|
<a href="postconf.5.html#defer_if_permit">defer_if_permit</a>) specifies the Postfix SMTP server action when a
|
|
sender address verification probe fails with some temporary error.
|
|
</p>
|
|
|
|
<h2><a name="caching">Address verification database</a></h2>
|
|
|
|
<p> To improve performance, the Postfix <a href="verify.8.html">verify(8)</a> daemon can save
|
|
address verification results to a persistent database. This is
|
|
enabled by default with Postfix 2.7 and later. The
|
|
<a href="postconf.5.html#address_verify_map">address_verify_map</a> (NOTE: singular) configuration parameter specifies
|
|
persistent storage for sender or recipient address verification
|
|
results. If you specify an empty value, all address verification
|
|
results are lost after "postfix reload" or "postfix stop". </p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
|
|
# Default setting for Postfix 2.7 and later.
|
|
# Note: avoid hash files here. Use btree instead.
|
|
<a href="postconf.5.html#address_verify_map">address_verify_map</a> = btree:$<a href="postconf.5.html#data_directory">data_directory</a>/verify_cache
|
|
|
|
# Default setting for Postfix 2.6 and earlier.
|
|
# This uses non-persistent storage only.
|
|
<a href="postconf.5.html#address_verify_map">address_verify_map</a> =
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p> NOTE 1: The database file should be stored under a Postfix-owned
|
|
directory, such as $<a href="postconf.5.html#data_directory">data_directory</a>. </p>
|
|
|
|
<blockquote> As of version 2.5, Postfix no longer uses root privileges
|
|
when opening this file. To maintain backwards compatibility, an
|
|
attempt to open the file under a non-Postfix directory is redirected
|
|
to the Postfix-owned <a href="postconf.5.html#data_directory">data_directory</a>, and a warning is logged. If
|
|
you wish to continue using a pre-existing database file, change its
|
|
file ownership to the account specified with the <a href="postconf.5.html#mail_owner">mail_owner</a> parameter,
|
|
and either move the file to the <a href="postconf.5.html#data_directory">data_directory</a>, or move it to some
|
|
other Postfix-owned directory. </blockquote>
|
|
|
|
<p> NOTE 2: Do not put this file in a file system that may run out
|
|
of space. When the address verification table gets corrupted the
|
|
world comes to an end and YOU will have to MANUALLY fix things as
|
|
described in the next section. Meanwhile, you will not receive mail
|
|
via SMTP. </p>
|
|
|
|
<p> NOTE 3: The <a href="verify.8.html">verify(8)</a> daemon will create a new database when
|
|
none exists. It will open or create the file before entering the
|
|
chroot jail. </p>
|
|
|
|
<h2><a name="dirty_secret">Managing the address verification
|
|
database</a></h2>
|
|
|
|
<p> The <a href="verify.8.html">verify(8)</a> manual page describes parameters that control how
|
|
long address verification results are cached before they need to
|
|
be refreshed, and how long results can remain "unrefreshed" before
|
|
they expire. Postfix uses different controls for positive results
|
|
(address was accepted) and for negative results (address was rejected,
|
|
or address verification failed for some other reason). </p>
|
|
|
|
<p> The <a href="verify.8.html">verify(8)</a> daemon will periodically remove expired entries
|
|
from the address verification database, and log the number of entries
|
|
retained and dropped (Postfix versions 2.7 and later). A cleanup
|
|
run is logged as "partial" when the daemon terminates early because
|
|
of "postfix reload, "postfix stop", or because the daemon received
|
|
no requests for $<a href="postconf.5.html#max_idle">max_idle</a> seconds. Postfix versions 2.6 and earlier
|
|
do not implement automatic address verification database cleanup.
|
|
There, the database is managed manually as described next. </p>
|
|
|
|
<p> When the address verification database file becomes too big,
|
|
or when it becomes corrupted, the solution is to manually rename
|
|
or delete (NOT: truncate) the file and run "postfix reload". The
|
|
<a href="verify.8.html">verify(8)</a> daemon will then create a new database file. </p>
|
|
|
|
<h2><a name="probe_routing">Controlling the routing of address
|
|
verification probes</a></h2>
|
|
|
|
<p> By default, Postfix sends address verification probe messages
|
|
via the same route as regular mail, because that normally produces
|
|
the most accurate result. It's no good to verify a local address
|
|
by connecting to your own SMTP port; that just triggers all kinds
|
|
of mailer loop alarms. The same is true for any destination that
|
|
your machine is best MX host for: hidden domains, virtual domains,
|
|
etc. </p>
|
|
|
|
<p> However, some sites have a complex infrastructure where mail
|
|
is not sent directly to the Internet, but is instead given to an
|
|
intermediate <a href="postconf.5.html#relayhost">relayhost</a>. This is a problem for address verification,
|
|
because remote Internet addresses can be verified only when Postfix
|
|
can access remote destinations directly. </p>
|
|
|
|
<p> For this reason, Postfix allows you to override the routing
|
|
parameters when it delivers an address verification probe message.
|
|
</p>
|
|
|
|
<p> First, the <a href="postconf.5.html#address_verify_relayhost">address_verify_relayhost</a> parameter allows you to
|
|
override the <a href="postconf.5.html#relayhost">relayhost</a> setting, and the <a href="postconf.5.html#address_verify_transport_maps">address_verify_transport_maps</a>
|
|
parameter allows you to override the <a href="postconf.5.html#transport_maps">transport_maps</a> setting.
|
|
The <a href="postconf.5.html#address_verify_sender_dependent_relayhost_maps">address_verify_sender_dependent_relayhost_maps</a> parameter
|
|
does the same for sender-dependent <a href="postconf.5.html#relayhost">relayhost</a> selection. </p>
|
|
|
|
<p> Second, each address class is given its own address verification
|
|
version of the message delivery transport, as shown in the table
|
|
below. Address classes are defined in the <a href="ADDRESS_CLASS_README.html">ADDRESS_CLASS_README</a>
|
|
file. </p>
|
|
|
|
<blockquote>
|
|
|
|
<table border="1">
|
|
|
|
<tr> <th> Domain list </th> <th> Regular transport</th> <th> Verify
|
|
transport </th> </tr>
|
|
|
|
<tr> <td> <a href="postconf.5.html#mydestination">mydestination</a> </td> <td> <a href="postconf.5.html#local_transport">local_transport</a> </td> <td>
|
|
<a href="postconf.5.html#address_verify_local_transport">address_verify_local_transport</a> </td> </tr>
|
|
|
|
<tr> <td> <a href="postconf.5.html#virtual_alias_domains">virtual_alias_domains</a> </td> <td> (not applicable) </td>
|
|
<td> (not applicable) </td> </tr>
|
|
|
|
<tr> <td> <a href="postconf.5.html#virtual_mailbox_domains">virtual_mailbox_domains</a> </td> <td> <a href="postconf.5.html#virtual_transport">virtual_transport</a>
|
|
</td> <td> <a href="postconf.5.html#address_verify_virtual_transport">address_verify_virtual_transport</a> </td> </tr>
|
|
|
|
<tr> <td> <a href="postconf.5.html#relay_domains">relay_domains</a> </td> <td> <a href="postconf.5.html#relay_transport">relay_transport</a> </td> <td>
|
|
<a href="postconf.5.html#address_verify_relay_transport">address_verify_relay_transport</a> </td> </tr>
|
|
|
|
<tr> <td> (not applicable) </td> <td> <a href="postconf.5.html#default_transport">default_transport</a> </td> <td>
|
|
<a href="postconf.5.html#address_verify_default_transport">address_verify_default_transport</a> </td> </tr>
|
|
|
|
</table>
|
|
|
|
</blockquote>
|
|
|
|
<p> By default, the parameters that control delivery of address
|
|
probes have the same value as the parameters that control normal
|
|
mail delivery. </p>
|
|
|
|
<h2><a name="forced_examples">Forced probe routing examples</a></h2>
|
|
|
|
<p> In a typical scenario one would override the <a href="postconf.5.html#relayhost">relayhost</a> setting
|
|
for address verification probes and leave everything else alone:
|
|
</p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
|
|
<a href="postconf.5.html#relayhost">relayhost</a> = $<a href="postconf.5.html#mydomain">mydomain</a>
|
|
<a href="postconf.5.html#address_verify_relayhost">address_verify_relayhost</a> =
|
|
...
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<p> Sites behind a network address translation box might have to
|
|
use a different SMTP client that sends the correct hostname
|
|
information: </p>
|
|
|
|
<blockquote>
|
|
<pre>
|
|
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
|
|
<a href="postconf.5.html#relayhost">relayhost</a> = $<a href="postconf.5.html#mydomain">mydomain</a>
|
|
<a href="postconf.5.html#address_verify_relayhost">address_verify_relayhost</a> =
|
|
<a href="postconf.5.html#address_verify_default_transport">address_verify_default_transport</a> = direct_smtp
|
|
|
|
/etc/postfix/<a href="master.5.html">master.cf</a>:
|
|
direct_smtp .. .. .. .. .. .. .. .. .. smtp
|
|
-o <a href="postconf.5.html#smtp_helo_name">smtp_helo_name</a>=nat.box.tld
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<h2><a name="forced_limitations">Limitations of forced probe routing</a></h2>
|
|
|
|
<p> Inconsistencies can happen when probe messages don't follow
|
|
the same path as regular mail. For example, a message can be
|
|
accepted when it follows the regular route while an otherwise
|
|
identical probe message is rejected when it follows the forced
|
|
route. The opposite can happen, too, but is less likely. </p>
|
|
|
|
</body>
|
|
|
|
</html>
|