Ok, this is what I came up with and it seems overly "simple" so if I missed
anything, please let me know!
As told by Phil, I added:
local_part_suffix = +*
local_part_suffix_optional
to my "accept" router which sends off to my appendfile transport for message
deliveries (I have not touched my redirect routers yet - for now only
*actual* user accounts can use local part suffixes). Then I went to my
appendfile transport and added:
maildirfolder_create_regex = /\.[^/]+$
and appended "${if eq {$local_part_suffix}{} {}{/.Public
Folders.${substr_1:$local_part_suffix}}}" (without the quotes) to my
directory option for the transport (right after the $local_part variable
which forms part of the system path).
I wasn't sure how it would handle the space in ".Public Folders", so at
first I tried having the entire thing surrounded by ${quote: ...} (so that
the entire directory path would be quoted if required), but that threw
errors when I tested since it seemed to double quote things (for ex, it spat
out ""/mail/user/.Public Folder.exim-users""). I had previously been using
${quote_local_part:$local_part} inside my directory statement but realized
that was probably wrong (since that adds quotes around the local part which
wouldn't make sense if it tried to deliver to /mail/"user") - so I removed
that.
Aside from verifying I've implemented local part suffixes properly
(essentially), should I be quoting/escaping stuff for "directory" for my
appendfile router? I do reject local parts that have ".." in them, but I'm
still a bit wary about having some special filesystem-specific characters
get through and cause a loophole for reading/writing to files they shouldn't
write to. Should I be quoting/escaping the path, and if so how?
Eli.
