postfix-master/ADDRESS_VERIFICATION_README.html

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