[Top] [All Lists]

Re: thoughts about external lists

2008-10-28 04:21:37

Hello Ned,

Thanks for your feedback. I agree with you that the lists in address/envelope/header are not-necessary-expandable (could be very large or only check for membership can be made). However this thoughts are not valid for "reject :list", where the parameter has to be a necessary-expandable list.

Със здраве,

Ned Freed wrote:

Rereading draft-melnikov-sieve-external-lists-01 the main idea that came
to my mind is that ":list" adds one more (unnecessary) dimension.  In
case of "header", "address" and "envelope" test, their last parameter so
far is a string-list:

             address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
             <header-list: string-list> <key-list: string-list>

             envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
             <envelope-part: string-list> <key-list: string-list>

             header [COMPARATOR] [MATCH-TYPE]
             <header-names: string-list> <key-list: string-list>

With ":list" added the last parameter will be altered from "list of
strings" to a "list of list of strings".

Not really, it's a list of external lists.

At the same time mixing
"internal" and external lists gets more complicated than necessary.  For
doing a check "if a mail does not come from my three girlfriends,  or my
company, then reject it" it would be necessary to write

    if anyof(envelope "from" ["g1", "g2", "g3"],
envelope :lists "from" ["my-department", "our-partners"]) { reject
":P"; }

I actually prefer this. Rather strongly.

I think it would be better to allow references to lists in any
string-list, which expands the references, so that the string-list can
be used normal.  What about replacing :list "my-pets" with L{my-pets},
hence the above check would be rewritten as

    if envelope "from" ["g1", "g2", "g3", L{my-department},
L{<our-partners}] { reject ":P"; }

Well, first of all, what you're proposing is a syntax change to the core
language. That's unacceptable IMO.

I'm not sure you can get around this problem in a reasonable way - the obvious trick to try is to extend things to support "list" variables. Asuming this can bge made to work, it certainly has things going for it - it lets you do things
like pull in a list, modify it in fairly complex ways, and then check stuff
against it.

However, the problem that arises if you do this is that this is a really
awkward fit into existing implementations (ours at least and I suspect others
too). The problem is that things are geared around first evaluating list
constructs and then checking them, not the other way around. So what if that list expands into 1,000,000 addresses. Or more to the point, what if the list is defined in such a way that the only acces you have is a membership check;
there's no way to extract the list? It' still possible to implement this as
list variables - I think - but it gets really nasty really quickly.

In this way only the definition of string-list has to be changed.  The
test envelope, address and header stay untouched.  For "redirect" one
has just to write that it accepts now string-list instead of just

I'm certainly in favor of having the ability to do list tests in other
contexts, but my proposal is to match :list a new MATCH-TYPE, with all
that implies.


<Prev in Thread] Current Thread [Next in Thread>