Karl O. Pinc:
>
> On 08/10/2007 01:54:08 PM, Wietse Venema wrote:
> > Karl O. Pinc:
> > > Hello,
> > >
> > > I just had a situation where the sending postfix
> > > (me) uses greylisting, and the receiving postfix
> > > is using address_verify_sender.
> > >
> > > The greylisting generates a 450 response to
> > > the address_verify_sender query triggered by
> > > the initial email. The receiving postfix
> > > appears to be caching this as a failure,
> > > and not retrying the verify sender for some time.
> > > During that period the sending postfix retries
> > > mail delivery, but continues to get a 450
> > > from the receiver until address_verify_negative_refresh_time
> > > runs out.
> >
> > You can disable Postfix's negative reply caching in main.cf, but
> > you do so at your own risk. The default setting caches the reply
> > and therefore guarantees that infinite loops will be broken.
>
> I think what I'm asking for is to differentiate the
> address_verify_negative_refresh_time of the 4xx responses
> from that of the 5xx responses. The 4xx timeout would be
> considerably smaller and serve only to break loops.
You make an unproven assumption, namely that the 4xx reply will
change (into 2xx or 5xx) when you ask the server again.
Wietse
> (OT:
>
> I'm unclear on how infiniate loops are broken. I assume you're
> talking about address verification infinite loops? Seems to me
> these are only rate-limited until the mail expires from the queue.
>
> I'm also unclear on the purpose of address_verify_negative_expire_time.
> Perhaps adding and deleting from the db is expensive? Why wouldn't
> address_verify_negative_expire_time default to maximal_queue_lifetime?
> Seems like once you start you'll often keep hitting the
> cache until the mail goes off the queue.
> )
>
> Karl <kop AT meme DOT com>
> Free Software: "You don't pay back, you pay forward."
> -- Robert A. Heinlein
>
>
>
|
