Re: [exim] Recipient verify only for non-authenticated users

Góra strony
Delete this message
Reply to this message
Autor: Colin
Data:  
Dla: exim-users
Temat: Re: [exim] Recipient verify only for non-authenticated users

On 27/10/2011 11:26, W B Hacker wrote:
>> Hi Graeme, thanks for the reply,
>> I am unsure that I follow it completely. In my understanding, the
>> require verify should only apply if the condition is met.
>
>
> Not so. The ONLY condition that applies to that 'require' is the one
> immediately following it on its OWN line...
>
>

That makes sense now, thank you both for the assistance.
>>
>> How it should behave:
>> If recipient domain is in /etc/staticroutes then do a recipient callout
>> verification. If the verification fails with a permenant error, reject
>> message. If the verification fails with a temporary error, accept and
>> queue for retry.
>>
>> No recipient verification callouts should occur if the recipient is not
>> in /etc/staticroutes (ie the condition is not matched).
>>
>> This is not what happens because recipient verification callouts are
>> happening (and failing) on domains not in /etc/staticroutes.
>>
>> Regards,
>> Colin
>>
>
> Re-write it this way (fix MUA line-wrap!):
>
> =====
>
> deny
>
> ## do a check for presence in static routes file
>
> condition  =  ${if eq {1}{${lookup{$domain}lsearch \
>         {/etc/staticroutes}{1}{0}}}}

>
> ## .. carry-on if found, bail-out if not found
>
> !condition = verify recipient/callout=30s,defer_ok,use_sender
>
> ## having arrived here IF found in the static routes file...
> ## attempt recipient verification by callout
> ## trigger the 'deny' entry verb if callout FAILS
> ## ( the '!condition' of success)
>
> =====
>
> Bill
>


Apparently Exim doesn't like that as all messages fail with this:

invalid "condition" value "verify
recipient/defer_ok/callout=30s,defer_ok,use_sender"

Thanks for the help so far I will do some proper testing on the ACLs out
of hours when I can and report back when I find one that does what I
want it to!

Regards,
Colin.