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
