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

[Robert Burrell Donkin <[e-mail]>]

2009/7/20 Ned Freed <[e-mail]>:
>
>
>> 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

- robert