On Mon, 2010-04-26 at 09:04 +0100, Graeme Fowler wrote:
> On Mon, 26 Apr 2010 08:26:43 +0100, Ron White <exim.ml@???> wrote:
> > The ACL stanza performing the call out looks like this:
> >
> > drop message = REJECTED - Remote Recipient Verify Failed
> > log_message = relay recipient verification failed
> > domains = +hosted_domains
> > !verify = recipient/callout=15s,defer_ok,no_cache
>
> Just to get your head around it: the drop action acts on the whole ACL
> stanza together with precedence given to the first line. Try it like this:
>
> drop !verify = recipient/callout=15s,defer_ok,no_cache
> message = REJECTED - Remote Recipient Verify Failed
> log_message = relay recipient verification failed
> domains = +hosted_domains
>
> In the former case, the "message" line is always true but a following
> condition fails for some reason - I have no idea why the defer_ok isn't
> being honoured there, though.
> The latter case *should* give you what you want. Maybe :)
>
> Graeme
>
Thanks Graeme. The defer_ok is working now {restart is useful DOH!) -
but it's not something I want to use in my application.
I still have a problem with this despite putting the verb at the top.
drop !verify = recipient/callout=15s,no_cache
message = REJECTED - Remote Recipient Verify Failed
log_message = relay recipient verification failed
domains = +hosted_domains
When this runs and the callout gets a defer back from the remote server:
450 4.2.0 <null@null>: Recipient address rejected: Greylisted
Exim stops with a: "451 Could not complete recipient verify callout"
with the connection still open, plus the message is not what I have
specified.
I thought that the drop action would close the connection as the
verification has not been successful? I'm starting to think because Exim
is giving back a 4xx error the drop is not honoured because of it's
potential temporary status and Exim is expecting either a 2xx == OK or a
5xx == not OK for the callout and is not sure what to do with a 4xx if
the 'defer_ok' option is not set. Ideally I need the callout to
recognize a remote 4xx as an error and for the verify to fail. Kind of
like the opposite of 'defer_ok' - so a 'defer_notok' kind of action.
Perhaps I'm misunderstanding this?
