Postfix Address Verification Howto

习惯使用Postfix了

WARNING

The sender/recipient address verification feature described in this document is suitable only for low-traffic sites. It performs poorly under high load and may cause your site to be blacklisted by some providers. See the "" section below for details.

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.

The technique has obvious uses to reject junk mail with an unreplyable sender address.

The technique may also be useful to block mail for undeliverable recipients, for example on a mail 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.

This feature is available in Postfix version 2.1 and later.

Topics covered in this document:

A sender or recipient address is verified by probing the nearest MTA for that address, without actually delivering mail. The nearest MTA could be Postfix itself, or it could be a remote MTA (SMTP interruptus). Probe messages are like normal mail, except that they are never delivered, deferred or bounced; probe messages are always discarded.

Internet	->		<->					<->		Address verification database
				| probe messages v			^ delivery status |
				Postfix queue		->	Postfix delivery agents

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.

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 and parameters. See for details.

• When verifying a remote address, Postfix probes the nearest MTA for that address, without actually delivering mail to it. If the nearest MTA accepts the address, then Postfix assumes that the address is deliverable. In reality, mail for a remote address can bounce AFTER the nearest MTA accepts the recipient address.

• Some sites may blacklist 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.

• Normally, address verification probe messages follow the same path as regular mail. However, some sites send mail to the Internet via an intermediate ; this breaks address verification. See below, section , for how to override mail routing and for possible limitations when you have to do this.

• Postfix assumes that an address is undeliverable when the nearest MTA for the address rejects the probe, regardless of the reason for rejection (client rejected, HELO rejected, MAIL FROM rejected, etc.). Thus, Postfix rejects mail when the sender's MTA rejects mail from your machine. This is a good thing.

• Unfortunately, some major sites such as YAHOO do not reject unknown addresses in reply to the RCPT TO command, but report a delivery failure in response to end of DATA after a message is transferred. Postfix address verification does not work with such sites.

• By default, Postfix probe messages have "postmaster@$" as the sender address. This is SAFE because the Postfix SMTP server does not reject mail for this address.

  You can change this into the null address (" ="). This is UNSAFE because address probes will fail with mis-configured sites that reject MAIL FROM: <>, while probes from "postmaster@$" would succeed.

As mentioned earlier, recipient address verification may be 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.

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.

/etc/postfix/main.cf:
     = 
        
        
        ...
        
        
        ...

The "" restriction blocks mail for non-existent domains. Putting this before "" avoids the overhead of generating unnecessary probe messages.

The parameter (default 450) specifies how Postfix replies when a recipient address is known to bounce. Change this setting into 550 when you trust Postfix's judgments.

It is relatively safe to turn on sender address verification for specific domains that often appear in forged email.

/etc/postfix/main.cf:
     = hash:/etc/postfix/sender_access
     = 550
    # Note 1: Be sure to read the "" section below!
    # Note 2: Avoid hash files here. Use btree instead.
     = btree:/var/mta/verify
 
/etc/postfix/sender_access:
    aol.com     
    hotmail.com 
    bigfoot.com 
    ... etcetera ...

At some point in cyberspace/time, a list of frequently forged MAIL FROM domains could be found at .

NOTE: One of the first things you might want to do is to turn on sender address verification for all your own domains.

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 white lists for specific addresses, or even for entire domains.

To find out how sender address verification would affect your mail, specify " " so that you can see what mail would be blocked:

/etc/postfix/main.cf:
     = 
        
        ... 
         hash:/etc/postfix/sender_access
        
          
        ...
    # Note 1: Be sure to read the "" section below!
    # Note 2: Avoid hash files here. Use btree instead.
     = btree:/var/mta/verify

This is also a good way to populate your cache with address verification results before you start to actually reject mail.

The sender_access restriction is needed to whitelist 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.

NOTE: You will have to whitelist 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.

/etc/postfix/sender_access
    securityfocus.com OK
    ...

The "" restriction blocks mail from non-existent domains. Putting this before "" avoids the overhead of generating unnecessary probe messages.

The parameter (default 450) specifies how Postfix replies when a sender address is known to bounce. Change this setting into 550 when you trust Postfix's judgments.

NOTE: By default, address verification information is not stored in a persistent file. You have to specify one in main.cf (see below). Persistent storage is off by default because it may need more disk space than is available in your file system.

Address verification information is cached by the Postfix verify daemon. Postfix has a bunch of parameters that control the caching of positive and negative results. Refer to the manual page for details.

The (NOTE: singular) configuration parameter specifies an optional persistent database for sender address verification results. If you don't specify a file, all address verification information is lost after "postfix reload" or "postfix stop".

If your /var file system has sufficient space, try:

/etc/postfix/main.cf:
    # Note: avoid hash files here. Use btree instead.
     = btree:/var/mta/verify

NOTE: 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.

The daemon process will create a new database when none exists, and will open/create the file before it enters the chroot jail and before it drops root privileges.

The manual page describes parameters that control how long information remains cached before it needs to be refreshed, and how long information can remain "unrefreshed" before it expires. Postfix uses different controls for positive results (address was accepted) and for negative results (address was rejected).

Right now, no tools are provided to manage the address verification database. If the file gets too big, or if it gets corrupted, you can manually rename or delete the file and run "postfix reload". The new verify daemon process will then create a new database.

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.

However, some sites have a complex infrastructure where mail is not sent directly to the Internet, but is instead given to an intermediate . This is a problem for address verification, because remote Internet addresses can be verified only when Postfix can access remote destinations directly.

For this reason, Postfix allows you to override the routing parameters when it delivers an address verification probe message.

First, the parameter allows you to override the setting, and the parameter allows you to override the setting. The parameter does the same for sender-dependent selection.

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 file.

Domain list	Regular transport	Verify transport
	(not applicable)	(not applicable)
(not applicable)

By default, the parameters that control delivery of address probes have the same value as the parameters that control normal mail delivery.

In a typical scenario one would override the setting for address verification probes and leave everything else alone:

/etc/postfix/main.cf:
     = $
     =
    ...

Sites behind a network address translation box might have to use a different SMTP client that sends the correct hostname information:

/etc/postfix/main.cf:
     = $
     =
     = direct_smtp

/etc/postfix/master.cf:
    direct_smtp .. .. .. ..  .. .. .. .. .. smtp
        -o =nat.box.tld

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.