The below is in reference to a 3.36 installation.
I have a situation involving non-system accounts in virtual domains.
These accounts are aliased to inboxes like so:
user: /path/to/mailbox
This works peachy keen, but now I need to do something a bit more complex.
If an email comes to one of these domains and has a certain header, it
needs to be saved to the users spam mailbox, which is
/path/to/mailbox.spam, or ${address_file}.spam. I set up a nice
director/transport pair to handle this:
Transport:
spam_file:
driver = appendfile
file = ${address_file}.spam
delivery_date_add
envelope_to_add
return_path_add
director:
mx_spam:
driver = aliasfile
domains = dbmnz;/local/exim/etc/spamfilter.domains.db
condition = ${if eq {$header_x-spam:}{Yes}{yes}{no}}
file = /local/exim/etc/aliases/$domain
user = web
search_type = lsearch*
optional
file_transport = spam_file
pipe_transport = address_pipe
directory_transport = address_directory
So, I test it, and it works as expected as far as when the director
accepts or declines a message. But it always ends up in /path/to/mailbox,
whether mx_spam accepts it or not.
So, I start looking through the book and find a couple of items, one on
page 204 and one on page 219 that seem to indicate that when an appendfile
transport is called as a result of aliasing, the file option doesn't
_need_ to be set. Neither of those references say that its value is
ignored.
Regardless, is my example above not working because I have a misconfig, or
because appendfile overrides file= when called as the result of an alias
to a file?
If my example above won't work, any suggestions? I know I could deliver
to a pipe. Or do a lookup directly out of the aliasfile. or do something
funky w/ suffixes and redirects. But those are all gross. I would
appreciate any ideas for something more elegant.
Thanks
--John
