Patrik Rak:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 16.5.2013 13:13, Wietse Venema wrote:
>
> > You can try. I hope you can also document the result! Neither
>
> I'll do my best. Fortunately it seems this knob is pretty
> straightforward to explain to the end users.
>
> > Victor nor I have been able to fully absorb the subtle details
> > of nqmgr in a reasonable time span (like a long weekend or so).
>
> We can try to arrange some kind of online meeting about this someday if
> you wish. It would be even better to have a real whiteboard around, but
> we can try.
How much time do you have? I estimate this will take 3-4 sessions
of about 3-4 hours each, 1-2 per weekend. Obviously that can't be
done primarily by keyboard. In the worst case we may have to set
up some temporary account to keep international phone charges
under control.
> > Just be aware that persistent backlog will also affect geylisted
> > mail, as the time to make one pass over the deferred queue increases
> > with backlog size. Increasing the maximal_backoff_time only delays
> > the onset of trouble.
>
> I was thinking about related issue today, too. The enhancement I was
> considering was that rather than classifying all deferred mail as
> "slow", we can exclude deferred mail which is not in the deferred queue
> for longer than some configurable time (explicit retry count might be
> even better, but we don't keep track of that now). That would prevent
> the greylisted mail from being put into the same class as the entire
> backlog, which might be too harsh for fresh deferred mail.
That is an optimization for near-empty deferred queues, but does
not address the concern that I raise above. Aside from that, your
optimization does not seem to introduce new worst-case behavior so
it is mostly harmless.
Wietse
