Colin wrote:
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.
Mea culpa. Missed the mixed verbs.
'require' is a verb in its own right. 'deny' class, even.
In this case it over-rides the fact that the 'warn' it is sharing a
blanket with is harmless because it is seen as a NEW clause of its own.
All on one line, yet..
It ignores whatever the 'warn' looked up, and JFD's the test in its own
playpen.
Note in my examples I do not use a 'require' for the rDNS check.
I use a NOT'ed condition.
As in 'trigger *whatever* verb this clause began with ...
.. IF/AS/WHEN ... rDNS check .... FAILS'
Replace the 'require' with a 'condition = ' or '!condition = ' as suits
your need, and it should provide the expected logging.
The neat thing about NOT'ed conditionals is that they make stacked
conditional 'exemptions' easier to make sense of. At least to a Forth
coder.. where exiting on the earliest 'exception' is seen as more
efficient than carrying-on on the most inclusive 'case of'
;-)
Getting it to 'deny' or 'defer' then needs only changing the 'warn' verb
to <whatever>.
ELSE setting a flag and testing that later, in combination with other
foo if need be...
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/
