Absolutely correct. We need to turn some things on or off at the domain level (for all in the domain), but still other filters must be run on individual basis.
As long as "mailbox" is not encountered in the domain mailproc.tab, processing should continue with the user mailproc.tab. There are LOTS of good reasons, but for us, the xmail control server works best when it does not have to return a large number of lines. Having the fine grain control to place filters in domain and/or user mailproc.tab's is the best way to reduce the number of lines we have to read and then write back again using xmail control server. Having single user options rune from the individual user mailproc makes great sense! This way, if two users change their options at the same time, they do not both try to access domain mailproc.tab at the same time. Davide please consider this - Anyone else? > That's because logic dictates that a domain-scope mailproc doesn't > replace individual mailboxes' mailproc (or cmdalias), but is run in > addition to them, before them.. Like an inhereting ACL permission system > (May be a good thing to add a "no inheritance" switch to the mailbox > mailproc.tab/cmdalias). > > Anyone has any opinions? Am I going the right way or am I a weirdo here? :) > > Let's "vote". :) - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
