>>>>> On Fri, 9 Nov 2001 09:35:29 -0800 (PST), >>>>> Nick Sayer <[EMAIL PROTECTED]> (ns) writes:
ns> It seems to me that this could be far more easily done by creating a pseudo- ns> user. Have this user be the target of the alias and his sieve script will ns> be run. That sieve script can have nothing but fileinto directives to ns> populate the public folders. This pseudo-user does not even have to have an ns> INBOX, I don't think. Or if it does, then it will be perpetually empty if ns> your sieve script is written correctly. :-) And that's the catch, or at least one of them. Locally, we've kicked this idea around somewhat. If there is a problem with the script, as per the RFC the mail will drop into the inbox. This means we pretty much have to give that folder admin access to both areas. Well, if you do that, what's the point of the shared folder? Of course if you move all the non-user shared folders under "user.", then you've pretty much lost the advantages of having different namespaces. On one hand I can see an argument for having a "user." corresponding folder to represent the admin or moderator of the shared folder area. However, this would be pretty convoluted and complicated to explain to folks, I suspect. If at the beginning of the script you could define the "inbox", then perhaps this might be more feasible. Though, that would break the RFC. What if this define had a typo in it. Mail bounces? Perhaps as a last resort it would drop back to the real default. Oh, my head hurts. -- Amos
