1
PPoossttffiixx AAddddrreessss VVeerriiffiiccaattiioonn HHoowwttoo
3
-------------------------------------------------------------------------------
5
WWAARRNNIINNGG WWAARRNNIINNGG WWAARRNNIINNGG
7
The sender/recipient address verification feature described in this document is
8
suitable only for low-traffic sites. It performs poorly under high load and may
9
cause your site to be blacklisted by some providers. See the "Limitations"
10
section below for details.
12
WWhhaatt PPoossttffiixx aaddddrreessss vveerriiffiiccaattiioonn ccaann ddoo ffoorr yyoouu
14
Address verification is a feature that allows the Postfix SMTP server to block
15
a sender (MAIL FROM) or recipient (RCPT TO) address until the address has been
16
verified to be deliverable.
18
The technique has obvious uses in order to reject junk mail with an unreplyable
21
The technique may also be useful to block mail for undeliverable recipients,
22
for example on a mail relay host that does not have a list of all the valid
23
recipient addresses. This prevents undeliverable junk mail from entering the
24
queue, so that Postfix doesn't have to waste resources trying to send MAILER-
27
This feature is available in Postfix version 2.1 and later.
29
Topics covered in this document:
31
* How address verification works
32
* Limitations of address verification
33
* Recipient address verification
34
* Sender address verification for mail from frequently forged domains
35
* Sender address verification for all email
36
* Address verification database
37
* Managing the address verification database
38
* Controlling the routing of address verification probes
39
* Forced probe routing examples
40
* Limitations of forced probe routing
42
HHooww aaddddrreessss vveerriiffiiccaattiioonn wwoorrkkss
44
A sender or recipient address is verified by probing the nearest MTA for that
45
address, without actually delivering mail. The nearest MTA could be Postfix
46
itself, or it could be a remote MTA (SMTP interruptus). Probe messages are like
47
normal mail, except that they are never delivered, deferred or bounced; probe
48
messages are always discarded.
50
Postfix Postfix Address
51
Internet -> SMTP <-> verify <-> verification
52
server server database
63
With Postfix address verification turned on, normal mail will suffer only a
64
short delay of up to 6 seconds while an address is being verified for the first
65
time. Once an address status is known, the status is cached and Postfix replies
68
When verification takes too long the Postfix SMTP server defers the sender or
69
recipient address with a 450 reply. Normal mail clients will connect again
70
after some delay. The address verification delay is configurable with the
71
main.cf address_verify_poll_count and address_verify_poll_delay parameters. See
72
postconf(5) for details.
74
LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffiiccaattiioonn
76
* Postfix probes the nearest MTA for the address that is being verified,
77
without actually sending mail to that address. If the nearest MTA accepts
78
the address, then Postfix assumes that the address is deliverable, even
79
when the address will bounce AFTER that MTA accepts it.
81
* Sites like AOL may blacklist you when you are probing them too often (a
82
probe is an SMTP session that does not deliver mail), or when you are
83
probing them too often for a non-existent address.
85
* Normally, address verification probe messages follow the same path as
86
regular mail. However, some sites send mail to the Internet via an
87
intermediate relayhost; this breaks address verification. See below,
88
section "Controlling the routing of address verification probes", for how
89
to override mail routing and for possible limitations when you have to do
92
* Postfix assumes that an address is undeliverable when the nearest MTA for
93
the address rejects the probe, regardless of the reason for rejection
94
(client rejected, HELO rejected, MAIL FROM rejected, etc.). Thus, Postfix
95
rejects mail when the sender's MTA rejects mail from your machine. This is
98
* Unfortunately, some major sites such as YAHOO do not reject unknown
99
addresses in reply to the RCPT TO command, but report a delivery failure in
100
response to end of DATA after a message is transferred. Postfix address
101
verification does not work with such sites.
103
* By default, Postfix probe messages have "postmaster@$myorigin" as the
104
sender address. This is SAFE because the Postfix SMTP server does not
105
reject mail for this address.
107
You can change this into the null address ("address_verify_sender ="). This
108
is UNSAFE because address probes will fail with mis-configured sites that
109
reject MAIL FROM: <>, while probes from "postmaster@$myorigin" would
112
RReecciippiieenntt aaddddrreessss vveerriiffiiccaattiioonn
114
As mentioned earlier, recipient address verification may be useful to block
115
mail for undeliverable recipients on a mail relay host that does not have a
116
list of all valid recipient addresses. This can help to prevent the mail queue
117
from filling up with MAILER-DAEMON messages.
119
Recipient address verification is relatively straightforward and there are no
120
surprises. If a recipient probe fails, then Postfix rejects mail for the
121
recipient address. If a recipient probe succeeds, then Postfix accepts mail for
122
the recipient address.
124
/etc/postfix/main.cf:
125
smtpd_recipient_restrictions =
127
reject_unauth_destination
129
reject_unknown_recipient_domain
130
reject_unverified_recipient
133
The "reject_unknown_recipient_domain" restriction blocks mail for non-existent
134
domains. Putting this before "reject_unverified_recipient" avoids the overhead
135
of generating unnecessary probe messages.
137
The unverified_recipient_reject_code parameter (default 450) specifies how
138
Postfix replies when a recipient address is known to bounce. Change this
139
setting into 550 when you trust Postfix's judgments.
141
SSeennddeerr aaddddrreessss vveerriiffiiccaattiioonn ffoorr mmaaiill ffrroomm ffrreeqquueennttllyy ffoorrggeedd ddoommaaiinnss
143
It is relatively safe to turn on sender address verification for specific
144
domains that often appear in forged email.
146
/etc/postfix/main.cf:
147
smtpd_sender_restrictions = hash:/etc/postfix/sender_access
148
unverified_sender_reject_code = 550
149
# Note 1: Be sure to read the "Caching" section below!
150
# Note 2: Avoid hash files here. Use btree instead.
151
address_verify_map = btree:/var/mta/verify
153
/etc/postfix/sender_access:
154
aol.com reject_unverified_sender
155
hotmail.com reject_unverified_sender
156
bigfoot.com reject_unverified_sender
159
A list of frequently forged MAIL FROM domains can be found at http://
160
www.monkeys.com/anti-spam/filtering/sender-domain-validate.in.
162
NOTE: One of the first things you might want to do is to turn on sender address
163
verification for all your own domains.
165
SSeennddeerr aaddddrreessss vveerriiffiiccaattiioonn ffoorr aallll eemmaaiill
167
Unfortunately, sender address verification cannot simply be turned on for all
168
email - you are likely to lose legitimate mail from mis-configured systems. You
169
almost certainly will have to set up white lists for specific addresses, or
170
even for entire domains.
172
To find out how sender address verification would affect your mail, specify
173
"warn_if_reject reject_unverified_sender" so that you can see what mail would
176
/etc/postfix/main.cf:
177
smtpd_sender_restrictions =
180
check_sender_access hash:/etc/postfix/sender_access
181
reject_unknown_sender_domain
182
warn_if_reject reject_unverified_sender
184
# Note 1: Be sure to read the "Caching" section below!
185
# Note 2: Avoid hash files here. Use btree instead.
186
address_verify_map = btree:/var/mta/verify
188
This is also a good way to populate your cache with address verification
189
results before you start to actually reject mail.
191
The sender_access restriction is needed to whitelist domains or addresses that
192
are known to be OK. Although Postfix will not mark a known-to-be-good address
193
as bad after a probe fails, it is better to be safe than sorry.
195
NOTE: You will have to whitelist sites such as securityfocus.com and other
196
sites that operate mailing lists that use a different sender address for each
197
posting (VERP). Such addresses pollute the address verification cache quickly,
198
and generate unnecessary sender verification probes.
200
/etc/postfix/sender_access
204
The "reject_unknown_sender_domain" restriction blocks mail from non-existent
205
domains. Putting this before "reject_unverified_sender" avoids the overhead of
206
generating unnecessary probe messages.
208
The unverified_sender_reject_code parameter (default 450) specifies how Postfix
209
replies when a sender address is known to bounce. Change this setting into 550
210
when you trust Postfix's judgments.
212
AAddddrreessss vveerriiffiiccaattiioonn ddaattaabbaassee
214
NOTE: By default, address verification information is not stored in a
215
persistent file. You have to specify one in main.cf (see below). Persistent
216
storage is off by default because it may need more disk space than is available
219
Address verification information is cached by the Postfix verify daemon.
220
Postfix has a bunch of parameters that control the caching of positive and
221
negative results. Refer to the verify(8) manual page for details.
223
The address_verify_map (NOTE: singular) configuration parameter specifies an
224
optional persistent database for sender address verification results. If you
225
don't specify a file, all address verification information is lost after
226
"postfix reload" or "postfix stop".
228
If your /var file system has sufficient space, try:
230
/etc/postfix/main.cf:
231
# Note: avoid hash files here. Use btree instead.
232
address_verify_map = btree:/var/mta/verify
234
NOTE: Do not put this file in a file system that may run out of space. When the
235
address verification table gets corrupted the world comes to an end and YOU
236
will have to MANUALLY fix things as described in the next section. Meanwhile,
237
you will not receive mail via SMTP.
239
The verify(8) daemon process will create a new database when none exists, and
240
will open/create the file before it enters the chroot jail and before it drops
243
MMaannaaggiinngg tthhee aaddddrreessss vveerriiffiiccaattiioonn ddaattaabbaassee
245
The verify(8) manual page describes parameters that control how long
246
information remains cached before it needs to be refreshed, and how long
247
information can remain "unrefreshed" before it expires. Postfix uses different
248
controls for positive results (address was accepted) and for negative results
249
(address was rejected).
251
Right now, no tools are provided to manage the address verification database.
252
If the file gets too big, or if it gets corrupted, you can manually rename or
253
delete the file and run "postfix reload". The new verify daemon process will
254
then create a new database.
256
CCoonnttrroolllliinngg tthhee rroouuttiinngg ooff aaddddrreessss vveerriiffiiccaattiioonn pprroobbeess
258
By default, Postfix sends address verification probe messages via the same
259
route as regular mail, because that normally produces the most accurate result.
260
It's no good to verify a local address by connecting to your own SMTP port;
261
that just triggers all kinds of mailer loop alarms. The same is true for any
262
destination that your machine is best MX host for: hidden domains, virtual
265
However, some sites have a complex infrastructure where mail is not sent
266
directly to the Internet, but is instead given to an intermediate relayhost.
267
This is a problem for address verification, because remote Internet addresses
268
can be verified only when Postfix can access remote destinations directly.
270
For this reason, Postfix allows you to override the routing parameters when it
271
delivers an address verification probe message.
273
First, the address_verify_relayhost parameter allows you to override the
274
relayhost setting, and the address_verify_transport_maps parameter allows you
275
to override the transport_maps setting.
277
Second, each address class is given its own address verification version of the
278
message delivery transport, as shown in the table below. Address classes are
279
defined in the ADDRESS_CLASS_README file.
281
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
282
|DDoommaaiinn lliisstt |RReegguullaarr ttrraannssppoorrtt|VVeerriiffyy ttrraannssppoorrtt |
283
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
284
|mydestination |local_transport |address_verify_local_transport |
285
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
286
|virtual_alias_domains |(not applicable) |(not applicable) |
287
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
288
|virtual_mailbox_domains|virtual_transport|address_verify_virtual_transport|
289
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
290
|relay_domains |relay_transport |address_verify_relay_transport |
291
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
292
|(not applicable) |default_transport|address_verify_default_transport|
293
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
295
By default, the parameters that control delivery of address probes have the
296
same value as the parameters that control normal mail delivery.
298
FFoorrcceedd pprroobbee rroouuttiinngg eexxaammpplleess
300
In a typical scenario one would override the relayhost setting for address
301
verification probes and leave everything else alone:
303
/etc/postfix/main.cf:
304
relayhost = $mydomain
305
address_verify_relayhost =
308
Sites behind a network address translation box might have to use a different
309
SMTP client that sends the correct hostname information:
311
/etc/postfix/main.cf:
312
relayhost = $mydomain
313
address_verify_relayhost =
314
address_verify_default_transport = direct_smtp
316
/etc/postfix/master.cf:
317
direct_smtp .. .. .. .. .. .. .. .. .. smtp
318
-o smtp_helo_name=nat.box.tld
320
LLiimmiittaattiioonnss ooff ffoorrcceedd pprroobbee rroouuttiinngg
322
Inconsistencies can happen when probe messages don't follow the same path as
323
regular mail. For example, a message can be accepted when it follows the
324
regular route while an otherwise identical probe message is rejected when it
325
follows the forced route. The opposite can happen, too, but is less likely.
added
removed
README_FILES/ADDRESS_VERIFICATION_README
