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

[Ned Freed <ned.freed@xxxxxxxxxxx>]

> 2009/7/20 Ned Freed <ned.freed@xxxxxxxxxxx>:
> >
> >
> >> Hello,
> >
> >> > Would we need to have :list-is, :list-matches, :list-contains, or can we
> >> > get away with just :list, which would check for the exact match?
> >
> >> As far as I understood Ned, it is the list who decides on the exact
> >> match type : it is not up to the script to prescribe the matching. So
> >> "just :list".
> >
> >> Any use cases where :list-is, :list-contains ... make sense and "just
> >> :list" would be insufficient?
> >
> > Sure, you can have lists that support more than one kind of matching,
> > although
> > I expect such cases to be the exception rather than the rule. In such cases
> > I
> > would propose that the type of matching be embedded in the list name
> > somehow.
> >
> > This then gets to the idea of using URLs for list names. A tag: URL is of
> > course completely capable of handling additional embedded material. Other
> > URL schemes, not so much. In fact I'm not entirely sure how this is supposed
> > to
> > work with LDAP URLs with reasonable efficiency.
> >
> > Consider the fairly typical case of whitelisting based on a personal address
> > book in LDAP. Assuming everyone is OK with users being able to construct
> > and perform their own LDAP searches and have no problem knowing and hard
> > coding
> > the base DN of their entries (both very big ifs), this would call for
> > something
> > like:
> >
> >  if address :list "from"
> >     "ldap:///cn=me,o=pab?mail?sub?(objectclass=regularentry)" {
> >     ... whitelist ...
> >  }
> >
> > The problem with this is we're again back to enumeration - that URL produces
> > a (potentially very large) list of addresses, which would have to be
> > compared
> > one by one to the address(es) extracted from the "from" field.
> >
> > But consider the URL:
> >
> >  ldap:///cn=me,o=pab?mail?sub?(&(objectclass=regularentry)(mail=a@b))
> >
> > This flips the problem around - now the address you're looking for is
> > specified
> > in the URL itself. Now it's up to the LDAP server to find the match, and the
> > simple fact it returned a response is enough to conclude the address is on
> > the
> > list.
> >
> > This is much more efficient, especially if the LDAP server has proper
> > indexing.
> > But now the URL is something that has to be constructed by knowing what
> > you're
> > searching for.
> >
> > I will also note that LDAP URLs can embed very complex matching criteria of
> > their own.
> >
> > Now, I guess I have no problem with using tag: URLs that end up getting
> > converted to the more efficient LDAP URLs seen here. But I really have to
> > question whether anyone is actually going to allow, as the specification
> > implies, the direct use of LDAP URLs or other URLs with similar
> > characteristics.

> +1

> the Sieve engine will face problems of semantics, resolution and
> authentication with direct URLs

The last item is an important point. Anyone who allows, say LDAP URls, is going
to have a fun time analyzing those URls to make sure they don't do  anything
naughty.

				Ned