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

Colin wrote:
>
> On 27/10/2011 09:37, W B Hacker wrote:
>> Colin wrote:
>>>
>>> Thank you for the reply,
>>>
>>> All mail comes through frontend filtering servers which deliver via TLS
>>> on port 25, so 587 is not involved.
>>>
>>> As it happens I believe I have tracked down the cause.
>>>
>>> I have the following ACL which doesn't behave as I expected. This to my
>>> understand should require a verify only if the recipient domain is
>>> listed in /etc/staticroutes.
>>>
>>> warn
>>> condition = ${if eq
>>> {1}{${lookup{$domain}lsearch{/etc/staticroutes}{1}{0}}}}
>>> require verify = recipient/callout=30s,defer_ok,use_sender
>>>
>>> This was before my accept authenticated = * so for some reason this is
>>> triggering a verify on other messages - possibly if the sender is listed
>>> in /etc/staticroutes.
>>>
>>> I also wonder, should the defer_ok be in the recipient/callout/defer_ok?
>>> If this is only meant to apply to entries in /etc/staticroutes then it
>>> shouldn't matter, however with it causing verify for other domains I
>>> think it might make a difference?
>>>
>>> Regards,
>>> Colin
>>>
>>
>> Regardless of the rest of it - a 'warn' verb is not going to DO
>> anything to the session itself.
>>
>> Either it IS setting a flag not shown for later action, OR some
>> unrelated clause is doing the 'do'.
>>
>> The only other option would be an over-run on the callout timeout -
>> and that should cause a 'defer', not a 'deny'.
>>
>> - Which MAY be what is actually happening.
>>
>> Suggest temporarily setting:
>>
>> log_selector= +all
>>
>> I'd also add BOTH:
>>
>> logwrite = entering staticroute test
>>
>> log_message = match in staticroute test
>>
>> And see what is going on in more detail when that clause is traversed
>> and triggered.
>>
>> Bill
>>
> Thanks for the reply again.
>
> Regardless of what the warn should or should not do, it is in fact the
> cause. When that is above the auth line things fail. When it is below,
> it succeeds. When I change it to verify = recipient/defer_ok/callout =
> ... then it also succeeds. There are no flags being set by that part of
> the ACL, it is as I copied it.
>
> It is definitely not a timeout because I can monitor the sessions and
> the response comes back within 5 seconds. It is caused when a domain
> exists but does not have an MX record. This is what causes the lookup
> failure.
>
> Regards,
> Colin.
>

Mea culpa. Missed the mixed verbs.

'require' is a verb in its own right. 'deny' class, even.

In this case it over-rides the fact that the 'warn' it is sharing a
blanket with is harmless because it is seen as a NEW clause of its own.

All on one line, yet..

It ignores whatever the 'warn' looked up, and JFD's the test in its own
playpen.

Note in my examples I do not use a 'require' for the rDNS check.

I use a NOT'ed condition.

As in 'trigger *whatever* verb this clause began with ...
.. IF/AS/WHEN ... rDNS check .... FAILS'

Replace the 'require' with a 'condition = ' or '!condition = ' as suits
your need, and it should provide the expected logging.

The neat thing about NOT'ed conditionals is that they make stacked
conditional 'exemptions' easier to make sense of. At least to a Forth
coder.. where exiting on the earliest 'exception' is seen as more
efficient than carrying-on on the most inclusive 'case of'

;-)

Getting it to 'deny' or 'defer' then needs only changing the 'warn' verb
to <whatever>.

ELSE setting a flag and testing that later, in combination with other
foo if need be...

Bill

--
韓家標