(apologies for messing up the reply-to foo first time 8-)
On Fri, Jul 24, 2009 at 1:55 PM, Ned
Freed<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
2009/7/20 Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com>:
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.
+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