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

[Robert Burrell Donkin <robertburrelldonkin@xxxxxxxxx>]

(apologies for messing up the reply-to foo first time 8-)

On Fri, Jul 24, 2009 at 1:55 PM, Ned Freed<ned.freed@xxxxxxxxxxx> wrote:
>
>> 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.

+1

i spent some time this morning thinking about the HTTP case - and it's
very interesting :-)

i have some comments related to this but i need some more thinking
time before i post them to the list (i've pushed them to github[1]
just in case anyone wants to see where they're going ATM)

- robert

[1] http://github.com/RobertBurrellDonkin/ietf-mta-filters/tree/master
follow links to ExternallyStoredLists/00