summaryrefslogtreecommitdiffstats
path: root/proto/ADDRESS_VERIFICATION_README.html
diff options
context:
space:
mode:
Diffstat (limited to 'proto/ADDRESS_VERIFICATION_README.html')
-rw-r--r--proto/ADDRESS_VERIFICATION_README.html658
1 files changed, 658 insertions, 0 deletions
diff --git a/proto/ADDRESS_VERIFICATION_README.html b/proto/ADDRESS_VERIFICATION_README.html
new file mode 100644
index 0000000..ef1f6a7
--- /dev/null
+++ b/proto/ADDRESS_VERIFICATION_README.html
@@ -0,0 +1,658 @@
+<!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 relay host 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 preferred MTAs
+for that address, without actually delivering mail. The preferred
+MTAs could include the Postfix MTA itself, or some remote MTAs
+(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">
+ &nbsp; </td>
+
+ <td rowspan="3" align="center" valign="bottom"> <tt> -&gt; </tt>
+ </td>
+
+ <td rowspan="3" align="center" valign="middle"> probe<br>
+ message </td>
+
+ <td rowspan="3" align="center" valign="middle"> <tt> -&gt; </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> -&gt; </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> &lt;-&gt;
+ </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> &lt;- </tt>
+ </td>
+
+ <td rowspan="3" align="center" valign="middle"> probe<br>
+ status </td>
+
+ <td rowspan="3" align="center" valign="middle"> <tt> &lt;- </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>-&gt;</tt>
+ Local<br> <tt>-&gt;</tt> Remote</td>
+
+</tr>
+
+<tr>
+
+ <td rowspan="3" colspan="4" align="center" valign="middle">
+ &nbsp; </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"> &nbsp; </td> </tr>
+
+<tr>
+
+ <td colspan="4" align="center" valign="middle"> &nbsp; </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 main.cf address_verify_poll_count
+and address_verify_poll_delay parameters. See postconf(5) for
+details. </p>
+
+<h2><a name="limitations">Limitations of address verification</a></h2>
+
+<ul>
+
+<li> <p> Postfix assumes that a remote SMTP server will reject
+unknown addresses in reply to the RCPT TO command. However, some
+sites report this in reply to the DATA command. For such sites
+you may configure a workaround with the smtp_address_verify_target
+parameter (Postfix 3.0 and later). </p>
+
+<li> <p> When verifying a remote address, Postfix probes the preferred
+MTAs for that address, without actually delivering mail. If
+a preferred MTA accepts the address, then Postfix assumes that the
+address is deliverable. In reality, mail for a remote address can
+bounce AFTER a preferred MTA accepts the recipient address, or AFTER
+a preferred 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 relayhost; 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 a
+preferred 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 a preferred
+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 or DATA command, but instead 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@$myorigin" (with Postfix versions before 2.5, the
+default
+is "postmaster@$myorigin"). 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
+("address_verify_sender
+="). This is UNSAFE because address probes will fail with
+mis-configured sites that reject MAIL FROM: &lt;&gt;, while
+probes from "double-bounce@$myorigin" would succeed. </p>
+
+<li> <p> The downside of using a non-empty sender address is that
+the address may end op on spammer mailing lists. Although Postfix
+always discards mail to the double-bounce address, this still results
+in wasted network bandwidth and server capacity. To defeat
+address harvesting, Postfix 2.9 and later support time-dependent
+sender addresses when you specify a non-zero address_verify_sender_ttl
+value. </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 main.cf as
+described later). The persistent database helps to avoid probing
+the same address repeatedly. </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ smtpd_recipient_restrictions =
+ permit_mynetworks
+ # reject_unauth_destination is not needed here if the mail
+ # relay policy is specified under smtpd_relay_restrictions
+ # (available with Postfix 2.10 and later).
+ reject_unauth_destination
+ ...
+ reject_unknown_recipient_domain
+ reject_unverified_recipient
+ ...
+ # Postfix 2.6 and later privacy feature.
+ # unverified_recipient_reject_reason = Address lookup failed
+
+ # Postfix 3.2 and earlier workaround.
+ # Do not set enable_original_recipient=no. This prevents Postfix
+ # from saving the recipient address verification result under
+ # the original address, when the address verification probe
+ # message goes through address aliasing or canonical mapping.
+</pre>
+</blockquote>
+
+<p> The "reject_unknown_recipient_domain" restriction blocks mail
+for non-existent domains. Putting this before "reject_unverified_recipient"
+avoids the overhead of generating unnecessary probe messages. </p>
+
+<p> The unverified_recipient_reject_code 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 unverified_recipient_defer_code 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 unverified_recipient_reject_reason 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 unverified_recipient_tempfail_action parameter (default:
+defer_if_permit) 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/main.cf:
+ smtpd_sender_restrictions = hash:/etc/postfix/sender_access
+ unverified_sender_reject_code = 550
+ # Postfix 2.6 and later.
+ # unverified_sender_defer_code = 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 or lmdb instead.
+ address_verify_map = btree:/var/lib/postfix/verify
+
+ # Postfix 3.2 and earlier workaround.
+ # Do not set enable_original_recipient=no. This prevents Postfix
+ # from saving the sender address verification result under the
+ # original address, when the address verification probe message
+ # goes through address aliasing or canonical mapping.
+
+/etc/postfix/sender_access:
+ # Don't do this when you handle lots of email.
+ aol.com reject_unverified_sender
+ hotmail.com reject_unverified_sender
+ bigfoot.com reject_unverified_sender
+ ... etcetera ...
+</pre>
+</blockquote>
+
+<p> At some point in cyberspace/time, a list of frequently forged
+MAIL FROM domains could be found at
+http://www.monkeys.com/anti-spam/filtering/sender-domain-validate.in. </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 "warn_if_reject reject_unverified_sender" so that
+you can see what mail would be blocked: </p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ smtpd_sender_restrictions =
+ permit_mynetworks
+ ...
+ check_sender_access hash:/etc/postfix/sender_access
+ reject_unknown_sender_domain
+ warn_if_reject reject_unverified_sender
+ ...
+ # Postfix 2.6 and later.
+ # unverified_sender_reject_reason = 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 or lmdb instead.
+ address_verify_map = 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 "reject_unknown_sender_domain" restriction blocks mail from
+non-existent domains. Putting this before "reject_unverified_sender"
+avoids the overhead of generating unnecessary probe messages. </p>
+
+<p> The unverified_sender_reject_code 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 unverified_sender_defer_code 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 unverified_sender_reject_reason 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 unverified_sender_tempfail_action parameter (default:
+defer_if_permit) 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 verify(8) daemon can save
+address verification results to a persistent database. This is
+enabled by default with Postfix 2.7 and later. The
+address_verify_map (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>
+# Example 1: Default setting for Postfix 2.7 and later.
+# Note: avoid hash files here. Use btree or lmdb instead.
+/etc/postfix/main.cf:
+ address_verify_map = btree:$data_directory/verify_cache
+
+# Example 2: Shared persistent lmdb: cache (Postfix 2.11 or later).
+# Disable automatic cache cleanup in all Postfix instances except
+# for one instance that will be responsible for cache cleanup.
+/etc/postfix/main.cf:
+ address_verify_map = lmdb:$data_directory/verify_cache
+ # address_verify_cache_cleanup_interval = 0
+
+# Example 3: Shared persistent btree: cache (Postfix 2.9 or later).
+# Disable automatic cache cleanup in all Postfix instances except
+# for one instance that will be responsible for cache cleanup.
+/etc/postfix/main.cf:
+ address_verify_map = proxy:btree:$data_directory/verify_cache
+ # address_verify_cache_cleanup_interval = 0
+
+# Example 4: Shared memory cache (requires Postfix 2.9 or later).
+# Disable automatic cache cleanup in all Postfix instances.
+# See memcache_table(5) for details.
+/etc/postfix/main.cf:
+ address_verify_map = memcache:/etc/postfix/verify-memcache.cf
+ address_verify_cache_cleanup_interval = 0
+
+# Example 5: Default setting for Postfix 2.6 and earlier.
+# This uses non-persistent storage only.
+/etc/postfix/main.cf:
+ address_verify_map =
+</pre>
+</blockquote>
+
+<p> NOTE 1: The database file should be stored under a Postfix-owned
+directory, such as $data_directory. </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 data_directory, 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 mail_owner parameter,
+and either move the file to the data_directory, 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 verify(8) 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 verify(8) 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 verify(8) 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 $max_idle 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
+verify(8) 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 relayhost. 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 address_verify_relayhost parameter allows you to
+override the relayhost setting, and the address_verify_transport_maps
+parameter allows you to override the transport_maps setting.
+The address_verify_sender_dependent_relayhost_maps parameter
+does the same for sender-dependent relayhost 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 ADDRESS_CLASS_README
+file. </p>
+
+<blockquote>
+
+<table border="1">
+
+<tr> <th> Domain list </th> <th> Regular transport</th> <th> Verify
+transport </th> </tr>
+
+<tr> <td> mydestination </td> <td> local_transport </td> <td>
+address_verify_local_transport </td> </tr>
+
+<tr> <td> virtual_alias_domains </td> <td> (not applicable) </td>
+<td> (not applicable) </td> </tr>
+
+<tr> <td> virtual_mailbox_domains </td> <td> virtual_transport
+</td> <td> address_verify_virtual_transport </td> </tr>
+
+<tr> <td> relay_domains </td> <td> relay_transport </td> <td>
+address_verify_relay_transport </td> </tr>
+
+<tr> <td> (not applicable) </td> <td> default_transport </td> <td>
+address_verify_default_transport </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 relayhost setting
+for address verification probes and leave everything else alone:
+</p>
+
+<blockquote>
+<pre>
+/etc/postfix/main.cf:
+ relayhost = $mydomain
+ address_verify_relayhost =
+ ...
+</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/main.cf:
+ relayhost = $mydomain
+ address_verify_relayhost =
+ address_verify_default_transport = direct_smtp
+
+/etc/postfix/master.cf:
+ direct_smtp .. .. .. .. .. .. .. .. .. smtp
+ -o smtp_helo_name=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>