Dan wrote:
[snip]
Yes.
Though after starting to get this going, I realised that this also does not
100% match my needs. Admittedly my setup is a bit complicated, as after the
initial postfix are multiple email systems. The "local" one is a cyrus IMAP
server, but some users get their mails also delivered to other (LAN-local)
mail servers we run for different projects (e.g. an Exchange server).
Ideally dspam would work for them as well. But then there may even be
addresses that are split to go out to other servers outside of our LAN
(which should not be filtered). Argh.
The latter aside, the content filter may not be good as it uses the resolved
forwarding address.
This is your choice...
This is wanted for aliases, but not wanted for forwards
(esp. multiple ones), as the user would not necessarily know the internal
addresses.
Argh. I think this is something that is rather difficult (if at all) to
achieve. Maybe the best would be to use the mailbox_transport method, so
anybody who wants email to be filtered & forwarded to other mail systems
must do the forwarding in cyrus (should be no big problem with web sieve).
Or is there some way to achieve the complicated?
you can achieve a high level of flexibility with a "relay" setup:
postfix1 -> dspam -> postfix2
define different aliases on postfix1 and postfix2. that is, on postfix1,
define virtual aliases that should be expanded before dspam. and on
postfix2 define virtual aliases that should be expanded after dspam
(mailing lists for example).
if you want to skip filtering based on the client or the sender, then
you can use the FILTER statement in an access check (see a previous post).
if you want to skip dspam based on the recipient, then the best is to
make postfix1 and postfix2 two different instances (run postfix twice
with different config and queue directories, not just add an smtpd to a
single master.cf), then do not use FILTER or content_filter at all.
Instead use transport_maps to route mail through dspam or directly to
postfix2 depending on the recipient (per recipient transports).
if you don't want multiple postfix instances (despite many of their
benefits:), you can "lock" dspam virtual uids table (remove
auto_increment or don't grant write ... etc).
