Adam Funk wrote:
*snip*
>
> BTW, I have one other concern. Is it possible for a badly written
> logfile or logwrite instruction in a filter to cause mail to be lost?
>
>
Ordinarily not.
Further, Exim will 'usually' place a line in the log describing (as best it can)
what failed to work.
If, for example, a variable cannot be expanded, a conditional is not structured
in a workable manner, or a dirtree/file cannot be found or written to, that can
cause an acl clause 'set' to be bailed out of. That could leave a message on the
queue OR cause a rejection with the far-end seeing, for example 'temporary local
problem' - but either way there is a trail.
NB: all of these would ordinarily be default log entries unless you have
provided customized failure messages. It may pay to do that = putting some
unique ID as to where the call came from into each message to speed troubleshooting.
CAVEATS:
1) If 'log_selector = ' has been set to very low verbosity, some or all of the
entries might be absent.
If so, you might wish to try it for a time with 'log_selector = +all', then
ratchet that back down afterwards so you don't eat too much disk space.
2) I am assuming similar behaviour for filters - especially in that they may
call router/transport sets - as for in-session acl's.
I've never personally needed an Exim filter, so I may be wrong about that.
HTH,
Bill
--
## List details at
http://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/
