Re: Comments on draft-melnikov-sieve-external-lists-02.txt

[Ned Freed <ned.freed@xxxxxxxxxxx>]

> >> 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.

> 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.

				Ned