From: Mark Hunting on 10 Feb 2010 10:00
Wietse Venema wrote:
> Mark Hunting:
>> We use Postfix for some time now, and it's really a great relieve after
>> having used qmail for years. However there's one issue I am unable to solve.
>> Next to the usual virtual mailboxes and aliases we also provide a
>> fallback mail service to some customers that insist on having their own
>> mail server in their office (usually connected to an ADSL line). Our
>> server is a low-priority MX for these domains. When the customer's mail
>> server or ADSL line is down we accept the mail for them, and deliver it
>> to their server as soon as it is reachable again.
>> To prevent backscatter I have set reject_unverified_recipient in the
>> smtpd_recipient_restrictions. But when the customer's server is down,
>> recipients can't be verified of course. So I set
>> unverified_recipient_defer_code to 250, and mail is now accepted when
>> the customer's server is down. Unfortunately some servers we relay for
>> are quite slow on address verification sometimes, and then postfix
>> defers (and accepts with code 250) the mail just before the customer's
>> server answers that the address is invalid. This causes backscatter and
>> I want to prevent that.
> To prevent backscatter, increase address_verify_poll_count or don't
> set unverified_recipient_defer_code to 250.
> It is too much trouble to distinguish between the different reasons
> why Postfix can't get a positive RCPT TO response from a server
> (no DNS lookup, no TCP handshake, no SMTP handshake, no TLS handshake,
> no MAIL FROM/RCPT FROM reply, or the server server replies with a
> 4xx status).
> I recommend maintaining a persistent cache for address verification
> results that are collected when the customer is up, so that Postfix
> will almost never have to verify a valid recipient addresses while
> a remote server is down or slow.
> Postfix will refresh existing recipient entries long before they
> expire, without introducing delay for those recipients even when
> the remote server is down or slow.
> This cache will grow over time. Postfix 2.7, due to be out any week
> now, introduces automatic cleanup of the verify cache.
Thanks a lot for your answer Wietse! I will increase the
address_verify_poll_count to see if it helps.
I also came up with the idea of using the persistent cache, in fact we
already use it. But for these domains we are only the fallback MX, so
when a customer's server is up and running we hardly receive any mail
for it, and our cache doesn't fill up like we want for this to work.
For other customer's servers we are the primary MX, and for them this is
the perfect solution.