Philip Hazel writes:
>
[...]
> It looks like the required feature is a list of escalating load average
> thresholds to allow the following modes:
>
> (1) accept from anywhere (subject to the limits on numbers of SMTP
> calls), and do immediate deliveries.
>
> (2) accept from some restricted list of hosts/networks and deliver
> it; accept and queue mail from elsewhere.
>
> (3) accept from anywhere, but just queue the mail.
>
> (4) accept only from restricted list, deliver it; do not accept from
> elsewhere
>
> (5) accept only from restricted list, queue it; do not accept from
> elsewhere
>
> (6) do not accept from anywhere
It isn't really so bad if done by independant parameter settings, is it?
If you use the "smtp_reserve_hosts" & "smtp_reserve_nets" to define the
restricted list (surely one wouldn't want different lists for the SMTP
connection control and the load control?) then it only involves four
parameters:
smtp_accept_loadavg_max
smtp_accept_loadavg_queue
smtp_accept_reserve_loadavg_max
smtp_accept_reserve_loadavg_queue
by analogy with existing ones (except that "smtp_accept_reserve_max" is
called "smtp_accept_reserve" and there is no "smtp_accept_reserve_queue").
Of course, this allows even more states than the above, if the ordering of
the values is not what you assume, but there is no limit to the weirdness
of mail administrators' requirements. Some might want the exception list to
be unfavoured rather than favoured, for example.
> together with a separate threshold above which no deliveries at all are
> ever attempted, i.e. queue runners don't do anything (7).
Perhaps this should be "don't run periodic queue runners". i.e. the -q<time>
daemon omits the queue scan if the load average is too high, but a queue
scan can still be forced by an explicit -q call? Or would those who run
queue scans from crontabs prefer the test to be made in the latter case?
Chris Thompson Cambridge University Computing Service,
Email: cet1@??? New Museums Site, Cambridge CB2 3QG,
Phone: +44 1223 334715 United Kingdom.
