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