On 2/22/2011 8:03 AM, W B Hacker wrote: > Marc Perkel wrote:
>> Is there a way to tell an ACL to just bypass and do nothing in the case
>> where it normally would return a "Tempory Local Problem" because of
>> something like a failed string expansion or a missing file?
>>
>> The problem I'm trying to fix is that I'm allowing users to type in
>> strings to block messages in headers. But if the user types something
>> that "match" doesn't like then they end up getting their email blocked
>> and no knowing what happened. I'd like to have an "ignore errors"
>> command in an ACL so that if there's some kind of failure the ACL is
>> silently bypassed.
>>
>>
>
> Just do it in two steps, much as if it was a point score accumulation.
>
> Use a 'warn' verb to set up <something> such as a string or acl_?
> variable for the test you cite above.
>
> Put the 'action' verb (accept, deny .. whatever) in a *subsequent* acl
> that inspects what the warn onpassed.
>
> That lets you write your own error-handing / branching... and/or use
> several tests then combine results before taking a decision.
>
> Not much limit to the flexibility ...
>
> HTH,
>
> Bill
>
>
Hi Bill,
Thanks for your advice but it didn't work. The use of WARN still
produced a Temporary Local error. in this example I deliberately created
a bad regex that wouldn't expand. Users create them by accident.
2011-02-22 08:38:49 1PrvGD-0007dm-Ae H=64.junkemailfilter.com
[65.49.42.64] F=<techrepublicnewsletters@???>
temporarily rejected after DATA: failed to expand ACL string "${if
match{$message_headers}{\N*.hotmail.fr\N}}": regular expression error in
"*.hotmail.fr": nothing to repeat at offset 0
What I'm needing is a way to ignore this kind of error and have the ACL
do nothing.
