Re: [sieve] Question about draft-ietf-sieve-external-lists-02

NED+mta-filters@mauve.mrochek.com Wed, 04 August 2010 23:11 UTC

Return-Path: <NED+mta-filters@mauve.mrochek.com>
X-Original-To: sieve@core3.amsl.com
Delivered-To: sieve@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2FB63A6A49 for <sieve@core3.amsl.com>; Wed, 4 Aug 2010 16:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.204
X-Spam-Level:
X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOBGDy1DHhpW for <sieve@core3.amsl.com>; Wed, 4 Aug 2010 16:11:36 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id BFDDD3A6AA3 for <sieve@ietf.org>; Wed, 4 Aug 2010 16:11:35 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NQAM23Q7DC000FRE@mauve.mrochek.com> for sieve@ietf.org; Wed, 4 Aug 2010 16:12:04 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NQ7TXKVIQ8000CVY@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Wed, 4 Aug 2010 16:12:00 -0700 (PDT)
From: NED+mta-filters@mauve.mrochek.com
Message-id: <01NQAM2295HU000CVY@mauve.mrochek.com>
Date: Wed, 04 Aug 2010 16:00:36 -0700
In-reply-to: "Your message dated Wed, 04 Aug 2010 11:53:37 +0200" <4C5938A1.9050909@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format="flowed"
References: <4C500AB3.7040808@rename-it.nl> <01NQ4OHCU1HE00004A@mauve.mrochek.com> <18437_1280824505_o738Z4AF020978_4C57D4A6.1080902@rename-it.nl> <E6ACF2B10BCC81BCB369A119@minbar.fac.cs.cmu.edu> <4C584DD1.8070205@rename-it.nl> <4C5938A1.9050909@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1280962828; i=@mrochek.com; bh=rMgYaGT05auA39I10imJ+SvZ+zYLbKTSKtaHqnMxn+M=; h=From:Cc:Message-id:Date:Subject:In-reply-to:MIME-version: Content-type:References:To; b=VjOqMlH20BKeg5ltsxK1pS7/lE9j3XFsYYlHqSVXVsDQbI94t41p21Yhqn2D+GrYy KzerX2WwVDjHLXH0qqK+ABuXR7o/M5T6u1+HUqonl9bFzauQXy9CScdL+TTGqi/2Jb JflLUddMBhftwxPkgdJKz9N2qZASBXcNP2akcVHc=
Cc: sieve@ietf.org
Subject: Re: [sieve] Question about draft-ietf-sieve-external-lists-02
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIEVE Working Group <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sieve>
List-Post: <mailto:sieve@ietf.org>
List-Help: <mailto:sieve-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Aug 2010 23:11:38 -0000

> I personally think that comparators should be allowed with :list, but I
> don't have a strong opinion.

Given the points that have been raised, I'm starting to think this is the right
answer. In the rare cases where a compprator does make sense to use with an
external list, it can be encoded into the list name.

> I also think that making Sieve scripts fail because an implementation
> decides that a particular comparator can't be used with :list would be a
> bad idea. If we want to go this route, then we need to define how a
> particular comparator works for a particular external list URI type.

Yeah, but the problem there is what to do about tag: URLs. I don't know what
other implementations have planned, but we're not exactly keen on letting users
specify arbitrary LDAP URLs or anything similar. Instead, the mail admin sets
up whatever tag: URLs (incuding families of them) they want, and these are then
mapped to LDAP, database queries, code callouts, whatever.

As it happens we have no exiting or planned external list mechanisms where a
comparator makes sense, so right now we can simply reject the combination
outright. But suppose this were to change. Given the mapping involved we'd
basically be counting on the admin to specify the handling of comparators, and
this means the admin is going to be responsible for setting it up so an unused
comparator results in an error. Of course we can arrange the defaults so that
the "right" think happens most of the time, but even so this doesn't sound
like all that great of an idea...

				Ned