++ 02/10/08 01:10 -0700 - Phil Pennock:
>On 2008-10-02 at 09:40 +0200, Rejo Zenger wrote:
>> I am trying to create a nested condition for a router and I seem to be
>> unable to get it working. I have now:
>>
>> ${if and { \
>> { or { \
>> {def:h_List-Id:} \
>> {eq {$sender_address}{}} \
>> {match{$h_X-Spam-Flag:}{(?i)YES}}
>
>You're missing a backslash at the end of that line.
My bad. This wasn't a problem in my configuration. The missing backslash
was introduced when preparing the initial posting and reformarting the
condition for the sake of readability.
[...]
>This is the problem, I suspect. The {false}{true} here is what you'd
>use in ${if CONDITION {TRUE-CASE}{FALSE-CASE}} after CONDITION. The
>or{{C1}{C2}{C3}} together forms a condition. The and{{C4}{C5}} forms a
>condition. C1...C5 are conditions. So the and{} takes conditions, not
>strings.
Understood. Clear.
[...]
>and the EXTRA-BITS is leading to a parse error, with a less than ideal
>error message.
Yup. Which is why have been counting all the braces a zillion times. :)
>So expressing that directly and assuming that the username is, by this
>point, the $local_part being routed:
>
> ${if and{\
> {!def:h_List-Id:}\
> {!eqi{$h_X-Spam-Flag:}{yes}}\
> {!eq {$sender_address}{}}\
> {forany{${addresses:$h_To:}:${addresses:$h_Cc:}}\
> {eqi{$local_part}{${local_part:$item}}}}\
> }}
I have copied this to my configuration and allthough I haven't tested
all separated conditions an intial test shows this does what I want it
to do. Thanks for your help Phil. Thank you.
One more thing, you said "and assuming that the username is, by this
point, the $local_part being routed". Why wouldn't that be the case? In
my situation, this part of a router which is one of a couple taking care
of the local delivery of the message.
--
Rejo Zenger . <rejo@???> . 0x75FC50F3 . <
https://rejo.zenger.nl>
GPG encrypted e-mail prefered.
