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.
--
## 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/
