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