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

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.