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