Merlin wrote:
> Hi All
>
> We have a pair of systems running versions 4.41(gateway) and
> 4.43(mail-server) with a Cyrus mail store.
>
> We have noticed 6 messages in the last month that have not been
> delivered to their recipient but have been passed through the gateway
> machine succesfully.
> Exim logs that the message has 'Completed' but show no mention of it
> being delivered - and indeed it isn't.
*trimmed*
> # if the local part prefix matches then redirect to the current_user router
> # if not, drop down to next router
> # we check local user in order to prevent aliases/lists being broken!
> real_prefix:
> driver = redirect
> redirect_router = current_users
You haven't shown this router. Does it exist? And does it select a
transport?
There was no R=(router) T=(transport) in the log snippet you posted, so it
looks as if either you are disposing of the messages before they hit the
routers,
or are traversing all routers without finding a match in any of them.
You have satisfied *something*, else Exim would log a failure.
>Mail Server log entry:
>2005-11-03 11:39:38 1EXdRS-0006FB-NX <= ap454@???
>H=stirling.mrc-dunn.cam.ac.uk [193.60.90.25] P=esmtps
>X=TLSv1:DES-CBC3-SHA:168 S=3355
>id=417CBCF38B7010499DB4EC7FA24A0A1E3C5842@???
>2005-11-03 11:39:38 1EXdRS-0006FB-NX Completed
FWIW, even with expanded logging on, the only time I see 'completed' in
my 4.54 logs is
when I have discarded, etc. *before hitting* a router/transport.
It never shows up as above when a router/transport set were selected and
used.
You can temporarily 'instrument' your configure by:
- Numbering your acl's in comments.
Perhaps also refer to the step of the smtp process, connect thru data,
i.e C1, H1, R1, F1, D1, and D12S6, etc. for scanner steps.
- putting a logwrite = <acl number +terse message> on each acl Gives an
unconditional log entry.
- also putting a log_message = <acl number +terse message> on each warn,
deny, discard, drop. Entry only if triggered.
Optionally load HELO and host address and name information into an
acl_c(n) variable at CONNECT or EHLO/HELO.
Make $acl_c(n) part of each message to make them easier to find in the logs.
That will tell you which acl's a given message traversed, if they
triggered, and - most important - 'who had it last'.
When you need to edit, a find <acl code#> will take you directly to the
problem area.
That won't *fix* the problem - but, with appropriate test messages, it
will tell you exactly *where it is*.
When done with the detective work, selectively comment all/most of those
out until next time you need them.
Aside from 'fat' logs, they take up machine resources.
HTH,
Bill Hacker
