We are seeing entries of the following form in our panic log
2000-06-28 11:49:36 user "xxxxx.response" for file existence test not
found
2000-06-28 11:53:43 user "xxxxx.response" for file existence test not
found
[where xxxxx has replaced a valid alias on our system and I am only
getting these for one particular address]
Firstly am I correct in thinking that this means that exim is trying to
run some (unspecified) file existance test as the username
xxxxx.response ?
The only place that response appears in our tests is the following
director which is used for autoreplies to addresses such as abuse etc.
functional_autoreply:
driver = smartuser
domains = "lsearch;TABLES/local_domains.common:\
lsearch;TABLES/local_domains.THISHOST"
transport = autoresponders
require_files = TABLES/forwardfiles/${local_part}.response
user = exim
unseen
which should run as the user exim (and there is not a file
xxxxx.response so nothing occurs) and appears to be working for anybody
else.
The only file existance test that runs under the username is the
standard .forward style test but that director should never be reached
until the alias has been turned into a username (and it works for
everybody else and -d9 on all the tests described below shows exactly
what I would expect)
When I run an address test (-bt) on xxxxx it correctly gives me the
username to which this delivers and when I run a test on xxxxx.response
it gives me 'unknown local user' . I can't think of any other address
to test and can't reproduce the error.
Also there does not appear to be anything related to this address in
the queue, neither can I find the same error message in any of the
message logs. Furthermore the time gap between the log attempts is much
less than our queue run time and there is no message ID so I suspect
that this is actually some SMTP connection - is this a reasonable
assumption?
I have therefore tried an SMTP testing session (-bh) with RCPT TO's of
xxxxx and xxxxx.response and get the correct 250 for xxxxx and 550 for
xxxxx.response.
Basically I can't reproduce the problem! I can't think of any other
address to try and I can't think of any way to trap the SMTP
transaction to find out what that is actually putting in RCPT TO: other
than putting -d9 on my daemon process which is don't think is
practicable from the point of view of coping with the output produced
by every connection.
Can anybody think of anything else I can try?
Jonathan
------------------------------------------------------------------------------
J. R. Haynes
Network Team Leader
Cranfield Computer Centre, e-mail: J.Haynes@???
Cranfield University,
Wharley End, Tel: Bedford (01234) 754205
Cranfield, Bedford (01234) 750111 Extn 4205
Beds., Fax: Bedford (01234) 751814
MK43 0AL.
