ADDRESS_VERIFICATION_README.html revision 1.4
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 relay host 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 main.cf address_verify_poll_count 194and address_verify_poll_delay parameters. See postconf(5) 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 relayhost; 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@$myorigin" (with Postfix versions before 2.5, the 238default 239is "postmaster@$myorigin"). 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("address_verify_sender 244="). This is UNSAFE because address probes will fail with 245mis-configured sites that reject MAIL FROM: <>, while 246probes from "double-bounce@$myorigin" 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 253useful to block mail for undeliverable recipients on a mail relay 254host that does not have a list of all valid recipient addresses. 255This can help to prevent the mail queue from filling up with 256MAILER-DAEMON messages. </p> 257 258<p> Recipient address verification is relatively straightforward 259and there are no surprises. If a recipient probe fails, then Postfix 260rejects mail for the recipient address. If a recipient probe 261succeeds, then Postfix accepts mail for the recipient address. 262However, recipient address verification probes can increase the 263load on down-stream MTAs when you're being flooded by backscatter 264bounces, or when some spammer is mounting a dictionary attack. </p> 265 266<p> By default, address verification results are saved in a <a 267href="#caching">persistent database</a> (Postfix version 2.7 and 268later; with earlier versions, specify the database in main.cf as 269described later). The persistent database helps to avoid probing 270the same address repeatedly. </p> 271 272<blockquote> 273<pre> 274/etc/postfix/main.cf: 275 smtpd_recipient_restrictions = 276 permit_mynetworks 277 reject_unauth_destination 278 ... 279 reject_unknown_recipient_domain 280 reject_unverified_recipient 281 ... 282 # Postfix 2.6 and later privacy feature. 283 # unverified_recipient_reject_reason = Address lookup failed 284</pre> 285</blockquote> 286 287<p> The "reject_unknown_recipient_domain" restriction blocks mail 288for non-existent domains. Putting this before "reject_unverified_recipient" 289avoids the overhead of generating unnecessary probe messages. </p> 290 291<p> The unverified_recipient_reject_code parameter (default 450) 292specifies the numerical Postfix SMTP server reply code when a 293recipient address is known to 294bounce. Change this setting into 550 when you trust Postfix's 295judgments. </p> 296 297<p> The following features are available in Postfix 2.6 and later. 298</p> 299 300<p> The unverified_recipient_defer_code parameter (default 450) 301specifies the numerical Postfix SMTP server reply code when a 302recipient address probe fails with some temporary error. Some sites 303insist on changing this into 250. NOTE: This change turns MX servers 304into backscatter sources when the load is high. </p> 305 306<p> The unverified_recipient_reject_reason parameter (default: 307empty) specifies fixed text that Postfix will send to remote SMTP 308clients, instead of sending actual address verification details. 309Do not specify the SMTP status code or enhanced status code. </p> 310 311<p> The unverified_recipient_tempfail_action parameter (default: 312defer_if_permit) specifies the Postfix SMTP server action when a 313recipient address verification probe fails with some temporary 314error. </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 319sender address verification for specific domains that often appear 320in forged email. </p> 321 322<blockquote> 323<pre> 324/etc/postfix/main.cf: 325 smtpd_sender_restrictions = hash:/etc/postfix/sender_access 326 unverified_sender_reject_code = 550 327 # Postfix 2.6 and later. 328 # unverified_sender_defer_code = 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 address_verify_map = btree:/var/db/postfix/verify 334 335/etc/postfix/sender_access: 336 # Don't do this when you handle lots of email. 337 aol.com reject_unverified_sender 338 hotmail.com reject_unverified_sender 339 bigfoot.com reject_unverified_sender 340 ... etcetera ... 341</pre> 342</blockquote> 343 344<p> At some point in cyberspace/time, a list of frequently forged 345MAIL FROM domains could be found at 346http://www.monkeys.com/anti-spam/filtering/sender-domain-validate.in. </p> 347 348<p> NOTE: One of the first things you might want to do is to turn 349on sender address verification for all your own domains. </p> 350 351<h2><a name="sender_always">Sender address verification for all 352email</a></h2> 353 354<p> Unfortunately, sender address verification cannot simply be 355turned on for all email - you are likely to lose legitimate mail 356from mis-configured systems. You almost certainly will have to set 357up 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 361mail, specify "warn_if_reject reject_unverified_sender" so that 362you can see what mail would be blocked: </p> 363 364<blockquote> 365<pre> 366/etc/postfix/main.cf: 367 smtpd_sender_restrictions = 368 permit_mynetworks 369 ... 370 check_sender_access hash:/etc/postfix/sender_access 371 reject_unknown_sender_domain 372 warn_if_reject reject_unverified_sender 373 ... 374 # Postfix 2.6 and later. 375 # unverified_sender_reject_reason = 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 address_verify_map = btree:/var/db/postfix/verify 381</pre> 382</blockquote> 383 384<p> This is also a good way to populate your cache with address 385verification results before you start to actually reject mail. </p> 386 387<p> The sender_access restriction is needed to whitelist domains 388or addresses that are known to be OK. Although Postfix will not 389mark a known-to-be-good address as bad after a probe fails, it is 390better to be safe than sorry. </p> 391 392<p> NOTE: You will have to whitelist sites such as securityfocus.com 393and other sites that operate mailing lists that use a different 394sender address for each posting (VERP). Such addresses pollute 395the address verification cache quickly, and generate unnecessary 396sender 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 "reject_unknown_sender_domain" restriction blocks mail from 407non-existent domains. Putting this before "reject_unverified_sender" 408avoids the overhead of generating unnecessary probe messages. </p> 409 410<p> The unverified_sender_reject_code parameter (default 450) 411specifies the numerical Postfix server reply code when a sender 412address is known to 413bounce. Change this setting into 550 when you trust Postfix's 414judgments. </p> 415 416<p> The following features are available in Postfix 2.6 and later. 417</p> 418 419<p> The unverified_sender_defer_code parameter (default 450) specifies 420the numerical Postfix SMTP server reply code when a sender address 421verification probe fails with some temporary error. Specify a valid 4222xx or 4xx code. </p> 423 424<p> The unverified_sender_reject_reason parameter (default: 425empty) specifies fixed text that Postfix will send to remote SMTP 426clients, instead of sending actual addres verification details. 427Do not specify the SMTP status code or enhanced status code. </p> 428 429<p> The unverified_sender_tempfail_action parameter (default: 430defer_if_permit) specifies the Postfix SMTP server action when a 431sender 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 verify(8) daemon can save 437address verification results to a persistent database. This is 438enabled by default with Postfix 2.7 and later. The 439address_verify_map (NOTE: singular) configuration parameter specifies 440persistent storage for sender or recipient address verification 441results. If you specify an empty value, all address verification 442results are lost after "postfix reload" or "postfix stop". </p> 443 444<blockquote> 445<pre> 446/etc/postfix/main.cf: 447 # Default setting for Postfix 2.7 and later. 448 # Note: avoid hash files here. Use btree instead. 449 address_verify_map = btree:$data_directory/verify_cache 450 451 # Default setting for Postfix 2.6 and earlier. 452 # This uses non-persistent storage only. 453 address_verify_map = 454</pre> 455</blockquote> 456 457<p> NOTE 1: The database file should be stored under a Postfix-owned 458directory, such as $data_directory. </p> 459 460<blockquote> As of version 2.5, Postfix no longer uses root privileges 461when opening this file. To maintain backwards compatibility, an 462attempt to open the file under a non-Postfix directory is redirected 463to the Postfix-owned data_directory, and a warning is logged. If 464you wish to continue using a pre-existing database file, change its 465file ownership to the account specified with the mail_owner parameter, 466and either move the file to the data_directory, or move it to some 467other Postfix-owned directory. </blockquote> 468 469<p> NOTE 2: Do not put this file in a file system that may run out 470of space. When the address verification table gets corrupted the 471world comes to an end and YOU will have to MANUALLY fix things as 472described in the next section. Meanwhile, you will not receive mail 473via SMTP. </p> 474 475<p> NOTE 3: The verify(8) daemon will create a new database when 476none exists. It will open or create the file before entering the 477chroot jail. </p> 478 479<h2><a name="dirty_secret">Managing the address verification 480database</a></h2> 481 482<p> The verify(8) manual page describes parameters that control how 483long address verification results are cached before they need to 484be refreshed, and how long results can remain "unrefreshed" before 485they expire. Postfix uses different controls for positive results 486(address was accepted) and for negative results (address was rejected, 487or address verification failed for some other reason). </p> 488 489<p> The verify(8) daemon will periodically remove expired entries 490from the address verification database, and log the number of entries 491retained and dropped (Postfix versions 2.7 and later). A cleanup 492run is logged as "partial" when the daemon terminates early because 493of "postfix reload, "postfix stop", or because the daemon received 494no requests for $max_idle seconds. Postfix versions 2.6 and earlier 495do not implement automatic address verification database cleanup. 496There, the database is managed manually as described next. </p> 497 498<p> When the address verification database file becomes too big, 499or when it becomes corrupted, the solution is to manually rename 500or delete (NOT: truncate) the file and run "postfix reload". The 501verify(8) daemon will then create a new database file. </p> 502 503<h2><a name="probe_routing">Controlling the routing of address 504verification probes</a></h2> 505 506<p> By default, Postfix sends address verification probe messages 507via the same route as regular mail, because that normally produces 508the most accurate result. It's no good to verify a local address 509by connecting to your own SMTP port; that just triggers all kinds 510of mailer loop alarms. The same is true for any destination that 511your machine is best MX host for: hidden domains, virtual domains, 512etc. </p> 513 514<p> However, some sites have a complex infrastructure where mail 515is not sent directly to the Internet, but is instead given to an 516intermediate relayhost. This is a problem for address verification, 517because remote Internet addresses can be verified only when Postfix 518can access remote destinations directly. </p> 519 520<p> For this reason, Postfix allows you to override the routing 521parameters when it delivers an address verification probe message. 522</p> 523 524<p> First, the address_verify_relayhost parameter allows you to 525override the relayhost setting, and the address_verify_transport_maps 526parameter allows you to override the transport_maps setting. 527The address_verify_sender_dependent_relayhost_maps parameter 528does the same for sender-dependent relayhost selection. </p> 529 530<p> Second, each address class is given its own address verification 531version of the message delivery transport, as shown in the table 532below. Address classes are defined in the ADDRESS_CLASS_README 533file. </p> 534 535<blockquote> 536 537<table border="1"> 538 539<tr> <th> Domain list </th> <th> Regular transport</th> <th> Verify 540transport </th> </tr> 541 542<tr> <td> mydestination </td> <td> local_transport </td> <td> 543address_verify_local_transport </td> </tr> 544 545<tr> <td> virtual_alias_domains </td> <td> (not applicable) </td> 546<td> (not applicable) </td> </tr> 547 548<tr> <td> virtual_mailbox_domains </td> <td> virtual_transport 549</td> <td> address_verify_virtual_transport </td> </tr> 550 551<tr> <td> relay_domains </td> <td> relay_transport </td> <td> 552address_verify_relay_transport </td> </tr> 553 554<tr> <td> (not applicable) </td> <td> default_transport </td> <td> 555address_verify_default_transport </td> </tr> 556 557</table> 558 559</blockquote> 560 561<p> By default, the parameters that control delivery of address 562probes have the same value as the parameters that control normal 563mail 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 relayhost setting 568for address verification probes and leave everything else alone: 569</p> 570 571<blockquote> 572<pre> 573/etc/postfix/main.cf: 574 relayhost = $mydomain 575 address_verify_relayhost = 576 ... 577</pre> 578</blockquote> 579 580<p> Sites behind a network address translation box might have to 581use a different SMTP client that sends the correct hostname 582information: </p> 583 584<blockquote> 585<pre> 586/etc/postfix/main.cf: 587 relayhost = $mydomain 588 address_verify_relayhost = 589 address_verify_default_transport = direct_smtp 590 591/etc/postfix/master.cf: 592 direct_smtp .. .. .. .. .. .. .. .. .. smtp 593 -o smtp_helo_name=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 600the same path as regular mail. For example, a message can be 601accepted when it follows the regular route while an otherwise 602identical probe message is rejected when it follows the forced 603route. The opposite can happen, too, but is less likely. </p> 604 605</body> 606 607</html> 608