Re: [exim] Struggling with condition= syntax

Pàgina inicial
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
A: exim-users
Assumpte: Re: [exim] Struggling with condition= syntax
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