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.
Bill
--
韓家標
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
