By default, when Exim encounters a .forward file with an error in it (or a
problem with the permissions/ownership), it defers the message. This is
presumably so that the user can notice they're not getting any mail and fix the
problem.
Unfortunately, that seems to be a naive assumption, especially at large sites
where users have no access to the logs on the mail server and no shell account
to run `exim -bt` on. An alternate behavior is to just ignore the invalid
.forward file and continue processing the message - this way the user calls
tech support complaining "my .forward file doesn't work" and doesn't chase the
tech in circles with "I'm not getting any mail." This also reduces the
likelihood of bouncing messages due to end-user errors on sites with short
retry values.
To this end, I have patched an additional configuration option into the
forwardfile director in Exim 1.73, called ignore_dont_defer. When set to
true, Exim will simply ignore invalid forwardfiles and continue processing (it
has the forwardfile director return FAIL instead of DEFER or ERROR, except in
certain circumstances that couldn't conceivably be due to user error, i.e. NFS
problems).
The downside of this approach is that mail can be sent to the wrong place due
to a user change (i.e. a recursive chown or the like), however in a "normal"
environment this simply means it goes to the user's mail spool instead of being
forwarded or filtered.
Am I overlooking any other problems this might cause? Is this a Good Thing
that should be included in the next release (it does, after all, default to
FALSE)? Other thoughts?
A context diff of my changes to Exim 1.73 is available at
http://www.slip.net/~dpifke/exim-forwardfile.diff
--
Dave Pifke, dpifke@???
--
*** Exim information can be found at
http://www.exim.org/ ***
