Tony Finch wrote:
> On Tue, 25 Apr 2006, Chris Shucksmith wrote:
>
>>I am trying to interpret several header values in the condition= line of
>>a router. I'm having real problems with curly braces and subsequently
>>Exim fails to start. If anyone can spot the error I would appreciate
>>your guidance.
>
>
> I think all you are missing is a \ on the first line.
>
> The way I would format it is as follows. I vary the cuddliness of the
> brackets in a systematic way, so that inner conditions stand out, and
> so that double nestings pair up.
>
> condition = ${if or{{ def:header_X-Spam-Flag: } \
> { def:header_X-Amavis-Alert: } \
> { and{{ def:header_X-Merlot-Blacklisted: } \
> { def:header_X-Spam-Level: } \
> { >{$header_X-Spam-Level}{1.5} }} }} \
> {yes} {no} }
>
> This is much more complicated than I allow string expansions to get.
>
> Tony.
Bravo ..
There are hints throughut the docs about relative efficiencies,
but the convenience of using Exim's superb ability to handle
strings may blind us to how Von-Neuman architecture has to work
at a lower level.
Ex: Here we assign integer 'score' values and thresholds for
most tests that are not already Boolean. The CPU can compare two
integers *way* faster than it can parse strings, and boolean
flags even faster.
Taking just a portion of the above for a faster approach:
==============================================================
condition = ${if >{$spam_score_int}{${eval:$acl_m7}}{1}{0}}
==============================================================
- where acl_m7 is carrying one of several per-user thresholds
extracted once the message recipient is known. OR a system-wide
value set in a macro. Or hard-coded as '15' in the specific case
above.
Then we use *separate tests* for any other similar need.
We also add the headers late, if at all, as a result of the
'score' integers, not the reverse.
Slapping a 'canned' header into place is *way* 'cheaper' than
parsing it later, so we concatenate several message into one header.
Result?
A 1300-line 'configure' not very human-friendly to read.
But the server seldom takes more than one second from
TCP-connection request to final delivery, even when performing
the most complex of tests, SQL calls, extensive logging, then
dual-deliver to both an archive and the users's mailstore.
Even when SA or RBL's are triggered (seldom) it stays around 1
to 3 seconds.
Simple modules are also far easier to test, debug, modify - even
if there are a lot more of them.
JFWIW
Bill
