Frank Elsner wrote:
> Hello,
>
>
> because I'm curious ... why the different handling?
>
> ldap_default_servers ... "... are tried in turn until one successfully ..."
> spamd_address ... "The servers are queried in a random fashion"
Purely a SWAG, but my guess as to the rationale is that:
- LDAP calls are likely to be much the same type, ergo consistent and
predictable load each go... and more likely to include 'off box' calls.
- resource load generated by spamd calls should vary considerably based on
message arrivals to be scanned being of different size, mime-type, attachments
or not, and if so what sort of scanning or prep (think nested archives) is to be
applied... AFAICS, spamd is also more likely to be implemented 'on box', even
if siad 'box' is a spam filtering engine, not the promo MTA.
>
>
> Can I force "tried in turn" for spamd_address?
>
>
>
> Kind regards,
> Frank Elsner
>
For sure if you grok C and don't mind recompiling.
Otherwiee?
Pass.
How many spamd 'engines' are you going to have available from which to choose?
Will they be on on-box, and if so will multiple independent ones save any
*overall* resources or add any *overall* speed [1]?
If OFF box, will they be able to work as effectively AND not have possible link
or fs delay/latency/blocking?
IOW - not sure what one might actually see as a net improvement with a change to
the status quo.
Bill
[1] JMNSHO, but moving about half the tests SA makes in an interpreted language
- basically anything that needs off-box calls or resources, such as DNS or RBL
queries, out of SA and into Exim acl's lets a skinned-down SA run lighter and
return results faster.
CAVEAT: Adjust score thresholds downward according to tests migrated out, as
their 'demerit' points will no longer be contributed on the spamd side of the
connection.
