On 7/5/2011 1:38 PM, Wietse Venema wrote: > Charlie Orford: >> I will run the tests and get the output for you later tonight but >> my suspicion is that there was likely nothing wrong with the >> address cache, just that a lot of addresses had never been probed >> by the secondary mx as the primary mx is up virtually 99.9% of >> the time. > > Wietse: >> In that case, a hypothetical "tempfail_action = permit" would be >> 99.9% identical to setting up a backup MX without any recipient >> validation and refusing all mail as long as the primary MX reponds. >> >> If there's something missing in Postfix, them that is what should >> be added (refusing mail if the primary responds). > > Charlie Orford: >> That sounds like it would be functionally equivalent to "tempfail_action >> = permit". >> >> The only negative scenario I can think of with this approach is >> if a sending mta happens to be using a broken (or out of date) >> DNS cache and as a result can't resolve / communicate with the >> primary mx but then tries the secondary (which might be served by >> a different NS for which it can get a valid A record) only to find >> the secondary refuses the connection. > > The difference is that "tempfail_action = permit" says "don't accept > mail for known-bogus recipients while the primary responds", while > the second approach says "don't accept mail for any recipients while > the primary responds". > > Fundamentally, both approaches rely on talking to the primary MX, > and therefore both approaches would suffer from errors if the > primary MX DNS information is broken, though the errors would not > be identical. > > Wietse
Maybe a compromise? How about running on the main MX postmap -s btree:/path/verify | grep ':250 ' > file and then export file as a relay_recipients map on the relay. Automate this to run periodically. Hmm, probably need to stop postfix on the main MX for a few seconds to run this, probably once a week would be sufficient to get the active users. -- Noel Jones
