On 23 May 2003, Nigel Metheringham wrote:
> The interesting part is that it looks as though this is caused by the
> verify code - if I comment out the line in my rcpt acl reading:-
> require verify = sender/callout=30s,defer_ok
>
> then I don't see the kernel message. Just to make things even more
> obscure. I can simplify that down to
> require verify = sender
>
> and I still see the same result *unless* the sender is a locally defined
> address (ie no DNS etc). There are no entries in the acl prior to that
> which would prevent that acl being run.
Hmm. Odd. There shouldn't be any subprocesses used in verifying a remote
address. There might be for a local address if .forward were used. That
is precisely the wrong way round.
> This implies to me that this is happening in the verify path, maybe in
> the dnslookup router (the only one run for remote addresses). It is not
> being seen for outgoing messages or locally run verify (ie exim -bt
> etc).
Even more strange, because the same routers should be used - assuming
you aren't playing games with verify_only etc.
The dnslookup router doesn't use subprocesses - but maybe your resolver
does?
> I'm rather foxed here...
Suggestion: you add code at the start and end of the dnslookup router to
write to the log. Then see if what you write surrounds the problem
messages.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
