On Wed, Jul 22, 2009 at 3:49 PM, Ned
Freed<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
But the same issues affect section 2.3. If the list can't be
enumerated, you can't redirect to it.
:list is not a match type in this case, again it is a black box.
...
So I would like to correct your statement. There is no need whatsoever to
be
able to enumerate list membership in Sieve in order to redirect.
The only requirement is that whoever does mailing list expansion needs to
be
able to do that. Such entity doesn't have to be the Sieve engine.
Two things:
1. When I say that the list must be enumerable, I don't necessarily
mean "by the Sieve engine." It's possible for the list not to be
enumerable at all, even by the list handler. Examples are where the
list stores hashes of email addresses (to preserve privacy, perhaps)
and where the list stores mailbox patterns (all members of department
Z have email addresses that start with "dz", so the list of department
Z members is querieable ("Is X a member?"), but not enumerable).
Exactly so. And by the same token, a list you can redirect to may not
necessarily be queryable in any other way.
+1
2. Ah, so you're suggesting that the Sieve engine, which knows how to
do a redirect, should pass this on to the list handler, which now also
has to know how to do a redirect. I'm not sure that's a good idea,
but I could perhaps be convinced. I'm curious about what Ned thinks
here.
Handling redirect :list by throwing the problem over the fence to a list
processors is an interesting approach. We actallly use a variant of it - the
sieve machinery performs variouos actions on the messeage but then invokes our
more general list expansion machinery to get the necessary address list.
i wonder whether the specification would be cleaner and clearer if it
allowed the sieve and list engines to collaborate in executing the
redirection in the most convenient fashion
- robert