Author: W B Hacker Date: To: exim users Subject: Re: [exim] Recipient verify only for non-authenticated users
Colin wrote: >
> On 27/10/2011 06:42, W B Hacker wrote:
>> A host lookup (of any kind..) should NOT be called for on submission
>> port 587.
>>
>> The typical user pool will be on broadband or dial-up and have neither
>> a proper PTR RR nor DNS 'chain' that Exim (fairly forgiving and
>> persistent at 'finding a way') is able to vet as smtp-useful.
>>
>> You need to grep-out that clause and modify what is around it.
>>
>> Here are a couple of examples for making exceptions on a similar issue.
>>
>> ====
>> deny
>> condition = ${if eq{$interface_port}{25}}
>> !verify = reverse_host_lookup
>> ===
>>
>> deny
>> !condition = ${if eq{$interface_port}{587}}
>> !verify = reverse_host_lookup
>>
>> ===
>>
>> Don't forget to also cast a glance at a local IP whitelists or such
>> BEFORE hitting anyhting as draconian as these - or as another included
>> !condition on hit.
>>
>> May also need a 'pass' for authorized relays and DNS-less boxen, such
>> as file archivers ELSE their cron reports can be blocked...
>>
>> Bill
>>
> 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.
