I've changed the subject and moving my reply to the Sieve mailing list,
where I think it belongs.
Agreed.
>> There is also a Sieve extension for making use of whitelists/blacklists
>> during mail delivery. See draft-melnikov-sieve-external-lists-02.txt.
>> It can work with CARDDAV, LDAP and other things.
>
> Interestingly, this extension in its current form is not compatible with
> at least one of the proposals that was made here. The issue is one I've
> raised before - the fact that :list is separate argument and not a
> match type.
>
> Where there is clearly some utility in being able to say stuff along the
> lines of:
>
> header :contains :list "subject" "tag:dirty-word-list"
>
> The problem is that in order for this to work the list has to be
> enumerable.
This wasn't the intent. I was certainly aware of the need not to
retrieve the whole membership list.
But you are saying that my syntax wouldn't work in this case.
It's not a question of syntax, but semantics. When a list isn't enumerable it
typically only supports some specific sort of matching that's intrinsic to the
list. In most case it's a :is match in sieve parlance, but not always.
So what you end up with are lists where some subset of
:is/:contains/:regex/:matches cannot be used. And which combinations are
and are nt allowed is going to vary from list to list.
There are basically two ways to address one. One is to say "some combinations
of :list and variaus MATCH-TYPES" are going to fail in some cases".
Alternately, we can simply say "the MATCH-TYPE is implied by the list itself,
and :list is therefore best thought of as a MATCH-TYPE".
I strongly prefer the latter. The former has least astonishment violation
written all over it. It also fails to allow for lists whose underlying match
criteria do not align with existing Sieve match types, and there are a LOT of
those; prefix match, suffix match, IP address pattern matches, etc. And before
anyone suggests defining new match types for these, allow me to point out that
in some cases the ynderlying match types allowed from some sources are open
ended and extensible.
> Not all lists are enumerable, and even some that are are so large even
> though oyu can enumerate them in theory you can't afford to do so in
> practice.
> One use case where this matters is when the list is a set of hashed
> values. The
> way you find if something is "on the list" is to hash it and see if
> that value
> appears. And even if the input string is short enough that you can
> enumerate
> all the unique substrings, how about :matches and :regex? Good luck with
> those.
> Hashed lists have in fact been proposed in the present discussion as a
> means of
> avoiding giving your address whitelist to the mail server. I happen
> not to
> think this is a useful thing to do for a variety of reasons, mostly
> having to
> do with address canonicalization (or lack thereof), but there are other
> use cases where hashed lists make more sense.
>
> So, although it reduces functionality, I believe :list should be a
> match type
> and the underlying comparison type that's done should be a property of
> the list
> itself.
Hmm. You are probably right, :list as a modifier is a bit of a hack.
How would the new match type work with tests other than
header/address/envelope?
Well, for example, something like
string :list "target-string" "list-name"
would check to see if the list named "list-name" has "target-string" as
a member using whatever membership criteria the list is set up for.
Ned