diff options
Diffstat (limited to '')
| -rw-r--r-- | html/ADDRESS_VERIFICATION_README.html | 658 |
1 files changed, 658 insertions, 0 deletions
diff --git a/html/ADDRESS_VERIFICATION_README.html b/html/ADDRESS_VERIFICATION_README.html new file mode 100644 index 0000000..3f429fe --- /dev/null +++ b/html/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=utf-8"> + +</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 denylisted 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 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"> + </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> 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 <a href="postconf.5.html#smtp_address_verify_target">smtp_address_verify_target</a> +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 denylist 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 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@$<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> + +<li> <p> The downside of using a non-empty sender address is that +the address may end up 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 <a href="postconf.5.html#address_verify_sender_ttl">address_verify_sender_ttl</a> +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 <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> 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_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 + + # Postfix 3.2 and earlier workaround. + # Do not set <a href="postconf.5.html#enable_original_recipient">enable_original_recipient</a>=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 "<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> = <a href="DATABASE_README.html#types">hash</a>:/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 or lmdb instead. + <a href="postconf.5.html#address_verify_map">address_verify_map</a> = <a href="DATABASE_README.html#types">btree</a>:/var/lib/postfix/verify + + # Postfix 3.2 and earlier workaround. + # Do not set <a href="postconf.5.html#enable_original_recipient">enable_original_recipient</a>=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 <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 allow 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> <a href="DATABASE_README.html#types">hash</a>:/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 or lmdb instead. + <a href="postconf.5.html#address_verify_map">address_verify_map</a> = <a href="DATABASE_README.html#types">btree</a>:/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 allowlist 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 allowlist 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 address 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> +# Example 1: Default setting for Postfix 2.7 and later. +# Note: avoid hash files here. Use btree or lmdb instead. +/etc/postfix/<a href="postconf.5.html">main.cf</a>: + <a href="postconf.5.html#address_verify_map">address_verify_map</a> = <a href="DATABASE_README.html#types">btree</a>:$<a href="postconf.5.html#data_directory">data_directory</a>/verify_cache + +# Example 2: Shared persistent <a href="lmdb_table.5.html">lmdb</a>: 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/<a href="postconf.5.html">main.cf</a>: + <a href="postconf.5.html#address_verify_map">address_verify_map</a> = <a href="lmdb_table.5.html">lmdb</a>:$<a href="postconf.5.html#data_directory">data_directory</a>/verify_cache + # <a href="postconf.5.html#address_verify_cache_cleanup_interval">address_verify_cache_cleanup_interval</a> = 0 + +# Example 3: Shared persistent <a href="DATABASE_README.html#types">btree</a>: 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/<a href="postconf.5.html">main.cf</a>: + <a href="postconf.5.html#address_verify_map">address_verify_map</a> = <a href="proxymap.8.html">proxy</a>:<a href="DATABASE_README.html#types">btree</a>:$<a href="postconf.5.html#data_directory">data_directory</a>/verify_cache + # <a href="postconf.5.html#address_verify_cache_cleanup_interval">address_verify_cache_cleanup_interval</a> = 0 + +# Example 4: Shared memory cache (requires Postfix 2.9 or later). +# Disable automatic cache cleanup in all Postfix instances. +# See <a href="memcache_table.5.html">memcache_table(5)</a> for details. +/etc/postfix/<a href="postconf.5.html">main.cf</a>: + <a href="postconf.5.html#address_verify_map">address_verify_map</a> = <a href="memcache_table.5.html">memcache</a>:/etc/postfix/verify-memcache.cf + <a href="postconf.5.html#address_verify_cache_cleanup_interval">address_verify_cache_cleanup_interval</a> = 0 + +# Example 5: Default setting for Postfix 2.6 and earlier. +# This uses non-persistent storage only. +/etc/postfix/<a href="postconf.5.html">main.cf</a>: + <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> |