Re: [exim] appendfile allow_symlink

On 2008-03-28 at 13:02 -0400, Jason Keltz wrote:
> In our case, all of our machines have access to /var/mail via NFS for
> local mail applications that do not use imap/pop. We will start to
> change this soon by small groups of users at a time. However, in order
> to be able to do this, we would like to be able to place the mail of the
> "localized" users into a different directory on the mail server, and
> then symlink /var/mail/USER to say, /local/mail/USER .. Now, the users
> can only get at their INBOX via imap, yet exim can still deliver to
> their inbox because its still writing to /var/mail. Later once everyone
> has been moved, /var/mail will simply become /local/mail. If there was
> an "allow_root_symlink" instead of just "allow_symlink", this would
> solve my problem.

A different opinion.

Avoid the symlink issue from Exim's PoV, don't defer trust for delivery
locations into the file-system. Let the users break the symlinks if
they want to make their life awkward. The symlinks should be a
convenience for mail-clients and nothing more.

Use two routers, the first one with
require_files = /local/mail/$local_part

Either use two almost-matching transports, or one transport which uses
$address_data as set by address_data in the router.

begin routers

new_delivery_location:
..
require_files = /local/mail/$local_part
address_data = /local/mail/$local_part

old_delivery_location:
..
address_data = /var/mail/$local_part

begin transports

local_delivery:
..
file = ${if def:address_data {$address_data}{/var/mail/$local_part}}
..

The last bit can be "file = $address_data" if you're sure that you've
found every router which might select the local_delivery transport,
since the conditional logic is 'just' a fail-safe.

-Phil