ietf-mta-filters
[Top] [All Lists]

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

2009-07-19 21:53:39


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(_at_)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.

                                Ned