1<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" 2 "http://www.w3.org/TR/html4/loose.dtd"> 3 4<html> 5 6<head> 7 8<title>Postfix Address Verification </title> 9 10<meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> 11 12</head> 13 14<body> 15 16<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix Address Verification Howto</h1> 17 18<hr> 19 20<h2>WARNING </h2> 21 22<p> Recipient address verification may cause an increased load on 23down-stream servers in the case of a dictionary attack or a flood 24of backscatter bounces. Sender address verification may cause your 25site to be blacklisted by some providers. See also the "<a 26href="#limitations">Limitations</a>" section below for more. </p> 27 28<h2><a name="summary">What Postfix address verification can do for you</a></h2> 29 30<p> Address verification is a feature that allows the Postfix SMTP 31server to block a sender (MAIL FROM) or recipient (RCPT TO) address 32until the address has been verified to be deliverable. </p> 33 34<p> The technique has obvious uses to reject junk mail 35with an unreplyable sender address. </p> 36 37<p> The technique is also useful to block mail for undeliverable 38recipients, for example on a mail <a href="postconf.5.html#relayhost">relay host</a> that does not have a 39list of all the valid recipient addresses. This prevents undeliverable 40junk mail from entering the queue, so that Postfix doesn't have to 41waste resources trying to send MAILER-DAEMON messages back. </p> 42 43<p> This feature is available in Postfix version 2.1 and later. </p> 44 45<p> Topics covered in this document: </p> 46 47<ul> 48 49<li><a href="#how"> How address verification works</a> 50 51<li><a href="#limitations">Limitations of address verification</a> 52 53<li><a href="#recipient">Recipient address verification</a> 54 55<li><a href="#forged_sender">Sender address verification for mail 56from frequently forged domains</a> 57 58<li><a href="#sender_always">Sender address verification for all 59email</a> 60 61<li><a href="#caching">Address verification database</a> 62 63<li><a href="#dirty_secret">Managing the address verification 64database</a> 65 66<li><a href="#probe_routing">Controlling the routing of address 67verification probes</a> 68 69<li><a href="#forced_examples">Forced probe routing examples</a> 70 71<li><a href="#forced_limitations">Limitations of forced probe routing</a> 72 73</ul> 74 75<h2><a name="how">How address verification works</a></h2> 76 77<p> A Postfix MTA verifies a sender or recipient address by probing 78the nearest 79MTA for that address, without actually delivering mail. The nearest 80MTA could be the Postfix MTA itself, or it could be a remote MTA 81(SMTP 82interruptus). Probe messages are like normal mail, except that 83they are never delivered, deferred or bounced; probe messages are 84always discarded. </p> 85 86<blockquote> 87 88<table border="0"> 89 90<tr> 91 92 <td rowspan="2" colspan="5" align="center" valign="middle"> 93 </td> 94 95 <td rowspan="3" align="center" valign="bottom"> <tt> -> </tt> 96 </td> 97 98 <td rowspan="3" align="center" valign="middle"> probe<br> 99 message </td> 100 101 <td rowspan="3" align="center" valign="middle"> <tt> -> </tt> 102 </td> 103 104 <td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle"> 105 Postfix<br> mail<br> queue </td> 106 107</tr> 108 109<tr> <td> </td> </tr> 110 111<tr> 112 113 <td rowspan="3" align="center" valign="middle"> Internet </td> 114 115 <td rowspan="3" align="center" valign="middle"> <tt> -> </tt> 116 </td> 117 118 <td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle"> 119 <a href="smtpd.8.html">Postfix<br> SMTP<br> server</a> </td> 120 121 <td rowspan="3" align="center" valign="middle"> <tt> <-> 122 </tt> </td> 123 124 <td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle"> 125 <a href="verify.8.html">Postfix<br> verify<br> server</a> 126 </td> 127 128</tr> 129 130<tr> 131 132 <td rowspan="1" colspan="3"> </td> 133 134 <td rowspan="1" align="center" valign="middle"> <tt> |</tt><br> 135 <tt> v</tt> </td> 136 137</tr> 138 139<tr> 140 141 <td rowspan="3" align="center" valign="top"> <tt> <- </tt> 142 </td> 143 144 <td rowspan="3" align="center" valign="middle"> probe<br> 145 status </td> 146 147 <td rowspan="3" align="center" valign="middle"> <tt> <- </tt> 148 </td> 149 150 <td rowspan="3" bgcolor="#f0f0ff" align="center" valign="middle"> 151 Postfix<br> delivery<br> agents </td> 152 153 <td rowspan="3" align="left" valign="middle"> <tt>-></tt> 154 Local<br> <tt>-></tt> Remote</td> 155 156</tr> 157 158<tr> 159 160 <td rowspan="3" colspan="4" align="center" valign="middle"> 161 </td> 162 163 <td rowspan="3" align="center" valign="middle"> <tt> 164 ^</tt><br> <tt> |</tt><br> <tt> v</tt> </td> 165 166</tr> 167 168<tr> <td> </td> </tr> 169 170<tr> <td colspan="4"> </td> </tr> 171 172<tr> 173 174 <td colspan="4" align="center" valign="middle"> </td> 175 176 <td bgcolor="#f0f0ff" align="center" valign="middle"> 177 Address<br> verification<br> database </td> 178 179</tr> 180 181</table> 182 183</blockquote> 184 185<p> With Postfix address verification turned on, normal mail will 186suffer only a short delay of up to 6 seconds while an address is 187being verified for the first time. Once an address status is known, 188the status is cached and Postfix replies immediately. </p> 189 190<p> When verification takes too long the Postfix SMTP server defers 191the sender or recipient address with a 450 reply. Normal mail 192clients will connect again after some delay. The address verification 193delay 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> 194and <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 195details. </p> 196 197<h2><a name="limitations">Limitations of address verification</a></h2> 198 199<ul> 200 201<li> <p> When verifying a remote address, Postfix probes the nearest 202MTA for that address, without actually delivering mail to it. If 203the nearest MTA accepts the address, then Postfix assumes that the 204address is deliverable. In reality, mail for a remote address can 205bounce AFTER the nearest MTA accepts the recipient address, or AFTER 206the nearest MTA accepts the message content. </p> 207 208<li> <p> Some sites may blacklist you when you are probing them 209too often (a probe is an SMTP session that does not deliver mail), 210or when you are probing them too often for a non-existent address. 211This is one reason why you should use sender address verification 212sparingly, if at all, when your site receives lots of email. </p> 213 214<li> <p> Normally, address verification probe messages follow the 215same path as regular mail. However, some sites send mail to the 216Internet via an intermediate <a href="postconf.5.html#relayhost">relayhost</a>; this breaks address 217verification. See below, section <a href="#probe_routing">"Controlling 218the routing of address verification probes"</a>, for how to override 219mail routing and for possible limitations when you have to do this. 220</p> 221 222<li> <p> Postfix assumes that an address is undeliverable when the 223nearest MTA for the address rejects the probe, regardless of the 224reason for rejection (client rejected, HELO rejected, MAIL FROM 225rejected, etc.). Thus, Postfix rejects an address when the nearest 226MTA for that address rejects mail from your machine for any reason. 227This is not a limitation, but it is mentioned here just in case 228people believe that it is a limitation. </p> 229 230<li> <p> Unfortunately, some sites do not reject 231unknown addresses in reply to the RCPT TO command, but report a 232delivery failure in response to end of DATA after a message is 233transferred. Postfix address verification does not work with such 234sites. </p> 235 236<li> <p> By default, Postfix probe messages have a sender address 237"double-bounce@$<a href="postconf.5.html#myorigin">myorigin</a>" (with Postfix versions before 2.5, the 238default 239is "postmaster@$<a href="postconf.5.html#myorigin">myorigin</a>"). This is SAFE because the Postfix SMTP 240server does not reject mail for this address. </p> 241 242<p> You can change the probe sender address into the null address 243("<a href="postconf.5.html#address_verify_sender">address_verify_sender</a> 244="). This is UNSAFE because address probes will fail with 245mis-configured sites that reject MAIL FROM: <>, while 246probes from "double-bounce@$<a href="postconf.5.html#myorigin">myorigin</a>" would succeed. </p> 247 248<li> <p> The downside of using a non-empty sender address is that 249the address may end op on spammer mailing lists. Although Postfix 250always discards mail to the double-bounce address, this still results 251in wasted network bandwidth and server capacity. To defeat 252address harvesting, Postfix 2.9 and later support time-dependent 253sender addresses when you specify a non-zero <a href="postconf.5.html#address_verify_sender_ttl">address_verify_sender_ttl</a> 254value. </p> 255 256</ul> 257 258<h2><a name="recipient">Recipient address verification</a></h2> 259 260<p> As mentioned earlier, recipient address verification is 261useful to block mail for undeliverable recipients on a mail relay 262host that does not have a list of all valid recipient addresses. 263This can help to prevent the mail queue from filling up with 264MAILER-DAEMON messages. </p> 265 266<p> Recipient address verification is relatively straightforward 267and there are no surprises. If a recipient probe fails, then Postfix 268rejects mail for the recipient address. If a recipient probe 269succeeds, then Postfix accepts mail for the recipient address. 270However, recipient address verification probes can increase the 271load on down-stream MTAs when you're being flooded by backscatter 272bounces, or when some spammer is mounting a dictionary attack. </p> 273 274<p> By default, address verification results are saved in a <a 275href="#caching">persistent database</a> (Postfix version 2.7 and 276later; with earlier versions, specify the database in <a href="postconf.5.html">main.cf</a> as 277described later). The persistent database helps to avoid probing 278the same address repeatedly. </p> 279 280<blockquote> 281<pre> 282/etc/postfix/<a href="postconf.5.html">main.cf</a>: 283 <a href="postconf.5.html#smtpd_recipient_restrictions">smtpd_recipient_restrictions</a> = 284 <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a> 285 <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a> 286 ... 287 <a href="postconf.5.html#reject_unknown_recipient_domain">reject_unknown_recipient_domain</a> 288 <a href="postconf.5.html#reject_unverified_recipient">reject_unverified_recipient</a> 289 ... 290 # Postfix 2.6 and later privacy feature. 291 # <a href="postconf.5.html#unverified_recipient_reject_reason">unverified_recipient_reject_reason</a> = Address lookup failed 292</pre> 293</blockquote> 294 295<p> The "<a href="postconf.5.html#reject_unknown_recipient_domain">reject_unknown_recipient_domain</a>" restriction blocks mail 296for non-existent domains. Putting this before "<a href="postconf.5.html#reject_unverified_recipient">reject_unverified_recipient</a>" 297avoids the overhead of generating unnecessary probe messages. </p> 298 299<p> The <a href="postconf.5.html#unverified_recipient_reject_code">unverified_recipient_reject_code</a> parameter (default 450) 300specifies the numerical Postfix SMTP server reply code when a 301recipient address is known to 302bounce. Change this setting into 550 when you trust Postfix's 303judgments. </p> 304 305<p> The following features are available in Postfix 2.6 and later. 306</p> 307 308<p> The <a href="postconf.5.html#unverified_recipient_defer_code">unverified_recipient_defer_code</a> parameter (default 450) 309specifies the numerical Postfix SMTP server reply code when a 310recipient address probe fails with some temporary error. Some sites 311insist on changing this into 250. NOTE: This change turns MX servers 312into backscatter sources when the load is high. </p> 313 314<p> The <a href="postconf.5.html#unverified_recipient_reject_reason">unverified_recipient_reject_reason</a> parameter (default: 315empty) specifies fixed text that Postfix will send to remote SMTP 316clients, instead of sending actual address verification details. 317Do not specify the SMTP status code or enhanced status code. </p> 318 319<p> The <a href="postconf.5.html#unverified_recipient_tempfail_action">unverified_recipient_tempfail_action</a> parameter (default: 320<a href="postconf.5.html#defer_if_permit">defer_if_permit</a>) specifies the Postfix SMTP server action when a 321recipient address verification probe fails with some temporary 322error. </p> 323 324<h2><a name="forged_sender">Sender address verification for mail from frequently forged domains</a></h2> 325 326<p> Only for very small sites, it is relatively safe to turn on 327sender address verification for specific domains that often appear 328in forged email. </p> 329 330<blockquote> 331<pre> 332/etc/postfix/<a href="postconf.5.html">main.cf</a>: 333 <a href="postconf.5.html#smtpd_sender_restrictions">smtpd_sender_restrictions</a> = hash:/etc/postfix/sender_access 334 <a href="postconf.5.html#unverified_sender_reject_code">unverified_sender_reject_code</a> = 550 335 # Postfix 2.6 and later. 336 # <a href="postconf.5.html#unverified_sender_defer_code">unverified_sender_defer_code</a> = 250 337 338 # Default setting for Postfix 2.7 and later. 339 # Note 1: Be sure to read the "<a href="#caching">Caching</a>" section below! 340 # Note 2: Avoid hash files here. Use btree instead. 341 <a href="postconf.5.html#address_verify_map">address_verify_map</a> = btree:/var/lib/postfix/verify 342 343/etc/postfix/sender_access: 344 # Don't do this when you handle lots of email. 345 aol.com <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a> 346 hotmail.com <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a> 347 bigfoot.com <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a> 348 ... etcetera ... 349</pre> 350</blockquote> 351 352<p> At some point in cyberspace/time, a list of frequently forged 353MAIL FROM domains could be found at 354<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> 355 356<p> NOTE: One of the first things you might want to do is to turn 357on sender address verification for all your own domains. </p> 358 359<h2><a name="sender_always">Sender address verification for all 360email</a></h2> 361 362<p> Unfortunately, sender address verification cannot simply be 363turned on for all email - you are likely to lose legitimate mail 364from mis-configured systems. You almost certainly will have to set 365up white lists for specific addresses, or even for entire domains. 366</p> 367 368<p> To find out how sender address verification would affect your 369mail, 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 370you can see what mail would be blocked: </p> 371 372<blockquote> 373<pre> 374/etc/postfix/<a href="postconf.5.html">main.cf</a>: 375 <a href="postconf.5.html#smtpd_sender_restrictions">smtpd_sender_restrictions</a> = 376 <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a> 377 ... 378 <a href="postconf.5.html#check_sender_access">check_sender_access</a> hash:/etc/postfix/sender_access 379 <a href="postconf.5.html#reject_unknown_sender_domain">reject_unknown_sender_domain</a> 380 <a href="postconf.5.html#warn_if_reject">warn_if_reject</a> <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a> 381 ... 382 # Postfix 2.6 and later. 383 # <a href="postconf.5.html#unverified_sender_reject_reason">unverified_sender_reject_reason</a> = Address verification failed 384 385 # Default setting for Postfix 2.7 and later. 386 # Note 1: Be sure to read the "<a href="#caching">Caching</a>" section below! 387 # Note 2: Avoid hash files here. Use btree instead. 388 <a href="postconf.5.html#address_verify_map">address_verify_map</a> = btree:/var/lib/postfix/verify 389</pre> 390</blockquote> 391 392<p> This is also a good way to populate your cache with address 393verification results before you start to actually reject mail. </p> 394 395<p> The sender_access restriction is needed to whitelist domains 396or addresses that are known to be OK. Although Postfix will not 397mark a known-to-be-good address as bad after a probe fails, it is 398better to be safe than sorry. </p> 399 400<p> NOTE: You will have to whitelist sites such as securityfocus.com 401and other sites that operate mailing lists that use a different 402sender address for each posting (VERP). Such addresses pollute 403the address verification cache quickly, and generate unnecessary 404sender verification probes. </p> 405 406<blockquote> 407<pre> 408/etc/postfix/sender_access 409 securityfocus.com OK 410 ... 411</pre> 412</blockquote> 413 414<p> The "<a href="postconf.5.html#reject_unknown_sender_domain">reject_unknown_sender_domain</a>" restriction blocks mail from 415non-existent domains. Putting this before "<a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>" 416avoids the overhead of generating unnecessary probe messages. </p> 417 418<p> The <a href="postconf.5.html#unverified_sender_reject_code">unverified_sender_reject_code</a> parameter (default 450) 419specifies the numerical Postfix server reply code when a sender 420address is known to 421bounce. Change this setting into 550 when you trust Postfix's 422judgments. </p> 423 424<p> The following features are available in Postfix 2.6 and later. 425</p> 426 427<p> The <a href="postconf.5.html#unverified_sender_defer_code">unverified_sender_defer_code</a> parameter (default 450) specifies 428the numerical Postfix SMTP server reply code when a sender address 429verification probe fails with some temporary error. Specify a valid 4302xx or 4xx code. </p> 431 432<p> The <a href="postconf.5.html#unverified_sender_reject_reason">unverified_sender_reject_reason</a> parameter (default: 433empty) specifies fixed text that Postfix will send to remote SMTP 434clients, instead of sending actual addres verification details. 435Do not specify the SMTP status code or enhanced status code. </p> 436 437<p> The <a href="postconf.5.html#unverified_sender_tempfail_action">unverified_sender_tempfail_action</a> parameter (default: 438<a href="postconf.5.html#defer_if_permit">defer_if_permit</a>) specifies the Postfix SMTP server action when a 439sender address verification probe fails with some temporary error. 440</p> 441 442<h2><a name="caching">Address verification database</a></h2> 443 444<p> To improve performance, the Postfix <a href="verify.8.html">verify(8)</a> daemon can save 445address verification results to a persistent database. This is 446enabled by default with Postfix 2.7 and later. The 447<a href="postconf.5.html#address_verify_map">address_verify_map</a> (NOTE: singular) configuration parameter specifies 448persistent storage for sender or recipient address verification 449results. If you specify an empty value, all address verification 450results are lost after "postfix reload" or "postfix stop". </p> 451 452<blockquote> 453<pre> 454/etc/postfix/<a href="postconf.5.html">main.cf</a>: 455 # Default setting for Postfix 2.7 and later. 456 # Note: avoid hash files here. Use btree instead. 457 <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 458 459 # Shared persistent cache (requires Postfix 2.9 or later). 460 <a href="postconf.5.html#address_verify_map">address_verify_map</a> = <a href="proxymap.8.html">proxy</a>:btree:$<a href="postconf.5.html#data_directory">data_directory</a>/verify_cache 461 # Disable automatic cache cleanup in all Postfix instances except 462 # for one instance that will be responsible for cache cleanup. 463 # <a href="postconf.5.html#address_verify_cache_cleanup_interval">address_verify_cache_cleanup_interval</a> = 0 464 465 # Shared memory cache (requires Postfix 2.9 or later). 466 # See <a href="memcache_table.5.html">memcache_table(5)</a> for details. 467 <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 468 469 # Default setting for Postfix 2.6 and earlier. 470 # This uses non-persistent storage only. 471 <a href="postconf.5.html#address_verify_map">address_verify_map</a> = 472</pre> 473</blockquote> 474 475<p> NOTE 1: The database file should be stored under a Postfix-owned 476directory, such as $<a href="postconf.5.html#data_directory">data_directory</a>. </p> 477 478<blockquote> As of version 2.5, Postfix no longer uses root privileges 479when opening this file. To maintain backwards compatibility, an 480attempt to open the file under a non-Postfix directory is redirected 481to the Postfix-owned <a href="postconf.5.html#data_directory">data_directory</a>, and a warning is logged. If 482you wish to continue using a pre-existing database file, change its 483file ownership to the account specified with the <a href="postconf.5.html#mail_owner">mail_owner</a> parameter, 484and either move the file to the <a href="postconf.5.html#data_directory">data_directory</a>, or move it to some 485other Postfix-owned directory. </blockquote> 486 487<p> NOTE 2: Do not put this file in a file system that may run out 488of space. When the address verification table gets corrupted the 489world comes to an end and YOU will have to MANUALLY fix things as 490described in the next section. Meanwhile, you will not receive mail 491via SMTP. </p> 492 493<p> NOTE 3: The <a href="verify.8.html">verify(8)</a> daemon will create a new database when 494none exists. It will open or create the file before entering the 495chroot jail. </p> 496 497<h2><a name="dirty_secret">Managing the address verification 498database</a></h2> 499 500<p> The <a href="verify.8.html">verify(8)</a> manual page describes parameters that control how 501long address verification results are cached before they need to 502be refreshed, and how long results can remain "unrefreshed" before 503they expire. Postfix uses different controls for positive results 504(address was accepted) and for negative results (address was rejected, 505or address verification failed for some other reason). </p> 506 507<p> The <a href="verify.8.html">verify(8)</a> daemon will periodically remove expired entries 508from the address verification database, and log the number of entries 509retained and dropped (Postfix versions 2.7 and later). A cleanup 510run is logged as "partial" when the daemon terminates early because 511of "postfix reload, "postfix stop", or because the daemon received 512no requests for $<a href="postconf.5.html#max_idle">max_idle</a> seconds. Postfix versions 2.6 and earlier 513do not implement automatic address verification database cleanup. 514There, the database is managed manually as described next. </p> 515 516<p> When the address verification database file becomes too big, 517or when it becomes corrupted, the solution is to manually rename 518or delete (NOT: truncate) the file and run "postfix reload". The 519<a href="verify.8.html">verify(8)</a> daemon will then create a new database file. </p> 520 521<h2><a name="probe_routing">Controlling the routing of address 522verification probes</a></h2> 523 524<p> By default, Postfix sends address verification probe messages 525via the same route as regular mail, because that normally produces 526the most accurate result. It's no good to verify a local address 527by connecting to your own SMTP port; that just triggers all kinds 528of mailer loop alarms. The same is true for any destination that 529your machine is best MX host for: hidden domains, virtual domains, 530etc. </p> 531 532<p> However, some sites have a complex infrastructure where mail 533is not sent directly to the Internet, but is instead given to an 534intermediate <a href="postconf.5.html#relayhost">relayhost</a>. This is a problem for address verification, 535because remote Internet addresses can be verified only when Postfix 536can access remote destinations directly. </p> 537 538<p> For this reason, Postfix allows you to override the routing 539parameters when it delivers an address verification probe message. 540</p> 541 542<p> First, the <a href="postconf.5.html#address_verify_relayhost">address_verify_relayhost</a> parameter allows you to 543override 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> 544parameter allows you to override the <a href="postconf.5.html#transport_maps">transport_maps</a> setting. 545The <a href="postconf.5.html#address_verify_sender_dependent_relayhost_maps">address_verify_sender_dependent_relayhost_maps</a> parameter 546does the same for sender-dependent <a href="postconf.5.html#relayhost">relayhost</a> selection. </p> 547 548<p> Second, each address class is given its own address verification 549version of the message delivery transport, as shown in the table 550below. Address classes are defined in the <a href="ADDRESS_CLASS_README.html">ADDRESS_CLASS_README</a> 551file. </p> 552 553<blockquote> 554 555<table border="1"> 556 557<tr> <th> Domain list </th> <th> Regular transport</th> <th> Verify 558transport </th> </tr> 559 560<tr> <td> <a href="postconf.5.html#mydestination">mydestination</a> </td> <td> <a href="postconf.5.html#local_transport">local_transport</a> </td> <td> 561<a href="postconf.5.html#address_verify_local_transport">address_verify_local_transport</a> </td> </tr> 562 563<tr> <td> <a href="postconf.5.html#virtual_alias_domains">virtual_alias_domains</a> </td> <td> (not applicable) </td> 564<td> (not applicable) </td> </tr> 565 566<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> 567</td> <td> <a href="postconf.5.html#address_verify_virtual_transport">address_verify_virtual_transport</a> </td> </tr> 568 569<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> 570<a href="postconf.5.html#address_verify_relay_transport">address_verify_relay_transport</a> </td> </tr> 571 572<tr> <td> (not applicable) </td> <td> <a href="postconf.5.html#default_transport">default_transport</a> </td> <td> 573<a href="postconf.5.html#address_verify_default_transport">address_verify_default_transport</a> </td> </tr> 574 575</table> 576 577</blockquote> 578 579<p> By default, the parameters that control delivery of address 580probes have the same value as the parameters that control normal 581mail delivery. </p> 582 583<h2><a name="forced_examples">Forced probe routing examples</a></h2> 584 585<p> In a typical scenario one would override the <a href="postconf.5.html#relayhost">relayhost</a> setting 586for address verification probes and leave everything else alone: 587</p> 588 589<blockquote> 590<pre> 591/etc/postfix/<a href="postconf.5.html">main.cf</a>: 592 <a href="postconf.5.html#relayhost">relayhost</a> = $<a href="postconf.5.html#mydomain">mydomain</a> 593 <a href="postconf.5.html#address_verify_relayhost">address_verify_relayhost</a> = 594 ... 595</pre> 596</blockquote> 597 598<p> Sites behind a network address translation box might have to 599use a different SMTP client that sends the correct hostname 600information: </p> 601 602<blockquote> 603<pre> 604/etc/postfix/<a href="postconf.5.html">main.cf</a>: 605 <a href="postconf.5.html#relayhost">relayhost</a> = $<a href="postconf.5.html#mydomain">mydomain</a> 606 <a href="postconf.5.html#address_verify_relayhost">address_verify_relayhost</a> = 607 <a href="postconf.5.html#address_verify_default_transport">address_verify_default_transport</a> = direct_smtp 608 609/etc/postfix/<a href="master.5.html">master.cf</a>: 610 direct_smtp .. .. .. .. .. .. .. .. .. smtp 611 -o <a href="postconf.5.html#smtp_helo_name">smtp_helo_name</a>=nat.box.tld 612</pre> 613</blockquote> 614 615<h2><a name="forced_limitations">Limitations of forced probe routing</a></h2> 616 617<p> Inconsistencies can happen when probe messages don't follow 618the same path as regular mail. For example, a message can be 619accepted when it follows the regular route while an otherwise 620identical probe message is rejected when it follows the forced 621route. The opposite can happen, too, but is less likely. </p> 622 623</body> 624 625</html> 626