ADDRESS_VERIFICATION_README.html [plain text]
<!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> The sender/recipient address verification feature described in this
document is suitable only for low-traffic sites. It performs poorly
under high load; excessive sender address verification activity may
even cause your site to be blacklisted by some
providers. See the "<a href="#limitations">Limitations</a>" section
below for details. </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 may also be 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 sender or recipient address is verified by probing the nearest
MTA for that address, without actually delivering mail. The nearest
MTA could be Postfix 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>
<tr>
<td bgcolor="#f0f0ff" align="center" valign="middle"> Internet
</td>
<td align="center" valign="middle"> <tt> -> </tt> </td>
<td bgcolor="#f0f0ff" align="center" valign="middle"> <a
href="smtpd.8.html">Postfix<br> SMTP<br> server</a> </td>
<td colspan="2" align="center" valign="middle"> <tt> <->
</tt> </td>
<td bgcolor="#f0f0ff" colspan="3" align="center" valign="middle">
<a href="verify.8.html">Postfix<br> verify<br> server</a>
</td>
<td colspan="2" align="center" valign="middle"> <tt> <->
</tt> </td>
<td bgcolor="#f0f0ff" align="center" valign="middle"> Address<br>
verification<br> database </td>
</tr>
<tr>
<td colspan="3"> </td>
<td> </td>
<td colspan="2" align="right" valign="middle"> <tt> |</tt><br>
probe<br> messages<br> <tt> v </tt> </td>
<td> </td>
<td colspan="2" align="left" valign="middle"> ^<br> delivery<br>
status<br> <tt> | </tt> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td colspan="2" bgcolor="#f0f0ff" align="center" valign="middle">
Postfix<br> queue </td>
<td align="center" valign="middle"> <tt> -> </tt> </td>
<td colspan="2" bgcolor="#f0f0ff" align="center" valign="middle">
Postfix<br> delivery<br> agents </td>
<td> </td>
<td> </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. </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 mail when the sender's MTA
rejects mail from your machine. This is a good thing. </p>
<li> <p> Unfortunately, some major sites such as YAHOO 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 "double-bounce@$<a href="postconf.5.html#myorigin">myorigin</a>"
as the sender address (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 this 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 "postmaster@$<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 may be
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 not saved. To avoid
probing the same address repeatedly, you can store the result in a
<a href="#caching">persistent database</a> as described later. </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>
...
</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 how Postfix replies when a recipient address is known to
bounce. Change this setting into 550 when you trust Postfix's
judgments. </p>
<h2><a name="forged_sender">Sender address verification for mail from frequently forged domains</a></h2>
<p> 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
# 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/lib/postfix/verify
/etc/postfix/sender_access:
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>
...
# 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/lib/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 how Postfix replies when a sender address is known to
bounce. Change this setting into 550 when you trust Postfix's
judgments. </p>
<h2><a name="caching">Address verification database</a></h2>
<p> NOTE: By default, address verification information is not stored
in a persistent file. You have to specify one in <a href="postconf.5.html">main.cf</a> (see
below). Persistent storage is off by default because it may need
more disk space than is available in your file system. </p>
<p> Address verification information is cached by the Postfix verify
daemon. Postfix has a bunch of parameters that control the caching
of positive and negative results. Refer to the <a href="verify.8.html">verify(8)</a> manual
page for details. </p>
<p> The <a href="postconf.5.html#address_verify_map">address_verify_map</a> (NOTE: singular) configuration parameter
specifies an optional database for sender or recipient address
verification results. If you don't specify a file, all address
verification information is lost after "postfix reload" or "postfix
stop". </p>
<p> If your /var file system has sufficient space, try: </p>
<blockquote>
<pre>
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
# Note: avoid hash files here. Use btree instead.
<a href="postconf.5.html#address_verify_map">address_verify_map</a> = btree:/var/lib/postfix/verify
</pre>
</blockquote>
<p> NOTE 1: As of version 2.5, Postfix no longer uses root privileges
when opening this file. The file should now be stored under the
Postfix-owned <a href="postconf.5.html#data_directory">data_directory</a>. As a migration aid, 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, move it to the
<a href="postconf.5.html#data_directory">data_directory</a>, and change ownership to the account specified with
the <a href="postconf.5.html#mail_owner">mail_owner</a> parameter. </p>
<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 process will create a new database when
none exists, and will open/create the file before it enters 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 information remains cached before it needs to be refreshed,
and how long information can remain "unrefreshed" before it expires.
Postfix uses different controls for positive results (address was
accepted) and for negative results (address was rejected). </p>
<p> Right now, no tools are provided to manage the address verification
database. If the file gets too big, or if it gets corrupted, you
can manually rename or delete the file and run "postfix reload".
The new verify daemon process will then create a new database. </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>