Viktor Dukhovni:
> On Tue, Jan 08, 2013 at 02:39:17PM -0500, Wietse Venema wrote:
> > Viktor Dukhovni:
> > > On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote:
> > >
> > > > I could add an option to treat this in the same manner as "failure
> > > > to connect" errors (i.e. temporarily skip all further delivery to
> > > > this site). However, this must not be the default strategy, because
> > > > this would hurt the far majority of Postfix sites which is not a
> > > > bulk email sender.
> > >
> > > Such a feedback mechanism is a sure-fire recipe for congestive
> > > collapse:
Given that sites will tempfail a delivery attempt to signal a "stay
away" condition, it makes sense to provide an option for bulkmailers
to treat those responses accordingly. That does not mean that this
option will be sufficient to solve all mail delivery problems. Some
parts will require human intervention.
The "stay away" condition is similar to "failure to connect", except
that one might want to use different timers. With "failure to
connect" the timer choice depends more on sender preferences, while
with "failure to deliver" the timer choice would depend more on the
destination.
Coming to the issue of receiver's limits: when receivers slam hard
on the brakes, I don't see how Postfix could automatically tune the
delivery rate (as a fictitious example, suppose that a transgression
results in a 30-minute penalty during which no mail will be accepted
from the client IP address).
My conclusion is that Postfix can continue to provide basic policies
that avoid worst-case failure modes, but the choice of the settings
that control those policies is better left to the operator. If the
receiver slams on the brakes, then Postfix can suspend deliveries,
but the sender operator will have to adjust the sending rate.
Wietse
