Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling Clarifications

[Robert Burrell Donkin <[e-mail]>]

On Fri, Jul 31, 2009 at 9:13 AM, Jeffrey Hutzelman<[e-mail]> wrote:
> --On Friday, July 31, 2009 09:09:23 AM +0100 Robert Burrell Donkin
> <[e-mail]> wrote:
>
>> yes - that's been made clear  (a summary of those discussions would
>> have been more useful than just a re-iteration)
>
> I'm sure there will be a summary in the WG minutes, when they're done.

i'm sure that there will

it would have been polite to inform the mailing list that changes - of
a fundamental nature - had been agreed at the meeting, and that any
discussions on - or analysis of - the recently posted draft 00 would
be wasted

- robert


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V979Ce054334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 31 Jul 2009 02:07:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6V979a8054333; Fri, 31 Jul 2009 02:07:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V9772R054327 for <[e-mail]>; Fri, 31 Jul 2009 02:07:08 -0700 (MST) (envelope-from [e-mail])
Received: by fxm7 with SMTP id 7so1233940fxm.10 for <[e-mail]>; Fri, 31 Jul 2009 02:07:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TsfLYCiHSw1DSlNf2P18DhSmp1a+rLNipJEh7RMTylc=; b=S36JVU60gyxGFBaM5rXVsOCDWfHfMrEzW8F9nQSLTWKRWIeys5GvOX5hxdn7+DeDPG OZmMlJs1Jr5rj0j8QL1h4XLsiUuIAuDJ4MUrIm7j4teq+oLmu0unux6WB/sC2fT8RGYY eG9X3P7iQw98iI22515iZSgqTZMlptW41J5/UDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=chAxlP324gCXPab+4LnbUybr9ErrwQf7pQ06gvCOA7f7MKhpHkALNR5gtCKajqSvl6 Qa/I7muNYz1Cfq/Nqc/wEeWDWHfR+EgM630dmXCmzNanj0PjURqi5N84J04F49MkPOQc 62hZQOwqCMkTOX4nHmr1rHSAXCFAGN5nKzdg8MIME-Version: 1.0
Received: by 10.204.71.68 with SMTP id g4mr396409bkj.81.1249031226609; Fri, 31  Jul 2009 02:07:06 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 31 Jul 2009 10:07:06 +0100
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Robert Burrell Donkin <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: [e-mail], Ned Freed <[e-mail]>, MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Jul 31, 2009 at 9:13 AM, Jeffrey Hutzelman<[e-mail]> wrote:
> --On Friday, July 31, 2009 09:09:23 AM +0100 Robert Burrell Donkin
> <[e-mail]> wrote:
>
>> yes - that's been made clear  (a summary of those discussions would
>> have been more useful than just a re-iteration)
>
> I'm sure there will be a summary in the WG minutes, when they're done.

i'm sure that there will

it would have been polite to inform the mailing list that changes - of
a fundamental nature - had been agreed at the meeting, and that any
discussions on - or analysis of - the recently posted draft 00 would
be wasted

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V8wj9n053665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 31 Jul 2009 01:58:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6V8wj51053664; Fri, 31 Jul 2009 01:58:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V8wgtK053651 for <[e-mail]>; Fri, 31 Jul 2009 01:58:43 -0700 (MST) (envelope-from [e-mail])
Received: by fxm7 with SMTP id 7so1229970fxm.10 for <[e-mail]>; Fri, 31 Jul 2009 01:58:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kzfmrrbgALi8qIT7X2EwZ3KXGa9URS7f0ZX2ptX15nw=; b=oKxk5JzTWGE21UwQIy7bLmJQnrjMlh9NcH/CvpkqV+5ESWd2DZvhFaHRybBC1zd6iX 2pUrvMI0JW51o1XtT2tU1iYumiEtuNoZR042OtUq6PGzjmNz46XDze9SC9bv/4PM8/Gn 8mdXvO7FsthKFI1jQU1xHQUKN3ag9Iugl5GZQDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZpEvpEAQyACAAjFWTiFzWgCnoQtaInwJH/nsi/dJYZ4LXWj2TN5Wi9jR8CIoXbfZzm GK4BjzZvcI54Uj4O0nXNtkJdqDL+MQrr1VduVAAuAYp4TfES55tWDcCgeaiu3JiTY6IY XQJuhQnKzO4TvZwj0ZYP2JKMwrTCaUMQuvQ4AMIME-Version: 1.0
Received: by 10.204.102.14 with SMTP id e14mr2465147bko.183.1249030721876;  Fri, 31 Jul 2009 01:58:41 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 31 Jul 2009 09:58:41 +0100
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.2 Allow Extensions To Use  List
From: Robert Burrell Donkin <[e-mail]>
To: [e-mail]
Cc: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Jul 30, 2009 at 6:36 PM, Barry
Leiba<[e-mail]> wrote:
>> Require implementations to raise a compile time error when list
>> is used with an unsupported test.
>
> That's already what happens when there are such errors in scripts.
> Why should we say it explicitly here, and not everywhere else?

philosophically, i believe in full and complete specifications, with
any areas of variance clearly indicated

practically, as the draft 00 stands, i feel that an implementator
might reasonably elect to test the combination of test and match-type
at compile time, at run time or not verify the condition at all. my
strong preference would be to just issue a warning with an option for
raising a runtime error.

so, though my implementation preference would be excluded by this
proposal, at least the expected behaviour would be clearly specified

>>    Implementations MAY support other tests but MUST raise a compile
>>    time error when a script contains any standard test where support has
>>    not been explicitly specified.
>
> Not explicitly specified by whom?  How?

yes - i'm not happy with the wholley language either

probably better just to specify those tests which should not be supported

> How does this make scripts portable?

i'm a little confused by this

when a script contains an extension, it will only compile on engines
that support that extension. asking extensions to abide by the
description of list in this draft (if they support it) means that at
least that may be relied upon by the script writer.

> This seems to encourage private
> extensions, which has really become a thorn in the web.

an extremely controversial statement ATM (but i'm going to avoid
taking the bait)

happily, sieve is extensible so this philosophical question has
already been resolved in the original specification. i think that a
revision of RFC 5228 would be the right place to start for anyone who
disagrees with this fundamental design decision.

what needs to be decided by this working group is whether the group
thinks that list should work uniformly across all extensions

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V8DtTi050318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 31 Jul 2009 01:13:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6V8DtUM050317; Fri, 31 Jul 2009 01:13:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V8DrGm050310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <[e-mail]>; Fri, 31 Jul 2009 01:13:54 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n6V8DjRa020124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 31 Jul 2009 04:13:45 -0400 (EDT)
Date: Fri, 31 Jul 2009 04:13:44 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
cc: [e-mail], Ned Freed <[e-mail]>, MTA filtering mailing list <[e-mail]>, [e-mail]
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling 	Clarifications
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, July 31, 2009 09:09:23 AM +0100 Robert Burrell Donkin 
<[e-mail]> wrote:

> yes - that's been made clear  (a summary of those discussions would
> have been more useful than just a re-iteration)

I'm sure there will be a summary in the WG minutes, when they're done.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V89VqH049696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 31 Jul 2009 01:09:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6V89VBY049695; Fri, 31 Jul 2009 01:09:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V89Ohx049683 for <[e-mail]>; Fri, 31 Jul 2009 01:09:30 -0700 (MST) (envelope-from [e-mail])
Received: by bwz27 with SMTP id 27so1108005bwz.10 for <[e-mail]>; Fri, 31 Jul 2009 01:09:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oNBoZMjX8f8NxhUK8h7q/J4Zk/3ApSyJWe3JlNl/I3s=; b=K/MKVWw0dltgLwfRkL4Fe1iZ4uVQ5IPFqJueWQ/nq4eo5WSAgJT8Q2UBO/kZOI/zrd 4PMgGZZeYyZpmelMHSxh9BM+zyls+UnD55Bra8EGlH+bWVGkDgU1fV2Tkfw3rrEK1kFm 1d82vIrbOi8S+tkvW3Ys7mAFJ4m+dJcCR5lboDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=yFCa9qIMjWFANUL5L+jnXjCQXtY3MfoQ2F/HGErMEciZv2M8HL4shq1EPxqrgKme9R bWU1FGpIvXtLcW+T2ubFH4YTNcBwYGTt8qAfERDRozBpEHTZQqiQNGvtO6VcOCCaJFyl 77qTqGLGnfN7ZhKRIoToVbgtKAqlMmSIeskEMMIME-Version: 1.0
Received: by 10.204.102.14 with SMTP id e14mr2406177bko.183.1249027763564;  Fri, 31 Jul 2009 01:09:23 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 31 Jul 2009 09:09:23 +0100
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Robert Burrell Donkin <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: [e-mail], Ned Freed <[e-mail]>, MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, Jul 31, 2009 at 8:54 AM, Jeffrey Hutzelman<[e-mail]> wrote:
> --On Friday, July 31, 2009 07:58:35 AM +0100 Robert Burrell Donkin
> <[e-mail]> wrote:
>
>>
>> On Thu, Jul 30, 2009 at 6:39 PM, Barry
>> Leiba<[e-mail]> wrote:
>>>
>>> This whole issue may be moot, because we're likely significantly
>>> changing the way the name is specified, after discussion in Stockholm.
>>
>> i am disappointed to have missed some indication or warning posted
>> that the draft was undergoing extensive review and revision off list
>
> There was extensive discussion of this issue during the working group
> meeting this week.

yes - that's been made clear  (a summary of those discussions would
have been more useful than just a re-iteration)

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V7si3b048826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 31 Jul 2009 00:54:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6V7sifq048825; Fri, 31 Jul 2009 00:54:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V7sZ4q048795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <[e-mail]>; Fri, 31 Jul 2009 00:54:43 -0700 (MST) (envelope-from [e-mail])
Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n6V7sRsx017947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 31 Jul 2009 03:54:29 -0400 (EDT)
Date: Fri, 31 Jul 2009 03:54:27 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>, [e-mail]
cc: Ned Freed <[e-mail]>, MTA filtering mailing list <[e-mail]>, [e-mail]
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling 	Clarifications
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Friday, July 31, 2009 07:58:35 AM +0100 Robert Burrell Donkin 
<[e-mail]> wrote:

>
> On Thu, Jul 30, 2009 at 6:39 PM, Barry
> Leiba<[e-mail]> wrote:
>> This whole issue may be moot, because we're likely significantly
>> changing the way the name is specified, after discussion in Stockholm.
>
> i am disappointed to have missed some indication or warning posted
> that the draft was undergoing extensive review and revision off list

There was extensive discussion of this issue during the working group 
meeting this week.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V6wcd7045099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 23:58:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6V6wcJA045098; Thu, 30 Jul 2009 23:58:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6V6wa2i045079 for <[e-mail]>; Thu, 30 Jul 2009 23:58:37 -0700 (MST) (envelope-from [e-mail])
Received: by fxm7 with SMTP id 7so1181878fxm.10 for <[e-mail]>; Thu, 30 Jul 2009 23:58:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q4D+JUfO+gJ4uvschJdVHAoZcIp/DceD02No5XjQE9A=; b=Iafmg47cd05wUWggg8Q4Wi5SnT+dxJ91Bu9eW8CAxkVA8Pi3wQAQqRdJh5KC2NzZrR IewQ1CfcV2RLd/7+nkGpJjf4L2PbWDpyXfDqDmxITaX4VUmMNYlPpiG+1XNnyYC5ybeN KLvH706uQJ06MAqYoxj8uSld92XrlRqXWAZBoDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DPYzd436+MuAzQwxSMxPa2PXh6uz1RtSjk+r9U1u1Fol62S11tM8V4TRVrwyLJOcrK bO5HKfOVEIw1NZs1Ut3veWGnBG/CdwuAY0a7IUt3hfeOB9vAHXU90XOF792cypdO4j7E QGExl9T565jzXpUVGn99ab1B4kiDx30Lw94ioMIME-Version: 1.0
Received: by 10.204.67.80 with SMTP id q16mr2024588bki.116.1249023515347; Thu,  30 Jul 2009 23:58:35 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 31 Jul 2009 07:58:35 +0100
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Robert Burrell Donkin <[e-mail]>
To: [e-mail]
Cc: Ned Freed <[e-mail]>, MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Jul 30, 2009 at 6:39 PM, Barry
Leiba<[e-mail]> wrote:
> This whole issue may be moot, because we're likely significantly
> changing the way the name is specified, after discussion in Stockholm.

i am disappointed to have missed some indication or warning posted
that the draft was undergoing extensive review and revision off list

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHfE4S098292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 10:41:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UHfEFj098291; Thu, 30 Jul 2009 10:41:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHfDl3098282 for <[e-mail]>; Thu, 30 Jul 2009 10:41:13 -0700 (MST) (envelope-from [e-mail])
Received: by pxi30 with SMTP id 30so1035116pxi.16 for <[e-mail]>; Thu, 30 Jul 2009 10:41:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zBhXbpvn7rEPkun/dtUm35jNAzzjZvYdynAJffV65yo=; b=PBU4FFJOC5Nv/sSnAhtipm+2tXAM5MICbjX1FGKinKjPWn7HNUT1Dp6ZdZ/Z+JZ2yM 7xX/C4g4QH9Ok3ATHaVUKn30q+uvTw407oO1a/stufDX83g+PZf3ETdYZnIpNUoXu3ey yUfHZdyux2QSxu/TazeHv1YnKtsxAq3plWK+EDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=uumkFCqaaZvJvTrA+60lEszr+qgYiCgRV8EtKV3LNnMZAetaJzeBfmohNjMYRMbbA4 t/4zUvJcJsmCfj/QOqcj41MPa1S447l7Ua8KdowkP3LkkB2/r6dVH7kFcEJvNNenh4j7 4X4oJBXQHrRCTKZtZUmOZpu/cWHs0UZEEL1jgMIME-Version: 1.0
Received: by 10.114.136.7 with SMTP id j7mr2006666wad.30.1248975672853; Thu,  30 Jul 2009 10:41:12 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 30 Jul 2009 13:41:12 -0400
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 3. Security Considerations,  Paragraph 3
From: Barry Leiba <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Robert Burrell Donkin <[e-mail]>, MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This entire section has already been rewritten, but the version hasn't
been posted as an I-D yet.  Wait until the next version is out, and
re-review.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHdpTp098155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 10:39:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UHdpx6098154; Thu, 30 Jul 2009 10:39:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHdif4098144 for <[e-mail]>; Thu, 30 Jul 2009 10:39:50 -0700 (MST) (envelope-from [e-mail])
Received: by wa-out-1112.google.com with SMTP id n7so259721wag.26 for <[e-mail]>; Thu, 30 Jul 2009 10:39:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/2+P7TydFAiuilxCexXW/J7UXdedgfEkCO1goiGA/J8=; b=RQnQpE6gkjVYtCEEnqOMNTY0ASBM/3V21Do8Pi7ZD3YVEXz4JAdg2QcoqrHT06VEB/ VWL+9HtvwleGZNLWiLxpJ5gt5qK+XcxFTKQG5rfNwGyUDs6nyy7gPUy8NLHyPEaJY1YS d97kyK607j4kESPmu8koAJdjbDNBDAHRujC5IDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=n7DUabVTiLc9dn1aJNazTPF9xSstKxNnn0pd0TzEpazIEbe0z5khurckugCxHbouQk PNv+hywhIc45Y6A4ZeZeijDR0UERsm453oov57bFFiPCoOPHeUe4Z1uDXiiSk3Kz7lgJ i55ubVoO+IVvCWbRn5ZMuUFt/xc5q4n8W7vUsMIME-Version: 1.0
Received: by 10.114.112.14 with SMTP id k14mr1967651wac.139.1248975583534;  Thu, 30 Jul 2009 10:39:43 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 30 Jul 2009 13:39:43 -0400
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Barry Leiba <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Robert Burrell Donkin <[e-mail]>, MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This whole issue may be moot, because we're likely significantly
changing the way the name is specified, after discussion in Stockholm.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHaQqB097975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 10:36:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UHaQmO097974; Thu, 30 Jul 2009 10:36:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-pz0-f188.google.com (mail-pz0-f188.google.com [209.85.222.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UHaNjI097967 for <[e-mail]>; Thu, 30 Jul 2009 10:36:24 -0700 (MST) (envelope-from [e-mail])
Received: by pzk26 with SMTP id 26so1076987pzk.16 for <[e-mail]>; Thu, 30 Jul 2009 10:36:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZOmWZsrh/sXGUejhEjeWIkLGsKmtdRjGPRTkWdyE1Gc=; b=FPBMtqTbSpVkKVuHpx4tQIuoKy6BG5ImZe//RVfTK4wGOXRot2DvcbqJBT/Th7Ubtk cy+fL1YfnNoEpyvC496mGDTk8xTP/90QwMzzXZ/LOV/BVcV8ZJEO72lP9sNP1KEVVJca F6bU1i1w78fKypdEcarSw9WvTu8kUS8h0/l/cDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bû4gu/0U7t4EALL9TT0nrQeixk4+Dn6JVlooQTnUpuoHGHO6Pe9C+3+3zTP7tmbLri Kn2HIpeILl54hUZmDNH8RIxOEFw7Tnue1/r20J2iV9nxYmTywKVsLDrFaAnlphaMhVne YZR0TLEnGnpQbSGpyAhFlQk6qyGxiNcQ0RzLoMIME-Version: 1.0
Received: by 10.115.109.19 with SMTP id l19mr2001005wam.45.1248975383087; Thu,  30 Jul 2009 10:36:23 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 30 Jul 2009 13:36:23 -0400
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.2 Allow Extensions To Use  List
From: Barry Leiba <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Require implementations to raise a compile time error when list
> is used with an unsupported test.

That's already what happens when there are such errors in scripts.
Why should we say it explicitly here, and not everywhere else?

>    Implementations MAY support other tests but MUST raise a compile
>    time error when a script contains any standard test where support has
>    not been explicitly specified.

Not explicitly specified by whom?  How?

How does this make scripts portable?  This seems to encourage private
extensions, which has really become a thorn in the web.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UFulnL089586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 08:56:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UFulv4089585; Thu, 30 Jul 2009 08:56:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UFukTs089579 for <[e-mail]>; Thu, 30 Jul 2009 08:56:46 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 30 Jul 2009 08:56:45 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 30 Jul 2009 08:56:43 -0700 (PDT)
Date: Thu, 30 Jul 2009 08:47:44 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 3. Security Considerations, Paragraph 3
In-reply-to: "Your message dated Thu, 30 Jul 2009 13:44:39 +0100" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>    "Protocols/APIs used to retrieve/verify external list membership MUST
>    provide at least the same level of confidentiality as protocols/APIs
>    used to retrieve Sieve scripts.  For example, if Sieve scripts are
>    retrieved using LDAP secured with Transport Layer Security (TLS)
>    encryption, then the protocol used to retrieve external list
>    membership must use a comparable mechanism for providing connection
>    confidentiality.  In particular, the protocol used to retrieve
>    external list membership must not be lacking encryption."

> Use Case One: Public FOAF

> how does banning access to public resources improve security?

> Use Case Two: Web Services

> how should an implementation judge whether a web service discovered
> over UDDI (say) is more or less confidential than script storage in
> LDAP (say)?

Complete agreement on all points. There are going to be all kinds of external
lists where the degree of confidentiality provided is an intrinsic
characteristic of the list itself and  isn't under the control of the Sieve
implementation. There are also going to be cases where the Sieve
implementation is accessing the list through an intermediary and has no
way of determining what security, if any, is being employed in accessing
the list. 

Specific examples of the latter would be a list provided by an LDAP proxy
server or a list provided by an LDAP server where the underlying attributes are
virtual and are resolved through some form of callout. Such setups are quite
common in practice.

The entire notion of there being a confidentiality requirement for
external lists independent of the list in question is completely silly.
Let's change this to say that both list content as well as the query stream
against the list MAY be confidential in nature and appopriate security
measures MUST be employed when they are.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UF6UXJ085067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 08:06:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UF6UUO085066; Thu, 30 Jul 2009 08:06:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UF6Sdl085052 for <[e-mail]>; Thu, 30 Jul 2009 08:06:28 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 30 Jul 2009 08:06:26 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 30 Jul 2009 08:06:25 -0700 (PDT)
Date: Thu, 30 Jul 2009 08:05:54 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.2 Allow Extensions To Use List
In-reply-to: "Your message dated Thu, 30 Jul 2009 13:24:55 +0100" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This proposal seems OK to me.

				Ned

> Proposal - Clarify Expected Behaviour For Unsupported Tests
> =============================> Change
> ------
> Require implementations to raise a compile time error when list
> is used with an unsupported test.
> Rationale
> ---------
> Adopting a single clear rule on error handling increases interoperability.
> Requiring a compile time error seems cleaner than alternatives such as
> silently failing the test.

> Proposal - Allow Extension Tests To Use Link
> ======================
> Change
> ------
> Add explicit permission for implementations to support list for other
> tests.
> Rationale
> ---------
> Extensions which find "list" useful should be encouraged to use it
> as described.

> Use Case: Mailing List Local Test
> ---------------------------------
> if mailinglist :list "tag:example.org,2009-07-24:IEFT" {
>    fileinto "standards";
> }

> --------------------------------------------------------------------------
> [1] Proposal
> --------------------------------------------------------------------------

> 2.2.  :list match type

>    ABNF:

>       MATCH-TYPE  =/ ":list"
>            ; only valid for supported tests

>    The new ":list" match type changes the interpretation of the "key-
>    list" parameter to supported tests.  When the match type is ":list",
>    the key-list becomes a list of names of externally stored lists.
>    The external lists are queried, perhaps through a list-specific
>    mechanism, and the test evaluates to "true" if any of the specified
>    values matches any member of one or more of the lists.

>    Implementations MUST support "address", "envelope" and "header" tests.
>    Implementations MAY support other tests but MUST raise a compile
>    time error when a script contains any standard test where support has
>    not been explicitly specified.


> --------------------------------------------------------------------------
> [2] Original Text
> --------------------------------------------------------------------------

> 2.2.  :list match type for "address", "envelope", and "header" tests

>    ABNF:

>       MATCH-TYPE  =/ ":list"
>            ; only valid for "address", "envelope", and "header" tests

>    The new ":list" match type changes the interpretation of the "key-
>    list" parameter to the "address"/"envelope"/"header" test.  When the
>    match type is ":list", the key-list becomes a list of names of
>    externally stored lists.  The external lists are queried, perhaps
>    through a list-specific mechanism, and the test evaluates to "true"
>    if any of the specified values matches any member of one or more of
>    the lists.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UF4lBa084900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 08:04:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UF4lvn084899; Thu, 30 Jul 2009 08:04:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UF4XtO084885 for <[e-mail]>; Thu, 30 Jul 2009 08:04:44 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 30 Jul 2009 08:04:32 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 30 Jul 2009 08:04:30 -0700 (PDT)
Date: Thu, 30 Jul 2009 07:51:37 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling Clarifications
In-reply-to: "Your message dated Thu, 30 Jul 2009 13:18:52 +0100" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Proposal: Separate Section For Discussion of TAG
> ========================> Changes
> -------
> Split first paragraph into sections.
> Rationale
> ---------
> Clarity

> Proposal: Clarify Expected Error Handling Behaviour
> =========================> Changes
> -------
> Specify that unsupported URI schemas are compile time
> errors and that resolution failures are runtime errors.

While I agree it's a good idea to report errors at as early a phase as
possible, unless we're willing to specify that variable substitutions cannot be 
used in list names, this can at most be a SHOULD, not a MUST.

> Rationale
> ---------
> Practical implementations will not be able to support
> all feasible URI schemes, protocols, discovery mechanisms
> and resource semantics.

> Any URI schema which is not supported by the engine
> will never be resolved. In this case, it is clearer and
> cleaner to fail at compile time. Note that this case
> also includes malformed URIs.

> Resources may be dynamic. A resource whose semantics
> could not be understood at compile time may have been
> replaced by one that could be at runtime. Resource
> resolution may be dynamic: a resource which could not
> be resolved at compile time may be resolvable at
> runtime. Services may be dynamic. A service with
> suitable semantics may become available at runtime
> which was not at compile time. Conversely,
> resources, resource resolution and service discovery
> may fail at runtime after it succeeded at compile
> time.

> So, failures to resolve, locate or parse a resource
> referred to by the script should only be raised at
> runtime.

Agreed, however, it isn't clear to me that throwing an error is the right
thing to do when a given list resource is unavailable. Handling the
unavailability of a given resource is well within the purview of a properly
constructed portable script, I should think.

> Proposal: Require Implementations To Support [TAG-URI]
> ===========================
> Changes
> -------
> Require that all implementations support tag, plus any other
> URI schemes of their choice.
> Rationale
> ---------
> Insisting that implementations support at least one protocol
> sets a minimum level for script portability. Picking one
> particular web protocol such as LDAP, HTTP or FTP would impose
> a unnecessary burden on implementations and
> unnecessarily involve the specification in the semantics of
> engine-list server interactions.

> A credible alternative choice would be relative URIs.

It's unclear what "support" means in this context. In our implementtation list
URIs are parsed and then passed to what amounts to a callout. We can of course
make it so tag: is always a legal URL type when that check is done, but we
cannot force tag: to work.

> --------------------------------------------------------------------------
> [1] Proposal
> --------------------------------------------------------------------------

> 2.4.  Syntax of an externally stored list name

>    A name of an externally stored list is always an absolute URI [URI].
>    Implementations might find URLs such as [LDAP], [CardDAV], or
>    [TAG-URI] to be useful for naming external lists.

>    Implementations MUST raise a compile time error when a list name
>    cannot be parsed into a URI scheme supported by the implementation.

See above. This needs to be a SHOULD.

>    Resolution of the resource MAY involve resource location and service
>    discovery. Resources MAY change dynamically. Resolution of the
>    resource MUST be perform at script execution time. When the resource
>    cannot be located or the resource type is found to be unsupported
>    then the implementation MUST raise a runtime error.

If we're going to throw an error like this in a  test I think we need a way to
test and see if the resource is available.

>    Implementations MAY attempt to resolve the URI at compile time but
>    MUST NOT raise a compile time error on failure.

> 2.4.1 The Tag Scheme
>    The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
>    user friendlier identifiers.

>    Resolution of such identifiers is going to be implementation specific
>    and it can help in hiding the complexity of an implementation from
>    end users.  For example, an implementation can provide a web interface
>    for managing lists of users stored in LDAP.  Requiring users to know
>    generic LDAP URL syntax might not be very practical, due to its
>    complexity.  An implementation can instead use a fixed tag URI prefix
>    such as "tag:example.com,<date>:" (where <date> can be, for example,
>    a date generated once on installation of the web interface and left
>    untouched upon upgrades) and the prefix doesn't even need to be shown
>    to end users.

>    Implementations MUST support the [TAG-URI] URI scheme.

I think some elaboration on what "support" means would be good here.

> 2.4.2 Other URI Schemes

>    Implementations MAY support other URI schemes.


				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UD9tRm075816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 06:09:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UD9tQ4075815; Thu, 30 Jul 2009 06:09:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (daboo.name [151.201.22.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UD9sH2075806 for <[e-mail]>; Thu, 30 Jul 2009 06:09:54 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 89A1F1767E08 for <[e-mail]>; Thu, 30 Jul 2009 09:09:53 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdnCspnT3OYY for <[e-mail]>; Thu, 30 Jul 2009 09:09:53 -0400 (EDT)
Received: from dhcp-10ae.meeting.ietf.org (dhcp-10ae.meeting.ietf.org [130.129.16.174]) by daboo.name (Postfix) with ESMTP id 922CF1767DFD for <[e-mail]>; Thu, 30 Jul 2009 09:09:52 -0400 (EDT)
Date: Thu, 30 Jul 2009 15:09:48 +0200
From: Cyrus Daboo <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Subject: Working Group Last Call for draft-freed-sieve-notary-05
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size96
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
We are starting a two week last call on draft-freed-sieve-notary-05. We've 
had a last call on this document before but some new "deliverby" features 
have been added since then, so we need adequate review of those from the WG 
before we can hand this off to the IESG.

So the last call starts today and will complete on August 13th.

Please send comments to the list.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UCr8RS074355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 05:53:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UCr8HH074354; Thu, 30 Jul 2009 05:53:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UCqwbY074341 for <[e-mail]>; Thu, 30 Jul 2009 05:53:07 -0700 (MST) (envelope-from [e-mail])
Received: by bwz27 with SMTP id 27so598482bwz.10 for <[e-mail]>; Thu, 30 Jul 2009 05:52:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=ivy35eFu9dLK2Gz9h/csdnapV3hj0pMSIx3AW+XLot8=; b=hQCcjIGKgcObJy0hrlCB+nr7CcEaiIkvEsyqKIn6qxKa7+uAXTBx6URuhuEYiv9Y8C +DvQXatVtOeRv+HB9Bt68J+pFbCanEuYj1/L6aDuf/FLGB0Ds4S6cncfo5733OR/FqA+ YNfz4znsltp3o4w/NSRNK/+iSZy/ODe53+Q6IDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=NLXijBr28e5YWHkQWGg+XGvynZYfYG0/CgwdSXBH0nNNUiJ1yq/ph3VCatE99MFBMJ ilp2sTruCPTUnhxHRKaMGwW+Bx04+ZWhi+w8rG/qeGVzXXoCtQpXOxi0WBmRPH/hyxmQ LE9r+v8UM5xcnsZ7SQx8JGZHlV0ZLVERj6bRsMIME-Version: 1.0
Received: by 10.204.102.14 with SMTP id e14mr1117237bko.183.1248958377799;  Thu, 30 Jul 2009 05:52:57 -0700 (PDT)
Date: Thu, 30 Jul 2009 13:52:57 +0100
Message-ID: <[e-mail]>
Subject: [draft-melnikov-sieve-external-lists] 3. Security Considerations,  Paragraph 2
From: Robert Burrell Donkin <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<blockquote cite='http://www.ietf.org/id/draft-ietf-sieve-external-lists-00.txt'>
   A failure to retrieve data due to the server storing the external
   list membership being down or otherwise inaccessible may alter the
   result of Sieve processing.  So implementations SHOULD treat a
   temporary failure to retrieve or verify external list membership in
   the same manner as a temporary failure to retrieve a Sieve script.
   For example, if the Sieve script is stored in the Lightweight
   Directory Access Protocol (LDAP) and the script can't be retrieved
   when a message is processed, then the agent performing Sieve
   processing can, for example, assume that the script doesn't exist or
   delay message delivery until the script can be retrieved
   successfully.  External list memberships should be treated as if they
   are a part of the script itself, so a temporary failure to retrieve
   them should be handled in the same way as a temporary failure to
   retrieve the Sieve script itself.
</blockquote>

how does this error handling behaviour improve security?

what are the advantages of this new error handling language to that
already established in RFC 5228?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UCigvS073455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 05:44:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UCig8e073452; Thu, 30 Jul 2009 05:44:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f221.google.com (mail-fx0-f221.google.com [209.85.220.221]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UCieDD073420 for <[e-mail]>; Thu, 30 Jul 2009 05:44:41 -0700 (MST) (envelope-from [e-mail])
Received: by fxm21 with SMTP id 21so612056fxm.27 for <[e-mail]>; Thu, 30 Jul 2009 05:44:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=+Ra5ofht3XVQzewFckfXWeDv98d8AV9Xde4s8aU5cNk=; b=CNTgNiO18X940NtOIje7PEqqVhg/2fQ8Xgvm6RBsr53QuVO9UuYGjC/gPAVyHKiGxL NXu9VfYSDRjKqES1m5JFL49ESLqG+Ak+bUuMwn8FEYmcQBfsVLuSmFW9dN/miZkggrSb jNkaqaG0rNL+7UDdbBVDUogfxjzFxSvrGIMvUDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=xsB9+QqAX9rZ2UqVZ+R3eZ6Oa13vJWhor4iisuuNS88hp7WeZBq5oc3bUMUAkoiRHC 47uilyVTH6WFSDO3Jz+PY6q+wLrz7vG88+WRu13RCrFyEn1DoaFl752ePx5AWm5B32Rm td6fnABKnUE+n0+fsVkExx7g61Qj82wnGLbiQMIME-Version: 1.0
Received: by 10.204.102.14 with SMTP id e14mr1108554bko.183.1248957879380;  Thu, 30 Jul 2009 05:44:39 -0700 (PDT)
Date: Thu, 30 Jul 2009 13:44:39 +0100
Message-ID: <[e-mail]>
Subject: [draft-melnikov-sieve-external-lists] 3. Security Considerations,  Paragraph 3
From: Robert Burrell Donkin <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

   "Protocols/APIs used to retrieve/verify external list membership MUST
   provide at least the same level of confidentiality as protocols/APIs
   used to retrieve Sieve scripts.  For example, if Sieve scripts are
   retrieved using LDAP secured with Transport Layer Security (TLS)
   encryption, then the protocol used to retrieve external list
   membership must use a comparable mechanism for providing connection
   confidentiality.  In particular, the protocol used to retrieve
   external list membership must not be lacking encryption."

Use Case One: Public FOAF

how does banning access to public resources improve security?

Use Case Two: Web Services

how should an implementation judge whether a web service discovered
over UDDI (say) is more or less confidential than script storage in
LDAP (say)?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UCOwYo072104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 05:24:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UCOwPo072103; Thu, 30 Jul 2009 05:24:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f221.google.com (mail-fx0-f221.google.com [209.85.220.221]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UCOuxF072093 for <[e-mail]>; Thu, 30 Jul 2009 05:24:57 -0700 (MST) (envelope-from [e-mail])
Received: by fxm21 with SMTP id 21so600448fxm.27 for <[e-mail]>; Thu, 30 Jul 2009 05:24:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=pRRCaYeS5aThfSdlq8kBZBE2jmeAHQeEn+o4qhSOjWU=; b=mJYXiWyRjetAvqSRVLI/vdImElSZoGllo7wn8LWm0mNR1HEZLaXiWcESOMRCIDZwYY zUHGzaUP1s0p1Yk4/BFxycuDePOAfmnHNy0HzrCU9I5kVV06BLps0VBocnJM4VYdZ4E0 THIrS0ihia4QzAVpjVGfAMYNCl7e0V1AOQNYUDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=XoDOtJFFpgLkwNSfdtoHsKPbvR7YkwTUDJ2ImTiXv4tTn1CTUBNEtspwLoHQ1xf+KI t3V2yuOk+C+zMESx0pDy95Xgkm2kQ/mgWD6CpnVtMMCodO1Gqwrko2l0y3/0gNsqMypQ 1JJuQOzS6US9WNgZhyuxLPbS9gJWw77Y9m7xsMIME-Version: 1.0
Received: by 10.204.118.12 with SMTP id t12mr1097653bkq.158.1248956695051;  Thu, 30 Jul 2009 05:24:55 -0700 (PDT)
Date: Thu, 30 Jul 2009 13:24:55 +0100
Message-ID: <[e-mail]>
Subject: [draft-melnikov-sieve-external-lists] 2.2 Allow Extensions To Use  List
From: Robert Burrell Donkin <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Proposal - Clarify Expected Behaviour For Unsupported Tests
=============================Change
------
Require implementations to raise a compile time error when list
is used with an unsupported test.
Rationale
---------
Adopting a single clear rule on error handling increases interoperability.
Requiring a compile time error seems cleaner than alternatives such as
silently failing the test.

Proposal - Allow Extension Tests To Use Link
======================
Change
------
Add explicit permission for implementations to support list for other
tests.
Rationale
---------
Extensions which find "list" useful should be encouraged to use it
as described.

Use Case: Mailing List Local Test
---------------------------------
if mailinglist :list "tag:example.org,2009-07-24:IEFT" {
   fileinto "standards";
}

--------------------------------------------------------------------------
[1] Proposal
--------------------------------------------------------------------------

2.2.  :list match type

   ABNF:

      MATCH-TYPE  =/ ":list"
           ; only valid for supported tests

   The new ":list" match type changes the interpretation of the "key-
   list" parameter to supported tests.  When the match type is ":list",
   the key-list becomes a list of names of externally stored lists.
   The external lists are queried, perhaps through a list-specific
   mechanism, and the test evaluates to "true" if any of the specified
   values matches any member of one or more of the lists.

   Implementations MUST support "address", "envelope" and "header" tests.
   Implementations MAY support other tests but MUST raise a compile
   time error when a script contains any standard test where support has
   not been explicitly specified.


--------------------------------------------------------------------------
[2] Original Text
--------------------------------------------------------------------------

2.2.  :list match type for "address", "envelope", and "header" tests

   ABNF:

      MATCH-TYPE  =/ ":list"
           ; only valid for "address", "envelope", and "header" tests

   The new ":list" match type changes the interpretation of the "key-
   list" parameter to the "address"/"envelope"/"header" test.  When the
   match type is ":list", the key-list becomes a list of names of
   externally stored lists.  The external lists are queried, perhaps
   through a list-specific mechanism, and the test evaluates to "true"
   if any of the specified values matches any member of one or more of
   the lists.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UCJ466071642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 05:19:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UCJ4vR071641; Thu, 30 Jul 2009 05:19:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UCIs66071622 for <[e-mail]>; Thu, 30 Jul 2009 05:19:03 -0700 (MST) (envelope-from [e-mail])
Received: by fxm23 with SMTP id 23so1360868fxm.6 for <[e-mail]>; Thu, 30 Jul 2009 05:18:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=FYHrTSpoO0R6eo1vuMjo6cepohW/57xCXOBg6JhWuYE=; b=DVjfXOWIN2UmvZBpk8dS7dfAydjqnivlPg/QV2ppoBwZhzUhCaaB57km+IEnbpnHBu TSBJTROpaZzVn/HLR3JUu9yRAMuYnE75azFgsUKaDpuImVndf/wQheijbYW1MYXLdEqH Gh05rD9DCcaURUfb+Hii5u8abDtwMumrnsO6YDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=agynpAp/b9MxLZT9KanelvpRVfcDK22jvgm2c/DRYQAH0lHsnBiNNnVmQ1IdjbHHS7 VlxCGjOc0GRQYGSL26/phHypq3MSPhbT09jdVDKgU/u5DQ4qiINKYxfL+mP80MX1uG/N KVPhitHmgRbMpSEO2ZhlIzBsRRTK4BvmJjY+QMIME-Version: 1.0
Received: by 10.204.114.194 with SMTP id f2mr1129157bkq.17.1248956332858; Thu,  30 Jul 2009 05:18:52 -0700 (PDT)
Date: Thu, 30 Jul 2009 13:18:52 +0100
Message-ID: <[e-mail]>
Subject: [draft-melnikov-sieve-external-lists] 2.4 Proposed Error Handling  Clarifications
From: Robert Burrell Donkin <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Proposal: Separate Section For Discussion of TAG
========================Changes
-------
Split first paragraph into sections.
Rationale
---------
Clarity

Proposal: Clarify Expected Error Handling Behaviour
=========================Changes
-------
Specify that unsupported URI schemas are compile time
errors and that resolution failures are runtime errors.
Rationale
---------
Practical implementations will not be able to support
all feasible URI schemes, protocols, discovery mechanisms
and resource semantics.

Any URI schema which is not supported by the engine
will never be resolved. In this case, it is clearer and
cleaner to fail at compile time. Note that this case
also includes malformed URIs.

Resources may be dynamic. A resource whose semantics
could not be understood at compile time may have been
replaced by one that could be at runtime. Resource
resolution may be dynamic: a resource which could not
be resolved at compile time may be resolvable at
runtime. Services may be dynamic. A service with
suitable semantics may become available at runtime
which was not at compile time. Conversely,
resources, resource resolution and service discovery
may fail at runtime after it succeeded at compile
time.

So, failures to resolve, locate or parse a resource
referred to by the script should only be raised at
runtime.

Proposal: Require Implementations To Support [TAG-URI]
===========================
Changes
-------
Require that all implementations support tag, plus any other
URI schemes of their choice.
Rationale
---------
Insisting that implementations support at least one protocol
sets a minimum level for script portability. Picking one
particular web protocol such as LDAP, HTTP or FTP would impose
a unnecessary burden on implementations and
unnecessarily involve the specification in the semantics of
engine-list server interactions.

A credible alternative choice would be relative URIs.


--------------------------------------------------------------------------
[1] Proposal
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list is always an absolute URI [URI].
   Implementations might find URLs such as [LDAP], [CardDAV], or
   [TAG-URI] to be useful for naming external lists.

   Implementations MUST raise a compile time error when a list name
   cannot be parsed into a URI scheme supported by the implementation.

   Resolution of the resource MAY involve resource location and service
   discovery. Resources MAY change dynamically. Resolution of the
   resource MUST be perform at script execution time. When the resource
   cannot be located or the resource type is found to be unsupported
   then the implementation MUST raise a runtime error.

   Implementations MAY attempt to resolve the URI at compile time but
   MUST NOT raise a compile time error on failure.

2.4.1 The Tag Scheme
   The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
   user friendlier identifiers.

   Resolution of such identifiers is going to be implementation specific
   and it can help in hiding the complexity of an implementation from
   end users.  For example, an implementation can provide a web interface
   for managing lists of users stored in LDAP.  Requiring users to know
   generic LDAP URL syntax might not be very practical, due to its
   complexity.  An implementation can instead use a fixed tag URI prefix
   such as "tag:example.com,<date>:" (where <date> can be, for example,
   a date generated once on installation of the web interface and left
   untouched upon upgrades) and the prefix doesn't even need to be shown
   to end users.

   Implementations MUST support the [TAG-URI] URI scheme.

2.4.2 Other URI Schemes

   Implementations MAY support other URI schemes.

--------------------------------------------------------------------------
[2] Original Text
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list is always an absolute URI [URI].
   Implementations might find URLs such as [LDAP], [CardDAV], or
   [TAG-URI] to be useful for naming external lists.
   The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
   user friendlier identifiers.  Resolution of such identifiers is going
   to be implementation specific and it can help in hiding the
   complexity of an implementation from end users.  For example, an
   implementation can provide a web interface for managing lists of
   users stored in LDAP.  Requiring users to know generic LDAP URL
   syntax might not be very practical, due to its complexity.  An
   implementation can instead use a fixed tag URI prefix such as "tag:
   example.com,<date>:" (where <date> can be, for example, a date
   generated once on installation of the web interface and left
   untouched upon upgrades) and the prefix doesn't even need to be shown
   to end users.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UAWBnj049961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 03:32:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UAWBOF049960; Thu, 30 Jul 2009 03:32:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f221.google.com (mail-fx0-f221.google.com [209.85.220.221]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UAW9lG049949 for <[e-mail]>; Thu, 30 Jul 2009 03:32:10 -0700 (MST) (envelope-from [e-mail])
Received: by fxm21 with SMTP id 21so537213fxm.27 for <[e-mail]>; Thu, 30 Jul 2009 03:32:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bhNPGpa7PE9gGO+HomFaIj8O5i7PGEoTMF/pX0POjAGY=; b=G/oMQJ8fp9KZgvhsELweIbJHOvDbBbT5nFAph+v6pImZGdE2zobMTl330gke4XSTw6 ThMYa6LCsry5a00s+V8cs9TKeRjNEN6QnLnBfv1cBOI9muSASBzYgkeM/FRYTtvdqKDa h0D84zxN/3+IsW0piP5w2v89wCdpO9CYrtBo0DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aTyE+I9FOYPCFzHsf6WUmkw66fWFxoyrvuWajBhUPj7QUku98aLWRY1RzX1QN/r9wf JpD8p8FnGSo1rX49Rt0p3DRKrQMu8Gkvu3uKV39f8EeqlIk9R5Jalr6d+Ban0DF6QVCo V11uaeEvDgKTD8OWolGaFT3mWKVGTlxouxqxAMIME-Version: 1.0
Received: by 10.204.50.195 with SMTP id a3mr1005960bkg.94.1248949928877; Thu,  30 Jul 2009 03:32:08 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 30 Jul 2009 11:32:08 +0100
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To  Section 2.4
From: Robert Burrell Donkin <[e-mail]>
To: [e-mail]
Cc: Aaron Stone <[e-mail]>, MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 28, 2009 at 8:39 AM, Barry
Leiba<[e-mail]> wrote:

<snip>

>  I'll also point out that in most cases (us geeks
> notwithstanding), the script will be generated under the covers.  So
> the user might, indeed, just type "MyList", and the icky-looking URI
> would be filled in for her.

how might such a generator discover how to map "MyList" to
"tag:MyList" (say) in an interoperable fashion?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UAO34P049294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 03:24:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UAO3F3049293; Thu, 30 Jul 2009 03:24:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f221.google.com (mail-fx0-f221.google.com [209.85.220.221]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UAO1Ie049286 for <[e-mail]>; Thu, 30 Jul 2009 03:24:02 -0700 (MST) (envelope-from [e-mail])
Received: by fxm21 with SMTP id 21so533236fxm.27 for <[e-mail]>; Thu, 30 Jul 2009 03:24:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x0X6ALq2TLmDfm9GgnASz6JZHUQqMTIX9MO+cA44GG0=; b=myOBo1srS0ND/9OVVsST7VIN6nce9dAvpaUI9NQRpD9tnOopkWwyIZSfE7yCa7rcCZ LCS6YPlwIKAYsi53kfYel+fDQuf2i0ZazxfsFURhbht2iexuli2iZSJi9T+b9fumF53K 8p4FQzRcCyl+WxG5GwLyzkbPORK3FCv+pCVskDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aXIgeXD552Zo90qjqAAeY7VcATEEA3aQ5hLonNi4NLYvCCuAAdvnqoupxZjLtvqZOi WwU0RWfESarwnvWm4Fc/CG32gaFYZI0BgmVKlv99lM2gNAPnLvZ1rC9duR3Weoa2Z8Fy 7dq5up9FdPp65tIIc1AmCLkRr56rDTz4BQjrwMIME-Version: 1.0
Received: by 10.204.102.14 with SMTP id e14mr963576bko.183.1248949440873; Thu,  30 Jul 2009 03:24:00 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 30 Jul 2009 11:24:00 +0100
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To  Section 2.4
From: Robert Burrell Donkin <[e-mail]>
To: [e-mail]
Cc: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, Jul 25, 2009 at 7:23 PM, Barry
Leiba<[e-mail]> wrote:
>> Use relative URIs to represent resources managed transparently by the
>> Sieve Engine.
>
> This was my thought as well, when Alexey first brought the idea up.
> Originally, the idea was that the list name was just a string,
> understood by the Sieve processor.  It quickly became clear that that
> was problematic, and we should go with URIs.  Some thought they should
> always be absolute, and I thought relative ones should be allowed.  We
> batted that around for some while, and settled on absolute.
>
> Apart from the reason you mention -- that it can be confusing -- the
> main argument against using relative URIs is the difficulty in clearly
> (and interoperably) defining what the relative ones mean.  Saying that
> the Sieve processor understands what they mean ignores the real
> problem with making sure the user (and/or the client) also understands
> it.
>
> I think we should stay with absolute URIs.

the location and interpretation of resources with arbitrary semantics
across arbitrary protocols is - i think - too difficult a problem to
be tackle by this draft. therefore, we should be satisfied now just by
specifying what we can and leaving these difficult interoperability
problems to other expert groups.

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UADhnk048670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 30 Jul 2009 03:13:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6UADhnc048669; Thu, 30 Jul 2009 03:13:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f221.google.com (mail-fx0-f221.google.com [209.85.220.221]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6UADVaT048628 for <[e-mail]>; Thu, 30 Jul 2009 03:13:42 -0700 (MST) (envelope-from [e-mail])
Received: by fxm21 with SMTP id 21so528173fxm.27 for <[e-mail]>; Thu, 30 Jul 2009 03:13:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh·WozqQnfkHW/2HYO/xsECd62iwkHTSlXaeLoAUtH+A=; b=pGPXuK3K7T+UXkMrwea5FfcLj08ADy5Z4CE6kS8NfreIUlBh/L55ppB43tLZvkTJIZ VkarF+DlkkZ9x7YJZcqVrB8rfTH6wrwApwKCSlyMNPwdipQr0/1tri2UMN4I1qm3Kop4 6Ws5f+yXWzpTS+SGhyOZ52oeJuCO86pao0TvsDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Nm5qKAEEZ6Gt7y6oGHF0YR2hBidlBRHiJoC3kcJrpcrSJP5xGD5PDOoOC4qYETflkx ZkuuQB3igL1kiUxuWsZDzUmVoiXnmvuNundOoSV8nVu9ikfPMQs2wq/uqLJK2oNDoPIx uhAN7ecC6zLi04l6/JGPp5lN/lIAX7fHgkYD0MIME-Version: 1.0
Received: by 10.204.54.198 with SMTP id r6mr945668bkg.191.1248948811070; Thu,  30 Jul 2009 03:13:31 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 30 Jul 2009 11:13:31 +0100
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To  Section 2.4
From: Robert Burrell Donkin <[e-mail]>
To: [e-mail]
Cc: Aaron Stone <[e-mail]>, MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Jul 28, 2009 at 8:39 AM, Barry
Leiba<[e-mail]> wrote:
>> [As IC:]

<snip>

>> I do like the idea of just writing ':list "MyList"' and not needed much
>> else. It does seem a bit overkill to be typing my own email address into
>> the Sieve script for the very same account.
>
> I like the idea also, but I see the problems in interpreting it,

what difficulties do you see?

> especially as one tries to move scripts form one implementation to
> another.

could you explain when - given a server instance capable of supporting
at least two sieve implementations and with access to resources mapped
by a relative URL - moving a script from one implementation to another
should create special difficulties?

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TN0Eie004265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 29 Jul 2009 16:00:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6TN0EHq004264; Wed, 29 Jul 2009 16:00:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6TN04Dx004252 for <[e-mail]>; Wed, 29 Jul 2009 16:00:14 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id CBC2E3A6E9C; Wed, 29 Jul 2009 16:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-include-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Wed, 29 Jul 2009 16:00:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.


	Title           : Sieve Email Filtering: Include Extension
	Author(s)       : C. Daboo, A. Stone
	Filename        : draft-ietf-sieve-include-03.txt
	Pages           : 14
	Date            : 2009-07-29

The Sieve Email Filtering "include" extension permits users to
include one Sieve script inside another.  This can make managing
large scripts or multiple sets of scripts much easier, and allows a
site and its users to build up libraries of scripts.  Users are able
to include their own personal scripts or site-wide scripts.

Change History (to be removed prior to publication as an RFC)

Changes from ietf-02 to ietf-03:

a.  Setting a variable then calling global on it is an error

 (something like 'use strict').

b.  Specify that the 'global' keyword is only available when

 'variables' has also been required.

c.  Uploading a script that includes a nonexistent script is not an

 error at upload time.

Changes from ietf-01 to ietf-02:

a.  Require that script names must be constant strings, not subject

 to variable expansion.

b.  Try the phrase immediate script instead of current script.

c.  Clarify that "global 'varname'" and "global.varname" refer to the

 same variable.

d.  Drop the requirement the global keywords come after require and

 before anything else.

Changes from ietf-00 to ietf-01:

a.  Replaced import/export with global.

b.  Added :once modifier to include.

c.  Added global namespace to see if it holds water.

Changes from daboo-06 to ietf-00:
a.  None

Changes from -05 to -06:

a.  Aaron Stone joins as author.

b.  Removed | characters from the script examples.

c.  Updated draft references to published RFCs.

Changes from -04 to -05:

a.  Fixed examples.

b.  Relaxed requirement that imported/exported variables be set

 before being used.

Changes from -03 to -04:

a.  Fixed missing 2119 definitions.

b.  Defined interaction with variables through use of import and

 export commands.

Changes from -02 to -03:

a.  Refreshing expired draft (updated for nits).

b.  Syntax -> Usage.

c.  Updated to 3028bis reference.

Changes from -01 to -02:

a.  Minor formatting changes only - refreshing expired draft.

Changes from -00 to -01:

a.  Added IPR boiler plate.

b.  Re-ordered sections at start to conform to RFC style.

c.  Moved recursion comment into General Considerations section.

d.  Switched to using optional parameter to indicate personal vs

 global.
e.  Explicitly state that an error occurs when a missing script is

 included.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-include-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sieve-include-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SE04Mr055361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 28 Jul 2009 07:00:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6SE04Qh055360; Tue, 28 Jul 2009 07:00:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6SE046D055354 for <[e-mail]>; Tue, 28 Jul 2009 07:00:04 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 0DE0D3A6CE1; Tue, 28 Jul 2009 07:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-external-lists-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue, 28 Jul 2009 07:00:02 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.


	Title           : Sieve Extension: Externally Stored Lists
	Author(s)       : A. Melnikov
	Filename        : draft-ietf-sieve-external-lists-00.txt
	Pages           : 7
	Date            : 2009-07-05

Sieve scripting language can be used for implementing of
whitelisting, blacklisting and personal distribution lists.
Currently this requires that all members of such lists be hardcoded
in the script itself.  Whenever a member of such list is added or
deleted, the script needs to be updated and possibly uploaded to a
mail server.

This document defines a Sieve extension for accessing externally
stored mailing lists, i.e. list whose members are stored externally
to the script, for example in LDAP (RFC 4510), ACAP (RFC 2244) or a
relational database.

ToDo

o  Need a way to advertise supported URI schemas in ManageSieve and

ihave.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-external-lists-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sieve-external-lists-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6S7dDGu025503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 28 Jul 2009 00:39:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6S7dCD5025502; Tue, 28 Jul 2009 00:39:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6S7d0XE025488 for <[e-mail]>; Tue, 28 Jul 2009 00:39:11 -0700 (MST) (envelope-from [e-mail])
Received: by wa-out-1112.google.com with SMTP id n7so598339wag.26 for <[e-mail]>; Tue, 28 Jul 2009 00:39:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3OgawDgOjlin+YVuFoqlzeDv7+fgJpLdXC+e1x/yas0=; b=RxSmo3m5lvr/CXIi24CLoKZqj3eVCsGjM6C50MY5Jb0fMwW8rWuPplq+I2ExD477eu vRt2KhkVy8oM4uFoTyMeKec9ggzflOuSHw3DK4bz08alt0KRUhPZjoHGY5GJw2QwFaBs F2t5GMqebQb5G7i5ikECJ/9Ogcu4u3me3KkxcDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=JCn7PMP55kughWZeLe99SJcwjV0YTx6hVd1cRV3T/WvWqgPNyXl+eVdL0I8rKfB38S H44eVdlwQz7yK+a9INMKGIGb+pI571dTOXVLbv6UMuEYgvEPpickzXTGnxvTvyKq1Blf ASyN0fxKDbngQUEe1uw6/zLodGpVtYaHumjSoMIME-Version: 1.0
Received: by 10.114.102.20 with SMTP id z20mr11685950wab.175.1248766740503;  Tue, 28 Jul 2009 00:39:00 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 28 Jul 2009 03:39:00 -0400
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To  Section 2.4
From: Barry Leiba <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Robert Burrell Donkin <[e-mail]>, MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> [As IC:]

"IC"?

> Personally, I'm concerned about potential ugliness of the identifiers if a
> UI thinks it's hidden, but that's kind of an omnipresent issue around here.

Sorry; I can't make sense of that.  Try rephrasing?

> I do like the idea of just writing ':list "MyList"' and not needed much
> else. It does seem a bit overkill to be typing my own email address into
> the Sieve script for the very same account.

I like the idea also, but I see the problems in interpreting it,
especially as one tries to move scripts form one implementation to
another.  I'll also point out that in most cases (us geeks
notwithstanding), the script will be generated under the covers.  So
the user might, indeed, just type "MyList", and the icky-looking URI
would be filled in for her.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6S01ICR098869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 27 Jul 2009 17:01:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6S01Ir0098868; Mon, 27 Jul 2009 17:01:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (75-101-96-32.dsl.static.sonic.net [75.101.96.32] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6S01HSG098862 for <[e-mail]>; Mon, 27 Jul 2009 17:01:18 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.cx (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with ESMTP id EBC8C16CE; Mon, 27 Jul 2009 17:01:26 -0700 (PDT)
MIME-Version: 1.0
Date: Mon, 27 Jul 2009 17:01:26 -0700
From: Aaron Stone <[e-mail]>
To: <[e-mail]>, Robert Burrell Donkin <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To =?UTF-8?Q?	Section 2.4?In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
X-Sender: [e-mail]
User-Agent: RoundCube Webmail/0.2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 27 Jul 2009 16:07:36 -0700, Aaron Stone <[e-mail]>
wrote:
> On Sat, 25 Jul 2009 14:23:29 -0400, Barry Leiba
> <[e-mail]> wrote:
>>> Use relative URIs to represent resources managed transparently by the
>>> Sieve Engine.
>> 
>> This was my thought as well, when Alexey first brought the idea up.
>> Originally, the idea was that the list name was just a string,
>> understood by the Sieve processor.  It quickly became clear that that
>> was problematic, and we should go with URIs.  Some thought they should
>> always be absolute, and I thought relative ones should be allowed.  We
>> batted that around for some while, and settled on absolute.
>> 
>> Apart from the reason you mention -- that it can be confusing -- the
>> main argument against using relative URIs is the difficulty in clearly
>> (and interoperably) defining what the relative ones mean.  Saying that
>> the Sieve processor understands what they mean ignores the real
>> problem with making sure the user (and/or the client) also understands
>> it.
>> 
>> I think we should stay with absolute URIs.
> 
> [As IC:]
> 
> With the tag: URI scheme, you do get the effect of a server-specific URI,
> and with a clear indication that that's what you're looking at (since it
> begins literally with "tag:"). Does that address the concerns here?

[Still an IC:]

Sorry, I didn't read the original comment and text. Of course this is
exactly what's at issue.

Personally, I'm concerned about potential ugliness of the identifiers if a
UI thinks it's hidden, but that's kind of an omnipresent issue around here.

I do like the idea of just writing ':list "MyList"' and not needed much
else. It does seem a bit overkill to be typing my own email address into
the Sieve script for the very same account.

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6RN7egU095839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 27 Jul 2009 16:07:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6RN7ero095838; Mon, 27 Jul 2009 16:07:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (75-101-96-32.dsl.static.sonic.net [75.101.96.32] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6RN7Srk095820 for <[e-mail]>; Mon, 27 Jul 2009 16:07:38 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.cx (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with ESMTP id 9910716CE; Mon, 27 Jul 2009 16:07:36 -0700 (PDT)
MIME-Version: 1.0
Date: Mon, 27 Jul 2009 16:07:36 -0700
From: Aaron Stone <[e-mail]>
To: <[e-mail]>
Cc: Robert Burrell Donkin <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To =?UTF-8?Q?	Section 2.4?In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
X-Sender: [e-mail]
User-Agent: RoundCube Webmail/0.2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, 25 Jul 2009 14:23:29 -0400, Barry Leiba
<[e-mail]> wrote:
>> Use relative URIs to represent resources managed transparently by the
>> Sieve Engine.
> 
> This was my thought as well, when Alexey first brought the idea up.
> Originally, the idea was that the list name was just a string,
> understood by the Sieve processor.  It quickly became clear that that
> was problematic, and we should go with URIs.  Some thought they should
> always be absolute, and I thought relative ones should be allowed.  We
> batted that around for some while, and settled on absolute.
> 
> Apart from the reason you mention -- that it can be confusing -- the
> main argument against using relative URIs is the difficulty in clearly
> (and interoperably) defining what the relative ones mean.  Saying that
> the Sieve processor understands what they mean ignores the real
> problem with making sure the user (and/or the client) also understands
> it.
> 
> I think we should stay with absolute URIs.

[As IC:]

With the tag: URI scheme, you do get the effect of a server-specific URI,
and with a clear indication that that's what you're looking at (since it
begins literally with "tag:"). Does that address the concerns here?

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6RGJfGh067728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 27 Jul 2009 09:19:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6RGJfLR067727; Mon, 27 Jul 2009 09:19:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (daboo.name [151.201.22.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6RGJUwR067700 for <[e-mail]>; Mon, 27 Jul 2009 09:19:41 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 43389174C4A3 for <[e-mail]>; Mon, 27 Jul 2009 12:19:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu0dBjDHSf7n for <[e-mail]>; Mon, 27 Jul 2009 12:19:28 -0400 (EDT)
Received: from dhcp-10ae.meeting.ietf.org (dhcp-10ae.meeting.ietf.org [130.129.16.174]) by daboo.name (Postfix) with ESMTP id 0F750174C498 for <[e-mail]>; Mon, 27 Jul 2009 12:19:27 -0400 (EDT)
Date: Mon, 27 Jul 2009 18:19:25 +0200
From: Cyrus Daboo <[e-mail]>
To: SIEVE <[e-mail]>
Subject: Slides for meeting uploaded
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size$2
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
I have uploaded a set of slides to the IETF meeting materials site for 
Wednesday's meeting. Please review and let me know of any corrections or 
additions.

<http://www3.ietf.org/proceedings/75/slides/sieve-0.pdf>

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6PIPqpl002163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 25 Jul 2009 11:25:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6PIPqYo002162; Sat, 25 Jul 2009 11:25:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-pz0-f188.google.com (mail-pz0-f188.google.com [209.85.222.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6PIPffG002154 for <[e-mail]>; Sat, 25 Jul 2009 11:25:52 -0700 (MST) (envelope-from [e-mail])
Received: by pzk26 with SMTP id 26so1493362pzk.16 for <[e-mail]>; Sat, 25 Jul 2009 11:25:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JXNwbWU8ldQVVjBGXcYsAwp2lhIaZHXdanPpMiF9MSc=; b=rNIO3tTXU3F15T+PlscgPalPbUdmMps947TQSvqthZLMQaD7738K5iqO3yZWwoWrj9 NWy8VQVFcSKGHnd3mYc0Nq+TYoi/afyikpsgsR4CCoJ8THHk9d40QRaeLIXxm1B82zjl X7MOnkAZ1CoyCJfNSqmLhDGHI4GNMi6VAQgfsDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bê/5ikKaHYUrBDmE11Ke313AHyjwKwlbEhJxYj+dCumZN4rrMlBLFGnMPJdpPDV4QF pMAGFS7LYPJrnH2BTheB3uG7YeGoeJ3N9geMy2do6KmaqcH9/K+QEb1+ZjoTmHQjvD2A jbtyPD2WnNGqR1gxlHM1vsWhrE5W3LxEF7gY0MIME-Version: 1.0
Received: by 10.115.106.6 with SMTP id i6mr6667311wam.168.1248546341367; Sat,  25 Jul 2009 11:25:41 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sat, 25 Jul 2009 14:25:41 -0400
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Changes To Section  2.3
From: Barry Leiba <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I don't strongly object to the change Robert suggests, below, but I
think it's useful to explain the situation, to explain why there might
be issues here.  I'd rather not eliminate the paragraph that gives
that explanation.  I'm happier, if we want to use Robert's text, to
leave at least some of the eliminated paragraph in as an informative
note.

Barry

On Fri, Jul 24, 2009 at 5:04 AM, Robert Burrell
Donkin<[e-mail]> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Changes
> - -------
> Revise and consolidate existing paragraphs 3 and 4 into a shorter functional
> description.
>
> Rationale
> - ---------
> Paragraphs 3 and 4 in 2.3 specify complex, hard to test requirements for
> little clear gain. Regarding the redirection as a black box makes the
> specification
> more concise and allows more space for novel approaches.
>
> - --------------------------------------------------------------------------
> [1] Proposed Text
> - --------------------------------------------------------------------------
>
> 2.3.  :list tagged argument to the "redirect" action
>
>   Usage:  redirect :list
>
>   The "redirect" action with the ":list" argument is used to send the
>   message to one or more email addresses stored in the externally
>   stored list 'ext-list-name'.  This variant of the redirect command
>   can be used to implement a personal distribution list.
>
>   The Sieve engine and list server SHOULD collaborate to achieve a
>   redirection consistent with the semantics described in [Sieve]. If
>   they are unable to do so then the situation MUST result in a
>   runtime error.
>
>   See Section 2.4 for the detailed description of syntax used for
>   naming externally stored lists.
>
> - --------------------------------------------------------------------------
> [2] Original Text
> - --------------------------------------------------------------------------
> 2.3.  :list tagged argument to the "redirect" action
>
>   Usage:  redirect :list
>
>   The "redirect" action with the ":list" argument is used to send the
>   message to one or more email addresses stored in the externally
>   stored list 'ext-list-name'.  This variant of the redirect command
>   can be used to implement a personal distribution list.
>
>   Use of this feature requires that the list resolve to a list of email
>   addresses, and that the Sieve engine be able to enumerate those
>   addresses. [[anchor5: Alexey would like the option of allowing the
>   list handler to enumerate the addresses and do the redirect there.
>   Barry thinks that's contrary to Sieve, which expects to queue the
>   redirect action for processing at a later stage, and that it would be
>   a bad idea to have the redirect happen in the list handler.  The WG
>   needs to resolve this issue.]]  In cases where, for example, a list
>   contains hashed email address values or an email address pattern
>   ("sz*@example.com", "*[e-mail]"), it will not be possible to
>   redirect to that list.
>
>   If the Sieve engine [[anchor6: or list handler?]] is permanently
>   unable to enumerate the list or the list does not resolve to email
>   addresses, the situation MUST result in a runtime error in the Sieve
>   script.
>
>   See Section 2.4 for the detailed description of syntax used for
>   naming externally stored lists.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6PINfCX002072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sat, 25 Jul 2009 11:23:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6PINfmv002071; Sat, 25 Jul 2009 11:23:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6PINUi9002059 for <[e-mail]>; Sat, 25 Jul 2009 11:23:40 -0700 (MST) (envelope-from [e-mail])
Received: by pxi30 with SMTP id 30so1433990pxi.16 for <[e-mail]>; Sat, 25 Jul 2009 11:23:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wDfXANjk21Mp6vmWTrFA/NV8NrQTvWRz2RPkYe6Ufao=; b=WAzBAHI96Lgx+Jz+MCrLkk0DKa1zi9pL3ZC2FByI8jcvjx3dVpuR2ORPLL3NIxPvEs ovtMFQYoEBYitmWukPKikMJvLbVIYCYAfQzEPfxYJ1t35CU++u9wIZaPm5AizUlhEIcZ tr8Mvc7Urc1SDYgCzmVnvy47jb9AUuKfsVsnADomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=CmPmagBVgTfowhMcVken8Qb3VR/WR9+YSIcGOoAu4GrI++4KaJOkZ9OWOrMzWBJZd0 1H25qObwAJrsDUxhZzskobfIuLj8Ng16igxENKIjjrGUV7ZODqljBkWNy+CAEdNck4+9 JE5z2Pp87gJuSDf7HFsGRMskBRT2VGi8m3ArkMIME-Version: 1.0
Received: by 10.114.161.3 with SMTP id j3mr6614360wae.10.1248546209922; Sat,  25 Jul 2009 11:23:29 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sat, 25 Jul 2009 14:23:29 -0400
Message-ID: <[e-mail]>
Subject: Re: [draft-melnikov-sieve-external-lists] Proposed Addition To  Section 2.4
From: Barry Leiba <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Use relative URIs to represent resources managed transparently by the
> Sieve Engine.

This was my thought as well, when Alexey first brought the idea up.
Originally, the idea was that the list name was just a string,
understood by the Sieve processor.  It quickly became clear that that
was problematic, and we should go with URIs.  Some thought they should
always be absolute, and I thought relative ones should be allowed.  We
batted that around for some while, and settled on absolute.

Apart from the reason you mention -- that it can be confusing -- the
main argument against using relative URIs is the difficulty in clearly
(and interoperably) defining what the relative ones mean.  Saying that
the Sieve processor understands what they mean ignores the real
problem with making sure the user (and/or the client) also understands
it.

I think we should stay with absolute URIs.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6OEBg5D099323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 24 Jul 2009 07:11:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6OEBgip099322; Fri, 24 Jul 2009 07:11:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f215.google.com (mail-bw0-f215.google.com [209.85.218.215]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6OEBTup099295 for <[e-mail]>; Fri, 24 Jul 2009 07:11:40 -0700 (MST) (envelope-from [e-mail])
Received: by bwz11 with SMTP id 11so1506509bwz.10 for <[e-mail]>; Fri, 24 Jul 2009 07:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OmgRTweum3OaLLl5/y5PjzDZoHEpC7bPy0TDijkUn14=; b=vBYDui/ctxtBm/7+CMf/31LfVWD0Lz6hhYgGUk8aP/bK7eBj2grV8gnN7Yd0CTxuA0 BkNq+zEyeDE8MFkwqWShurhE4ka46AXXc9X6lYxLGUahdhFGqLO/Io6U6DX1//XlPGxI dtu6VwSxCZsp9UhuLVawoKnbVW8WqvUPz1z1ADomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qdfWXjokMWv4KRyvyQ8PjfvlGinUHYkZdsVvIlFEwImKKcg1bMekQYDSZrSbKhXkgE Qkvt5zwisNEETur//rw9l+kvw4A25ewZ2DjhobQ2cZTGTs+OhEaMgyaRfAK3OOAwj3hy aotlrSa6/v1xVgbn374XTyOm7lPX2GXDp5eqgMIME-Version: 1.0
Received: by 10.204.112.130 with SMTP id w2mr3316680bkp.56.1248444688858; Fri,  24 Jul 2009 07:11:28 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 24 Jul 2009 15:11:28 +0100
Message-ID: <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Robert Burrell Donkin <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Cc: =?windows-1251?B?xOjr/+0gz+Dr4PPn7uI=?= <[e-mail]>, Alexey Melnikov <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

(apologies for messing up the reply-to foo first time 8-)

On Fri, Jul 24, 2009 at 1:55 PM, Ned Freed<[e-mail]> wrote:
>
>> 2009/7/20 Ned Freed <[e-mail]>:
>> >
>> >
>> >> 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@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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6OCv776093930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 24 Jul 2009 05:57:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6OCv7TM093928; Fri, 24 Jul 2009 05:57:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6OCuuQi093916 for <[e-mail]>; Fri, 24 Jul 2009 05:57:07 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 24 Jul 2009 05:56:53 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 24 Jul 2009 05:56:50 -0700 (PDT)
Date: Fri, 24 Jul 2009 05:55:10 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
In-reply-to: "Your message dated Thu, 23 Jul 2009 22:48:50 +0100" <[e-mail]>
To: Robert Burrell Donkin <[e-mail]>
Cc: Ned Freed <[e-mail]>, =?windows-1251?B?xOjr/+0gz+Dr4PPn7uI=?= <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 8BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 2009/7/20 Ned Freed <[e-mail]>:
> >
> >
> >> 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@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.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6OBcsu3088179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 24 Jul 2009 04:38:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6OBcs2W088169; Fri, 24 Jul 2009 04:38:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f215.google.com (mail-bw0-f215.google.com [209.85.218.215]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6OBcp7F088142 for <[e-mail]>; Fri, 24 Jul 2009 04:38:52 -0700 (MST) (envelope-from [e-mail])
Received: by bwz11 with SMTP id 11so1427125bwz.10 for <[e-mail]>; Fri, 24 Jul 2009 04:38:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=LFkcQMtrvixNgXymWAIFF1Fl8+EQp/J4eMsEa959b7Q=; b=S4+np4O0DEAF3aE0sWnDIjVcqw+jU4wwHsnHDPlv/updjCO16gva0JWdUl4bmDXoBW w+x45Kl7n5QUye2Anxboy2z4KPHusJnv4O7Pz2g/U199nI3fH6a3WQKC70MdAWbGXCqS +9JBSPQWuUQ4S6TWkzHbNZ+R9aEy5R1wV6q9ADomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=lnee0dk2MISMucmyxF1WTn/KCDVTkjgzvMwoExEQX/SHpAavvy7AWHucs4b6NlF5W2 QPapdYTd7Kpz7uQrPHUSnXV4ipEi7b1/dp3i8iN/Mrxu2nmCOxzRRhdSpYVO7r8ikUe3 D7MWBaV4NiHNtuGs4SUvN+MBhaCQji3HrU3KIMIME-Version: 1.0
Received: by 10.204.59.14 with SMTP id j14mr3181213bkh.39.1248435531262; Fri,  24 Jul 2009 04:38:51 -0700 (PDT)
Date: Fri, 24 Jul 2009 12:38:51 +0100
Message-ID: <[e-mail]>
Subject: [draft-melnikov-sieve-external-lists] Proposed Addition To Section  2.4
From: Robert Burrell Donkin <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Proposal
====
Use relative URIs to represent resources managed transparently by the
Sieve Engine.

Rationale
====A little syntactic sugar to simplify scripts.

For example, the following forms might be functionally equivalent:

  redirect :list "tag:example.com,2009-05-28:mylist"
  redirect :list "MyList"

but the relative URI form is more concise.

Disadvantages
======* It is not obvious that the list name is an URI. Some users may therefore
  be surprised to learn that URI naming rules apply.

Sample Use Cases
========
Shared Blacklist Maintained By The System Administrator
-------------------------------------------------------
 if address :list "/blacklist" {
   discard;
 }

Shared Distribution List Maintained By The System Administrator
---------------------------------------------------------------
 redirect :list "/staff"

Private Whitelist Maintained By The System For The User
-------------------------------------------------------
 if header :list "from" "MyFriends" {
   keep;
 }


--------------------------------------------------------------------------
[1] Proposed Insertion
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list MUST be an URI [URI].

2.4.1 Relative URIs

   A relative URI MAY be interpreted by a Sieve engine as a reference to
   a list service resource managed by the implementation. An
   implementation which does not support relative URIs SHOULD raise an
   error at compile time when a list name is a relative URI.

2.4.2 Absolute URIs

   An absolute URI indicates an external list processing resource.
   Implementations might find URLs such as [LDAP], [CardDAV], or
[etc, continuing as per original]

--------------------------------------------------------------------------
[2] Original Text
--------------------------------------------------------------------------

2.4.  Syntax of an externally stored list name

   A name of an externally stored list is always an absolute URI [URI].
   Implementations might find URLs such as [LDAP], [CardDAV], or
   [TAG-URI] to be useful for naming external lists.

   The "tag" URI scheme [TAG-URI] can be used to represent opaque, but
   user friendlier identifiers.  Resolution of such identifiers is going
   to be implementation specific and it can help in hiding the
   complexity of an implementation from end users.  For example, an
   implementation can provide a web interface for managing lists of
   users stored in LDAP.  Requiring users to know generic LDAP URL
   syntax might not be very practical, due to its complexity.  An
   implementation can instead use a fixed tag URI prefix such as "tag:
   example.com,<date>:" (where <date> can be, for example, a date
   generated once on installation of the web interface and left
   untouched upon upgrades) and the prefix doesn't even need to be shown
   to end users.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6O94fYX076165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 24 Jul 2009 02:04:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6O94fYC076164; Fri, 24 Jul 2009 02:04:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f215.google.com (mail-bw0-f215.google.com [209.85.218.215]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6O94QlP076148 for <[e-mail]>; Fri, 24 Jul 2009 02:04:37 -0700 (MST) (envelope-from [e-mail])
Received: by bwz11 with SMTP id 11so1358705bwz.10 for <[e-mail]>; Fri, 24 Jul 2009 02:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bhµqkiCHxoMUXRJdHj9hEa0u4Rxktp9Wns2XuZM57G58=; b=qwWMCNSrUT4noGhKlddZcX+AV2zki8wWEjNAgsOgI1588pX2pp2r5LouPpYc7r+3Wl 8EKi74Zq3bLBLBVtFoK99S3auh0kkKpgWurFaQXSX/krcxBlmYDOHRpgsLy9r2MrGj7l tkU0MHJcmDFFnU3xst00b+SNY9fHg4reG7qF8DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=meRojeReDlewOZ8mhGfAIFLd5G2H0OCoTFkQI1VNO7JM2/jqMkckR7AaO10Fa3p4p7 2asOLNkyr9W67kiPAWAZk7cpAKqaNYZMUEpgW7rJis8Hr+A7/xEOc4ER3EfQCS+xbVfE b5ygYWsQgKwbKhvZ7NPFmFgY4JHidHDpgV2goMIME-Version: 1.0
Received: by 10.204.116.208 with SMTP id n16mr2989652bkq.96.1248426266024;  Fri, 24 Jul 2009 02:04:26 -0700 (PDT)
Date: Fri, 24 Jul 2009 10:04:25 +0100
Message-ID: <[e-mail]>
Subject: [draft-melnikov-sieve-external-lists] Proposed Changes To Section 2.3
From: Robert Burrell Donkin <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Changes
- -------
Revise and consolidate existing paragraphs 3 and 4 into a shorter functional
description.

Rationale
- ---------
Paragraphs 3 and 4 in 2.3 specify complex, hard to test requirements for
little clear gain. Regarding the redirection as a black box makes the
specification
more concise and allows more space for novel approaches.

- --------------------------------------------------------------------------
[1] Proposed Text
- --------------------------------------------------------------------------

2.3.  :list tagged argument to the "redirect" action

   Usage:  redirect :list

   The "redirect" action with the ":list" argument is used to send the
   message to one or more email addresses stored in the externally
   stored list 'ext-list-name'.  This variant of the redirect command
   can be used to implement a personal distribution list.

   The Sieve engine and list server SHOULD collaborate to achieve a
   redirection consistent with the semantics described in [Sieve]. If
   they are unable to do so then the situation MUST result in a
   runtime error.

   See Section 2.4 for the detailed description of syntax used for
   naming externally stored lists.

- --------------------------------------------------------------------------
[2] Original Text
- --------------------------------------------------------------------------
2.3.  :list tagged argument to the "redirect" action

   Usage:  redirect :list

   The "redirect" action with the ":list" argument is used to send the
   message to one or more email addresses stored in the externally
   stored list 'ext-list-name'.  This variant of the redirect command
   can be used to implement a personal distribution list.

   Use of this feature requires that the list resolve to a list of email
   addresses, and that the Sieve engine be able to enumerate those
   addresses. [[anchor5: Alexey would like the option of allowing the
   list handler to enumerate the addresses and do the redirect there.
   Barry thinks that's contrary to Sieve, which expects to queue the
   redirect action for processing at a later stage, and that it would be
   a bad idea to have the redirect happen in the list handler.  The WG
   needs to resolve this issue.]]  In cases where, for example, a list
   contains hashed email address values or an email address pattern
   ("sz*@example.com", "*[e-mail]"), it will not be possible to
   redirect to that list.

   If the Sieve engine [[anchor6: or list handler?]] is permanently
   unable to enumerate the list or the list does not resolve to email
   addresses, the situation MUST result in a runtime error in the Sieve
   script.

   See Section 2.4 for the detailed description of syntax used for
   naming externally stored lists.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.6)

iQIcBAEBAgAGBQJKaXkZAAoJEHl6NpRAqILLt74P/2VpgofdttuAXkn0TZg60DJC
p3QT+jnnBMNNnBhGXKAQbG+h3REKThAvdDHgsfaAGXWLSQyCqz0ymdHU4S2Stp6w
WvhWJbQ9su1W54+lH7GjND0BCVw9X8ZqSvCSBtUKw+5p9oSOI29mSoR/ytPUspP0
y9qtQHBCjqTpslrOAqva3jtl7mK1iV6kBInfeqrhf/+V4jqAZQxXe3CMxOxPGU2Y
p+pT1cQgl/og76H1ZPomBmyO6RMQFhhELnXoDBp+kDWiHoW/0wpeiNGOl36zMd+H
KwdhxxWRqo26Za+w7oYP8VbV2mohepYEsN+PDcKCnTU+/U+zaS/Wk3HM1u/yVdmj
VGOijT/2NzUyeZZdloBYqN0cG9FLuQ1WBgILGSAyyYgDhHxe9Iss1gHwwfDy4mn7
djVnWBrS1vtr0SEo4Iaxypc7/s8ng3k1/557VZ070+cKuagtimya1qITGUtldU27
gZhwkxhrk3EXszZJBx8Op4qzk44ccZTVaG4i3CeDgSrF3AVF7J2PJnI/Qj4s2vM8
Qpcu+T1UDKOeWAapSPb7OmreKze/RTWi9gT0xiZA9Un3JZ4XcMLnq7BVZHYYzm40
x5ygqW1CWeQ+LOoxSM3wFuV7iAGrJnrtHV4qmCBaD2O9xHm8hEEGgVvfxbQnxWfe
HBXczQZuO61ojHSMCW4U
=g4tW
-----END PGP SIGNATURE-----



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6NLn34e032769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 23 Jul 2009 14:49:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6NLn3lM032768; Thu, 23 Jul 2009 14:49:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-fx0-f208.google.com (mail-fx0-f208.google.com [209.85.220.208]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6NLmp3j032749 for <[e-mail]>; Thu, 23 Jul 2009 14:49:02 -0700 (MST) (envelope-from [e-mail])
Received: by fxm4 with SMTP id 4so1147327fxm.10 for <[e-mail]>; Thu, 23 Jul 2009 14:48:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HZzwNSvV4YllO2sayYlTeu7VsM/IJDWVmqpkVixsc0w=; b=cuWO6oVMkl8Rg874Snt9okl5q9AktjCFsVpZGZuWmXMq7LT20EnA+f0wVcedIoL4aO JLvXofXH9iwrOpP5QwZx/F1H4yGGQimOi6uZRFgJ1GQzjzt+rz5bXo7peOpmHzqOu7CT wrOHbm8g2G00/hInpQx/sN3NXz16Xh9JiTxAIDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pSUlockzkxZ5oKPRuainQTwcwxydvaD5Zb8/Aiw4Xl/rf9zS/ogaTwF3waL3doh9bL JAGpDyh2jUthRIf+M1yvXT06fVkn+F3GbbNNLPICF+wbKqEcjRStVoIcpdKA4U6BNuaU n7olot72uEOrZEF/DBCGiPsaFifBkoDqrDf6kMIME-Version: 1.0
Received: by 10.204.115.67 with SMTP id h3mr2439277bkq.173.1248385730663; Thu,  23 Jul 2009 14:48:50 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 23 Jul 2009 22:48:50 +0100
Message-ID: <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Robert Burrell Donkin <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: =?windows-1251?B?xOjr/+0gz+Dr4PPn7uI=?= <[e-mail]>, Alexey Melnikov <[e-mail]>, [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

2009/7/20 Ned Freed <[e-mail]>:
>
>
>> 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@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

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6NLIkA8018233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 23 Jul 2009 14:18:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6NLIksm018232; Thu, 23 Jul 2009 14:18:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f215.google.com (mail-bw0-f215.google.com [209.85.218.215]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6NLIYlc018215 for <[e-mail]>; Thu, 23 Jul 2009 14:18:45 -0700 (MST) (envelope-from [e-mail])
Received: by bwz11 with SMTP id 11so1131714bwz.10 for <[e-mail]>; Thu, 23 Jul 2009 14:18:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=syxQJKnIjzM+c5piT9HK8mB/D50dHrkl9RakwaFjEL8=; b=PG2Jzrmpkw/x3wP0jdF1sXifEkrOUujFvO52PkRTtkRNFxXDq4BrCfaJCMTeXwuN04 wtCXKB4BR0WN0EUArD/YR8NGJHKpHV4hP6mbCYVWCZblcKlsRn2ChVpeolTiNu4bAJvg g+6GixMCyW86dlFCef+XEQMOFlxgxZmI+hmLgDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hLMxni5Ht3b8iwO8nENrk3KcG3m4hqvIIy5aSrsZU50e8wmSVeffjByecJWZbc6JV0 iouemqUYxz/+GeAt3UR39zIgZO6x+wkcapxfBe3EpWVb/7EuYRZEMep6oBGqAK7tqz9a Zn75D/iI8PmyFeJr6Sssjh2lbHhJbbW5hIZAwMIME-Version: 1.0
Received: by 10.204.52.146 with SMTP id i18mr2495289bkg.82.1248383913136; Thu,  23 Jul 2009 14:18:33 -0700 (PDT)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 23 Jul 2009 22:18:33 +0100
Message-ID: <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Robert Burrell Donkin <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: Barry Leiba <[e-mail]>, Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Jul 22, 2009 at 3:49 PM, Ned Freed<[e-mail]> wrote:
>
>
>> >> But the same issues affect section 2.3.  If the list can't be
>> >> enumerated, you can't redirect to it.
>> >>
>> > :list is not a match type in this case, again it is a black box.
>> ...
>> > So I would like to correct your statement. There is no need whatsoever to be
>> > able to enumerate list membership in Sieve in order to redirect.
>> > The only requirement is that whoever does mailing list expansion needs to be
>> > able to do that. Such entity doesn't have to be the Sieve engine.
>
>> Two things:
>> 1. When I say that the list must be enumerable, I don't necessarily
>> mean "by the Sieve engine."  It's possible for the list not to be
>> enumerable at all, even by the list handler.  Examples are where the
>> list stores hashes of email addresses (to preserve privacy, perhaps)
>> and where the list stores mailbox patterns (all members of department
>> Z have email addresses that start with "dz", so the list of department
>> Z members is querieable ("Is X a member?"), but not enumerable).
>
> Exactly so. And by the same token, a list you can redirect to may not
> necessarily be queryable in any other way.

+1

>> 2. Ah, so you're suggesting that the Sieve engine, which knows how to
>> do a redirect, should pass this on to the list handler, which now also
>> has to know how to do a redirect.  I'm not sure that's a good idea,
>> but I could perhaps be convinced.  I'm curious about what Ned thinks
>> here.
>
> Handling redirect :list by throwing the problem over the fence to a list
> processors is an interesting approach. We actallly use a variant of it - the
> sieve machinery performs variouos actions on the messeage but then invokes our
> more general list expansion machinery to get the necessary address list.

i wonder whether the specification would be cleaner and clearer if it
allowed the sieve and list engines to collaborate in executing the
redirection in the most convenient fashion

- robert



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6NL6uqe009944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 23 Jul 2009 14:06:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6NL6uRY009943; Thu, 23 Jul 2009 14:06:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6NL6fjs009935 for <[e-mail]>; Thu, 23 Jul 2009 14:06:53 -0700 (MST) (envelope-from [e-mail])
Received: by ewy4 with SMTP id 4so1217822ewy.10 for <[e-mail]>; Thu, 23 Jul 2009 14:06:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:date:message-id :subject:in-reply-to:mime-version:x-firegpg-version:content-type; bh=wzjoOZArxrqSABHlGBr6Koasxovp4LvU8Kk+2fsG5M8=; b=LY5gT1d/O3mqOEeDoHBSMPq66mUXAgUZBs3S5nTrcrkulh2fiRsoxgPcovzRYGGQsG SihLldCclEDS67R4tLp5uUrxMMMVJvnCcO5ma6tz7k+pZXbxRTnqov+ITOxMLcjPr/ye M7++gQgKNzUF/mxiqqvvFiCBhyZLLoDltlPx4DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:mime-version :x-firegpg-version:content-type; b=ko5h1yOSlh9Z6N8TRFS8+FbiFME7d6FmgDyD+h+omMLeF5easLfOLIg2Xkg2be45YY PUr6YGTTGLmTEf4cQ6FvVhDiAEMKuBkn6t8o/SzKQSEPKoLK1PsboGlzOYuTpYrqX20d VnhlntSr9cFIB7iaUX7gqvWxoXycI0gxu8ovIReceived: by 10.210.13.12 with SMTP id 12mr3139512ebm.98.1248383193668; Thu, 23 Jul 2009 14:06:33 -0700 (PDT)
Received: from ?127.0.0.1? (94-168-198-57.cable.ubr18.brad.blueyonder.co.uk [94.168.198.57]) by mx.google.com with ESMTPS id 10sm847363eyd.17.2009.07.23.14.06.32 (version=SSLv3 cipher=RC4-MD5); Thu, 23 Jul 2009 14:06:32 -0700 (PDT)
From: [e-mail]
To: Ned Freed <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, [e-mail], MTA filtering mailing list <[e-mail]>
Date: Thu, 23 Jul 2009 22:06:07 +0100 (GMT)
Message-ID: <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
X-FireGPG-Version: 0.7.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="-----firegpg076eqfxhz3sktyyzh6e3tpg"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
-------firegpg076eqfxhz3sktyyzh6e3tpg
Content-Type: text/plain; format=flowed; charset=UTF-8
Content-Transfer-Encoding: base64

KHRoYW5rcyBmb3Iga2lja2luZyB0aGlzIG9mZjogdGhlIHRpbWluZyBpcyBmb3J0dWl0b3VzIHNp
bmNlIGkgcGxhbm5lZCB0byBzdGFydCBpbXBsZW1lbnRpbmcgc29tZXRoaW5nIHNpbWlsYXIgc29v
bi4gaSdsbCBzdGFydCBhIG5ldyB0aHJlYWRzIGZvciBhbnkgbG9uZ2VyIGNvbW1lbnRzLikgDQoN
Ck9uIFdlZCwgSnVsIDIyLCAyMDA5IGF0IDM6MjQgUE0sIE5lZCBGcmVlZDxuZWQuZnJlZWRAbXJv
Y2hlay5jb20+IHdyb3RlOg0KPg0KPg0KPj4gQmFycnkgTGVpYmEgd3JvdGU6DQoNCjxzbmlwPg0K
DQo+PiA+U2VjdGlvbiAyLjMgbmVlZHMgdG8gbWFrZSBpdA0KPj4gPmNsZWFyIHRoYXQgd2hldGhl
ciBhbiBleHRlcm5hbCBsaXN0IGNhbiBkbyB0aGlzIG9yIG5vdCBkZXBlbmRzIHVwb24NCj4+ID50
aGUgbGlzdCwgYW5kIGl0IG5lZWRzIHRvIHNheSB3aGF0IGhhcHBlbnMgaWYgaXQgY2FuJ3QgKGln
bm9yZSwgb3INCj4+ID50aHJvdyBydW50aW1lIGVycm9yIHNlZW0gdG8gYmUgdGhlIHR3byBzZW5z
aWJsZSBjaG9pY2VzLCBhbmQgSSB0aGluayBJDQo+PiA+cHJlZmVyIHRoZSBsYXR0ZXIpLg0KPj4g
Pg0KPj4gPg0KPj4gV2Ugc2hvdWxkIGRpc2N1c3MgdGhpcyBpbiBTdG9ja2hvbG0gKGFuZCBvbiB0
aGUgbWFpbGluZyBsaXN0KS4gSSB3YXNuJ3QNCj4+IHRoaW5raW5nIGFib3V0IGJlaW5nIGFibGUg
dG8gdXNlIHRoZSBoZWFkZXIgdGVzdCB3aXRob3V0IGJlaW5nIGFibGUgdG8NCj4+IHJlZmVyZW5j
ZSB0aGUgc2FtZSBsaXN0IGluIHJlZGlyZWN0Lg0KPg0KPiBXZWxsLCBJIGNhbiBzb3J0IG9mIHNl
ZSBhbiBhcmd1bWVudCB0aGF0IHlvdSBtaWdodCBleHBlY3QgdG8gYmUgYWJsZSB0bw0KPiByZWZl
cmVuY2UgYW55IGxpc3QgdGhhdCB5b3UgdXNlZCBpbiBhbiBfYWRkcmVzc18gdGVzdCBpbiByZWRp
cmVjdCwgYnV0DQo+IGhlYWRlcj8gV2hvIHNheXMgdGhlIGxpc3RzIHdlJ2xsIGJlIGNoZWNraW5n
IGhlYWRlcnMgYWdhaW5zdCBhcmUgb2YNCj4gYWRkcmVzc2VzIG9yIGFueXRoaW5nIHRoYXQgY29y
cmVsYXRlcyB0byBhZGRyZXNzZXM/DQo+DQo+IEFuZCBpbiBmYWN0IHRoZXJlIGFyZSBldmVuIGxp
c3RzIG9mIGFkZHJlc3NlcyAoaGFzaGVkIGxpc3RzIGFyZSB0aGUgb2J2aW91cw0KPiBleGFtcGxl
KSB3aGVyZSB5b3Ugd29uJ3QgYmUgYWJsZSB0byByZWZlcmVuY2UgdGhlbSBpbiByZWRpcmVjdC4N
Cj4NCj4gVGhlIG9wcG9zaXRlIGlzIGdvaW5nIHRvIGJlIHRydWUgYXMgd2VsbC4gVGhlcmUgYXJl
IHBsZW50eSBvZiB1c2UgY2FzZXMgZm9yDQo+IGEgbGlzdCB5b3Ugd2FudCBwZW9wbGUgdG8gYmUg
YWJsZSB0byByZWRpcmVjdCB0byBidXQgbm90IHRlc3QgdGhlIGNvbnRlbnQgb2YNCj4gaW4gYW55
IHdheS4NCg0KKzENCg0KLSByb2JlcnQ-------firegpg076eqfxhz3sktyyzh6e3tpg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.6)

iQIcBAEBAgAGBQJKaNDJAAoJEHl6NpRAqILLrlEQAOS9E090Fv56Y6hKczTzsjHA
z4AROf2HrG8IqG47QWrEZVXQ8GpT75R2kien6bdR+OQJH8S66m/KDRLR0JcDNMET
ll4FekWlcdEACo3TgcVvoMHY/tk0hjt50csQhFsFVPrUg96IU+3FKzeweKkobyuV
c7+h2gOJqfiJtvPlBTkhNoM/vtpwtQHhcUdciXnOTJJ0xD5Zu+YlqFW5GClRFs1u
wB7ljPPAZuTr20oOCHPmO/kdAiTjqT5J/ObplsgU/DcNKZWe7ucs2huVexalU/QR
+gXyp+s+nDsSquYjJV1nrNpnk/eEUQ4sFLozay6ZtAy48siEbnjNNDUNNmdccoZN
xNctQ/Jdyi70H+T+SSTlTKrUzax8c1PCjaXbYkNh5lU13oHim6M5LW7WbZ8CG+GH
fkmeNBLcQJfhPomqAyriQvNnKODWD5uUnZ5krMU0AzG4G8uyRLVmDsa9vUknWOTo
p5w0dvZ3BauC6JWUwH5Vpis9XpYXYYQmGd7ik0LuF20tlEvYGhUP10x18+0p0MHw
YIf72duAiYrJ/sFw4GbCPho0Pz9dopet9v2DISgYdEd5If8IuP/g+yem6HSiVlOJ
x3MRMUtavkEV6K7MqxyWgJiYbtLNAuKBgX/VsPK1eX8yRoU43i3JuyCvnG+cbHw2
Mf8wqyxeQT3Zj7tEC4bC
=xtFj
-----END PGP SIGNATURE-----

-------firegpg076eqfxhz3sktyyzh6e3tpg--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MKpQ3q066773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 22 Jul 2009 13:51:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MKpPTU066772; Wed, 22 Jul 2009 13:51:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MKpOCI066765 for <[e-mail]>; Wed, 22 Jul 2009 13:51:25 -0700 (MST) (envelope-from [e-mail])
Received: from [217.214.124.120] (host-n177-120.homerun.telia.com [217.214.124.120])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 22 Jul 2009 21:51:23 +0100
Message-ID: <[e-mail]>
Date: Wed, 22 Jul 2009 22:50:49 +0200
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Barry Leiba wrote:
 [...]

>Should this next version be renamed to
>"draft-ietf-sieve-external-lists-00"?  In other words, should the WG
>adopt it?  I think it should.
>  
>
Yes. This document is in our charter and my understanding is that the WG 
already made a decision to accept it.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MKIvI9064818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 22 Jul 2009 13:18:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MKIvmn064817; Wed, 22 Jul 2009 13:18:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MKIj7w064804 for <[e-mail]>; Wed, 22 Jul 2009 13:18:56 -0700 (MST) (envelope-from [e-mail])
Received: from [217.214.124.120] (host-n177-120.homerun.telia.com [217.214.124.120])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 22 Jul 2009 21:18:44 +0100
Message-ID: <[e-mail]>
Date: Wed, 22 Jul 2009 22:18:06 +0200
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: [e-mail], MTA filtering mailing list <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:
 [...]

>> We should discuss this in Stockholm (and on the mailing list). I wasn't
>> thinking about being able to use the header test without being able to
>> reference the same list in redirect.
>
> Well, I can sort of see an argument that you might expect to be able to
> reference any list that you used in an _address_ test in redirect, but
> header? Who says the lists we'll be checking headers against are of
> addresses or anything that correlates to addresses?
>
> And in fact there are even lists of addresses (hashed lists are the 
> obvious
> example) where you won't be able to reference them in redirect.
>
> The opposite is going to be true as well. There are plenty of use 
> cases for a
> list you want people to be able to redirect to but not test the 
> content of in
> any way.

I was originally thinking about email only lists, but you and Barry 
convinced me that other types of lists are also useful.

So yes, I will update the draft.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MGIicW047286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 22 Jul 2009 09:18:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MGIieq047285; Wed, 22 Jul 2009 09:18:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-pz0-f188.google.com (mail-pz0-f188.google.com [209.85.222.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MGIXRR047262 for <[e-mail]>; Wed, 22 Jul 2009 09:18:44 -0700 (MST) (envelope-from [e-mail])
Received: by pzk26 with SMTP id 26so214947pzk.16 for <[e-mail]>; Wed, 22 Jul 2009 09:18:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HRovKjek1aebTZQRXCcUP0JlrnU4qXfTokOMDcsoXHw=; b=rglAqMnvliQ3tyjY2nVnSaEo8wIfjIqPGp3BEkYURf32dUVdIEz+0VCdnTsBhVJuDC BXttlTbAKJMXxzhLQfh4m3lnQBH4ZpGoKmFQk1z2v9S/+iRxnwRss2BEL2iZo/Wn40Dq SSDVpmQSkbIVP4IpWfiF3pIbA+qst3PbesnqADomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=th3lt50aS46soUrgaKRvSUfHDWqw9P4g/FI8e1XcwY6xkEOevbS7ETtvhnBTTCbXGm AKSy40U9Uq7lGuNAyqy1FkRU/5pN2FUtEKJ4F0GcOgLmjo1jZ+U1sNg0+TfC37uDaNEW u687YzD7IWR1oUlJxJvQr6ysCK1Ypu9mr+8d4MIME-Version: 1.0
Received: by 10.114.59.13 with SMTP id h13mr726347waa.146.1248279512995; Wed,  22 Jul 2009 09:18:32 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 22 Jul 2009 12:18:32 -0400
Message-ID: <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Barry Leiba <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>
Content-Type: multipart/mixed; boundary1636417b7df3d8ee046f4db864
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--001636417b7df3d8ee046f4db864
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Attached is my proposed -03 version (attached as "-03-pre01"), which
has NOT been posted as an I-D at this point.  I've sent Alexey my
edits, and the edit token is back with him.

I've made a bunch of changes, so forget DIFFs and please read the
whole thing (it's short) and comment.

Should this next version be renamed to
"draft-ietf-sieve-external-lists-00"?  In other words, should the WG
adopt it?  I think it should.

Barry

--001636417b7df3d8ee046f4db864
Content-Type: text/plain; charset=US-ASCII; 
	name="draft-melnikov-sieve-external-lists-03-pre01.txt"
Content-Disposition: attachment; 
	filename="draft-melnikov-sieve-external-lists-03-pre01.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fxg9ctf40

CgoKU2lldmUgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIEEuIE1lbG5pa292CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgSXNvZGUgTGltaXRlZApJbnRlbmRlZCBzdGF0dXM6IFN0YW5k
YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkgMjIsIDIwMDkKRXhwaXJl
czogSmFudWFyeSAyMywgMjAxMAoKCiAgICAgICAgICAgICAgICBTaWV2ZSBFeHRlbnNpb246IEV4
dGVybmFsbHkgU3RvcmVkIExpc3RzCiAgICAgICAgICAgICAgICAgZHJhZnQtbWVsbmlrb3Ytc2ll
dmUtZXh0ZXJuYWwtbGlzdHMtMDMKClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJu
ZXQtRHJhZnQgaXMgc3VibWl0dGVkIHRvIElFVEYgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRo
ZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRz
IGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFz
ayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUg
dGhhdAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50
cyBhcyBJbnRlcm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk
b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUg
dXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55
CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMg
cmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3Jr
IGluIHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNh
biBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0
cy50eHQuCgogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg
Y2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgog
ICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEphbnVhcnkgMjMsIDIwMTAuCgpD
b3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMDkgSUVURiBUcnVzdCBhbmQgdGhl
IHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdo
dHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0
aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1
bWVudHMgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j
dW1lbnQgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykuCiAgIFBsZWFzZSBy
ZXZpZXcgdGhlc2UgZG9jdW1lbnRzIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJp
Z2h0cwogICBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdCB0byB0aGlzIGRvY3VtZW50LgoK
QWJzdHJhY3QKCiAgIFRoZSBTaWV2ZSBzY3JpcHRpbmcgbGFuZ3VhZ2UgY2FuIGJlIHVzZWQgdG8g
aW1wbGVtZW50IHdoaXRlbGlzdGluZywKICAgYmxhY2tsaXN0aW5nLCBhbmQgcGVyc29uYWwgZGlz
dHJpYnV0aW9uIGxpc3RzLiAgQ3VycmVudGx5LCB0aGlzCiAgIHJlcXVpcmVzIHRoYXQgYWxsIG1l
bWJlcnMgb2Ygc3VjaCBsaXN0cyBiZSBoYXJkY29kZWQgaW4gdGhlIHNjcmlwdAoKCgpNZWxuaWtv
diAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjMsIDIwMTAgICAgICAgICAgICAgICAg
W1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgU2lldmUgRXh0ZW5zaW9uOiBFeHRlcm5hbGx5IFN0
b3JlZCBMaXN0cyAgICAgICBKdWx5IDIwMDkKCgogICBpdHNlbGYuICBXaGVuZXZlciBhIG1lbWJl
ciBvZiBhIGxpc3QgaXMgYWRkZWQgb3IgZGVsZXRlZCwgdGhlIHNjcmlwdAogICBuZWVkcyB0byBi
ZSB1cGRhdGVkIGFuZCBwb3NzaWJseSB1cGxvYWRlZCB0byBhIG1haWwgc2VydmVyLgoKICAgVGhp
cyBkb2N1bWVudCBkZWZpbmVzIGEgU2lldmUgZXh0ZW5zaW9uIGZvciBhY2Nlc3NpbmcgZXh0ZXJu
YWxseQogICBzdG9yZWQgbGlzdHMgLS0gbGlzdHMgd2hvc2UgbWVtYmVycyBhcmUgc3RvcmVkIGV4
dGVybmFsbHkgdG8gdGhlCiAgIHNjcmlwdCwgc3VjaCBhcyB1c2luZyBMREFQIChSRkMgNDUxMCks
IEFDQVAgKFJGQyAyMjQ0KSwgb3IgcmVsYXRpb25hbAogICBkYXRhYmFzZXMuCgpUb0RvCgogICBv
ICBOZWVkIGEgd2F5IHRvIGFkdmVydGlzZSBzdXBwb3J0ZWQgVVJJIHNjaGVtYXMgaW4gTWFuYWdl
U2lldmUgYW5kCiAgICAgIGloYXZlLgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgICBJbnRy
b2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IDMKICAgMS4xLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAzCgogICAyLiAgICBFeHRsaXN0cyBleHRlbnNpb24gIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgMi4xLiAgQ2FwYWJpbGl0eSBJ
ZGVudGlmaWVyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzCiAgIDIu
Mi4gIDpsaXN0IG1hdGNoIHR5cGUgZm9yICJhZGRyZXNzIiwgImVudmVsb3BlIiwgYW5kICJoZWFk
ZXIiCiAgICAgICAgIHRlc3RzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gMwogICAyLjMuICA6bGlzdCB0YWdnZWQgYXJndW1lbnQgdG8gdGhl
ICJyZWRpcmVjdCIgYWN0aW9uICAuIC4gLiAuIC4gLiAuIDQKICAgMi40LiAgU3ludGF4IG9mIGFu
IGV4dGVybmFsbHkgc3RvcmVkIGxpc3QgbmFtZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiA0CiAgIDIu
NS4gIEV4YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gNQoKICAgMy4gICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1CgogICA0LiAgICBJQU5BIENvbnNpZGVyYXRpb25z
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDYKCiAgIDUuICAgIEFj
a25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gNwoKICAgNi4gICAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiA3CiAgIDYuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNwogICA2LjIuICBJbmZvcm1hdGl2
ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDcKCiAg
ICAgICAgIEF1dGhvcidzIEFkZHJlc3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gOAoKCgoKCgoKCgoKCgoKTWVsbmlrb3YgICAgICAgICAgICAgICAgRXhwaXJl
cyBKYW51YXJ5IDIzLCAyMDEwICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJh
ZnQgIFNpZXZlIEV4dGVuc2lvbjogRXh0ZXJuYWxseSBTdG9yZWQgTGlzdHMgICAgICAgSnVseSAy
MDA5CgoKMS4gIEludHJvZHVjdGlvbgoKICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gZXh0
ZW5zaW9uIHRvIHRoZSBTaWV2ZSBsYW5ndWFnZSBbU2lldmVdCiAgIGZvciBjaGVja2luZyBtZW1i
ZXJzaGlwIGluIGFuIGV4dGVybmFsIGxpc3Qgb3IgZm9yIHJlZGlyZWN0aW5nCiAgIG1lc3NhZ2Vz
IHRvIGFuIGV4dGVybmFsIGxpc3Qgb2YgcmVjaXBpZW50cy4gIEFuICJleHRlcm5hbCBsaXN0IiBp
cyBhCiAgIGxpc3Qgd2hvc2UgbWVtYmVycyBhcmUgc3RvcmVkIGV4dGVybmFsbHkgdG8gdGhlIFNp
ZXZlIHNjcmlwdCwgc3VjaCBhcwogICB1c2luZyBMREFQIFtMREFQXSwgQUNBUCBbQUNBUF0sIG9y
IHJlbGF0aW9uYWwgZGF0YWJhc2VzLgoKICAgVGhpcyBleHRlbnNpb24gYWRkcyBhIG5ldyBtYXRj
aCB0eXBlIHRvIHRoZSAiYWRkcmVzcyIsICJlbnZlbG9wZSIsCiAgIGFuZCAiaGVhZGVyIiB0ZXN0
cywgYW5kIGEgbmV3IHRhZ2dlZCBhcmd1bWVudCB0byB0aGUgInJlZGlyZWN0IgogICBhY3Rpb24u
CgoxLjEuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQKCiAgIENvbnZlbnRpb25z
IGZvciBub3RhdGlvbnMgYXJlIGFzIGluIFtTaWV2ZV0gc2VjdGlvbiAxLjEsIGluY2x1ZGluZwog
ICB0aGUgdXNlIG9mIFtBQk5GXS4KCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1Qi
LCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQg
Tk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9j
dW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbS3dkc10uCgoKMi4g
IEV4dGxpc3RzIGV4dGVuc2lvbgoKMi4xLiAgQ2FwYWJpbGl0eSBJZGVudGlmaWVyCgogICBUaGUg
Y2FwYWJpbGl0eSBzdHJpbmcgYXNzb2NpYXRlZCB3aXRoIHRoZSBleHRlbnNpb24gZGVmaW5lZCBp
biB0aGlzCiAgIGRvY3VtZW50IGlzICJleHRsaXN0cyIuCgoyLjIuICA6bGlzdCBtYXRjaCB0eXBl
IGZvciAiYWRkcmVzcyIsICJlbnZlbG9wZSIsIGFuZCAiaGVhZGVyIiB0ZXN0cwoKICAgQUJORjoK
CiAgICAgIE1BVENILVRZUEUgID0vICI6bGlzdCIKICAgICAgICAgICA7IG9ubHkgdmFsaWQgZm9y
ICJhZGRyZXNzIiwgImVudmVsb3BlIiwgYW5kICJoZWFkZXIiIHRlc3RzCgogICBUaGUgbmV3ICI6
bGlzdCIgbWF0Y2ggdHlwZSBjaGFuZ2VzIHRoZSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgImtleS0K
ICAgbGlzdCIgcGFyYW1ldGVyIHRvIHRoZSAiYWRkcmVzcyIvImVudmVsb3BlIi8iaGVhZGVyIiB0
ZXN0LiAgV2hlbiB0aGUKICAgbWF0Y2ggdHlwZSBpcyAiOmxpc3QiLCB0aGUga2V5LWxpc3QgYmVj
b21lcyBhIGxpc3Qgb2YgbmFtZXMgb2YKICAgZXh0ZXJuYWxseSBzdG9yZWQgbGlzdHMuICBUaGUg
ZXh0ZXJuYWwgbGlzdHMgYXJlIHF1ZXJpZWQsIHBlcmhhcHMKICAgdGhyb3VnaCBhIGxpc3Qtc3Bl
Y2lmaWMgbWVjaGFuaXNtLCBhbmQgdGhlIHRlc3QgZXZhbHVhdGVzIHRvICJ0cnVlIgogICBpZiBh
bnkgb2YgdGhlIHNwZWNpZmllZCB2YWx1ZXMgbWF0Y2hlcyBhbnkgbWVtYmVyIG9mIG9uZSBvciBt
b3JlIG9mCiAgIHRoZSBsaXN0cy4KCiAgIEZvciBleGFtcGxlLCB0ZXN0aW5nICc6aGVhZGVyIFsi
dG8iLCAiY2MiXScgYWdhaW5zdCBhIGxpc3Qgd291bGQKICAgY2F1c2UgZWFjaCAidG8iIGFuZCAi
Y2MiIHZhbHVlLCBpZ25vcmluZyBsZWFkaW5nIGFuZCB0cmFpbGluZwogICB3aGl0ZXNwYWNlLCB0
byBiZSBxdWVyaWVkLiAgV2hlbiBhbnkgdmFsdWUgaXMgZm91bmQgdG8gYmVsb25nIHRvIHRoZQog
ICBsaXN0LCB0aGUgcXVlcmllcyBtYXkgc3RvcCBhbmQgdGhlIHRlc3QgcmV0dXJucyAidHJ1ZSIu
ICBJZiBubyB2YWx1ZQoKCgpNZWxuaWtvdiAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkg
MjMsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgU2lldmUg
RXh0ZW5zaW9uOiBFeHRlcm5hbGx5IFN0b3JlZCBMaXN0cyAgICAgICBKdWx5IDIwMDkKCgogICBi
ZWxvbmdzIHRvIHRoZSBsaXN0LCB0aGUgdGVzdCByZXR1cm5zICJmYWxzZSIuCgogICBGb3Igc29t
ZSBsaXN0cywgdGhlIFNpZXZlIGVuZ2luZSBtaWdodCBkaXJlY3RseSByZXRyaWV2ZSB0aGUgbGlz
dCBhbmQKICAgbWFrZSBpdHMgb3duIGNvbXBhcmlzb24uICBPdGhlciBsaXN0cyBtaWdodCBub3Qg
d29yayB0aGF0IHdheSAtLSB0aGV5CiAgIG1pZ2h0IHByb3ZpZGUgYSB3YXkgdG8gYXNrIGlmIGEg
dmFsdWUgaXMgaW4gdGhlIGxpc3QsIGJ1dCBub3QgcGVybWl0CiAgIHJldHJpZXZhbCBvZiB0aGUg
bGlzdCBpdHNlbGYuICBJdCBpcyB1cCB0byB0aGUgU2lldmUgaW1wbGVtZW50YXRpb24KICAgdG8g
dW5kZXJzdGFuZCBob3cgdG8gaW50ZXJhY3Qgd2l0aCBhbnkgc3VwcG9ydGVkIGxpc3QuICBJZiB0
aGUgU2lldmUKICAgZW5naW5lIGlzIHBlcm1hbmVudGx5IHVuYWJsZSB0byBxdWVyeSB0aGUgbGlz
dCAocGVyaGFwcyBiZWNhdXNlIHRoZQogICBsaXN0IGRvZXNuJ3Qgc3VwcG9ydCB0aGUgcmVxdWly
ZWQgb3BlcmF0aW9uKSwgdGhlIHRlc3QgTVVTVCByZXN1bHQgaW4KICAgYSBydW50aW1lIGVycm9y
IGluIHRoZSBTaWV2ZSBzY3JpcHQuCgogICBTZWUgU2VjdGlvbiAyLjQgZm9yIHRoZSBkZXRhaWxl
ZCBkZXNjcmlwdGlvbiBvZiBzeW50YXggdXNlZCBmb3IKICAgbmFtaW5nIGV4dGVybmFsbHkgc3Rv
cmVkIGxpc3RzLgoKMi4zLiAgOmxpc3QgdGFnZ2VkIGFyZ3VtZW50IHRvIHRoZSAicmVkaXJlY3Qi
IGFjdGlvbgoKICAgVXNhZ2U6ICByZWRpcmVjdCA6bGlzdCA8ZXh0LWxpc3QtbmFtZTogc3RyaW5n
PgoKICAgVGhlICJyZWRpcmVjdCIgYWN0aW9uIHdpdGggdGhlICI6bGlzdCIgYXJndW1lbnQgaXMg
dXNlZCB0byBzZW5kIHRoZQogICBtZXNzYWdlIHRvIG9uZSBvciBtb3JlIGVtYWlsIGFkZHJlc3Nl
cyBzdG9yZWQgaW4gdGhlIGV4dGVybmFsbHkKICAgc3RvcmVkIGxpc3QgJ2V4dC1saXN0LW5hbWUn
LiAgVGhpcyB2YXJpYW50IG9mIHRoZSByZWRpcmVjdCBjb21tYW5kCiAgIGNhbiBiZSB1c2VkIHRv
IGltcGxlbWVudCBhIHBlcnNvbmFsIGRpc3RyaWJ1dGlvbiBsaXN0LgoKICAgVXNlIG9mIHRoaXMg
ZmVhdHVyZSByZXF1aXJlcyB0aGF0IHRoZSBsaXN0IHJlc29sdmUgdG8gYSBsaXN0IG9mIGVtYWls
CiAgIGFkZHJlc3NlcywgYW5kIHRoYXQgdGhlIFNpZXZlIGVuZ2luZSBiZSBhYmxlIHRvIGVudW1l
cmF0ZSB0aG9zZQogICBhZGRyZXNzZXMuIFtbYW5jaG9yNTogQWxleGV5IHdvdWxkIGxpa2UgdGhl
IG9wdGlvbiBvZiBhbGxvd2luZyB0aGUKICAgbGlzdCBoYW5kbGVyIHRvIGVudW1lcmF0ZSB0aGUg
YWRkcmVzc2VzIGFuZCBkbyB0aGUgcmVkaXJlY3QgdGhlcmUuCiAgIEJhcnJ5IHRoaW5rcyB0aGF0
J3MgY29udHJhcnkgdG8gU2lldmUsIHdoaWNoIGV4cGVjdHMgdG8gcXVldWUgdGhlCiAgIHJlZGly
ZWN0IGFjdGlvbiBmb3IgcHJvY2Vzc2luZyBhdCBhIGxhdGVyIHN0YWdlLCBhbmQgdGhhdCBpdCB3
b3VsZCBiZQogICBhIGJhZCBpZGVhIHRvIGhhdmUgdGhlIHJlZGlyZWN0IGhhcHBlbiBpbiB0aGUg
bGlzdCBoYW5kbGVyLiAgVGhlIFdHCiAgIG5lZWRzIHRvIHJlc29sdmUgdGhpcyBpc3N1ZS5dXSAg
SW4gY2FzZXMgd2hlcmUsIGZvciBleGFtcGxlLCBhIGxpc3QKICAgY29udGFpbnMgaGFzaGVkIGVt
YWlsIGFkZHJlc3MgdmFsdWVzIG9yIGFuIGVtYWlsIGFkZHJlc3MgcGF0dGVybgogICAoInN6KkBl
eGFtcGxlLmNvbSIsICIqK2lldGZAZXhhbXBsZS5uZXQiKSwgaXQgd2lsbCBub3QgYmUgcG9zc2li
bGUgdG8KICAgcmVkaXJlY3QgdG8gdGhhdCBsaXN0LgoKICAgSWYgdGhlIFNpZXZlIGVuZ2luZSBb
W2FuY2hvcjY6IG9yIGxpc3QgaGFuZGxlcj9dXSBpcyBwZXJtYW5lbnRseQogICB1bmFibGUgdG8g
ZW51bWVyYXRlIHRoZSBsaXN0IG9yIHRoZSBsaXN0IGRvZXMgbm90IHJlc29sdmUgdG8gZW1haWwK
ICAgYWRkcmVzc2VzLCB0aGUgc2l0dWF0aW9uIE1VU1QgcmVzdWx0IGluIGEgcnVudGltZSBlcnJv
ciBpbiB0aGUgU2lldmUKICAgc2NyaXB0LgoKICAgU2VlIFNlY3Rpb24gMi40IGZvciB0aGUgZGV0
YWlsZWQgZGVzY3JpcHRpb24gb2Ygc3ludGF4IHVzZWQgZm9yCiAgIG5hbWluZyBleHRlcm5hbGx5
IHN0b3JlZCBsaXN0cy4KCjIuNC4gIFN5bnRheCBvZiBhbiBleHRlcm5hbGx5IHN0b3JlZCBsaXN0
IG5hbWUKCiAgIEEgbmFtZSBvZiBhbiBleHRlcm5hbGx5IHN0b3JlZCBsaXN0IGlzIGFsd2F5cyBh
biBhYnNvbHV0ZSBVUkkgW1VSSV0uCiAgIEltcGxlbWVudGF0aW9ucyBtaWdodCBmaW5kIFVSTHMg
c3VjaCBhcyBbTERBUF0sIFtDYXJkREFWXSwgb3IKICAgW1RBRy1VUkldIHRvIGJlIHVzZWZ1bCBm
b3IgbmFtaW5nIGV4dGVybmFsIGxpc3RzLgoKCgpNZWxuaWtvdiAgICAgICAgICAgICAgICBFeHBp
cmVzIEphbnVhcnkgMjMsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1E
cmFmdCAgU2lldmUgRXh0ZW5zaW9uOiBFeHRlcm5hbGx5IFN0b3JlZCBMaXN0cyAgICAgICBKdWx5
IDIwMDkKCgogICBUaGUgInRhZyIgVVJJIHNjaGVtZSBbVEFHLVVSSV0gY2FuIGJlIHVzZWQgdG8g
cmVwcmVzZW50IG9wYXF1ZSwgYnV0CiAgIHVzZXIgZnJpZW5kbGllciBpZGVudGlmaWVycy4gIFJl
c29sdXRpb24gb2Ygc3VjaCBpZGVudGlmaWVycyBpcyBnb2luZwogICB0byBiZSBpbXBsZW1lbnRh
dGlvbiBzcGVjaWZpYyBhbmQgaXQgY2FuIGhlbHAgaW4gaGlkaW5nIHRoZQogICBjb21wbGV4aXR5
IG9mIGFuIGltcGxlbWVudGF0aW9uIGZyb20gZW5kIHVzZXJzLiAgRm9yIGV4YW1wbGUsIGFuCiAg
IGltcGxlbWVudGF0aW9uIGNhbiBwcm92aWRlIGEgd2ViIGludGVyZmFjZSBmb3IgbWFuYWdpbmcg
bGlzdHMgb2YKICAgdXNlcnMgc3RvcmVkIGluIExEQVAuICBSZXF1aXJpbmcgdXNlcnMgdG8ga25v
dyBnZW5lcmljIExEQVAgVVJMCiAgIHN5bnRheCBtaWdodCBub3QgYmUgdmVyeSBwcmFjdGljYWws
IGR1ZSB0byBpdHMgY29tcGxleGl0eS4gIEFuCiAgIGltcGxlbWVudGF0aW9uIGNhbiBpbnN0ZWFk
IHVzZSBhIGZpeGVkIHRhZyBVUkkgcHJlZml4IHN1Y2ggYXMgInRhZzoKICAgZXhhbXBsZS5jb20s
PGRhdGU+OiIgKHdoZXJlIDxkYXRlPiBjYW4gYmUsIGZvciBleGFtcGxlLCBhIGRhdGUKICAgZ2Vu
ZXJhdGVkIG9uY2Ugb24gaW5zdGFsbGF0aW9uIG9mIHRoZSB3ZWIgaW50ZXJmYWNlIGFuZCBsZWZ0
CiAgIHVudG91Y2hlZCB1cG9uIHVwZ3JhZGVzKSBhbmQgdGhlIHByZWZpeCBkb2Vzbid0IGV2ZW4g
bmVlZCB0byBiZSBzaG93bgogICB0byBlbmQgdXNlcnMuCgoyLjUuICBFeGFtcGxlcwoKICAgW1th
bmNob3I3OiBUaGlzIGV4YW1wbGUgbG9va3Mgd3Jvbmc6IHRoZSAiZW52ZWxvcGUiIHRlc3QgaXMg
cHJvYmFibHkKICAgbm90IHJpZ2h0LiAgU2hvdWxkIGl0IHJlYWxseSBiZSB1c2luZyB0aGUgOmxp
c3QgdGVzdD8gIEl0J3MgdGVzdGluZwogICA6ZGV0YWlsLCBzbyBJIHRoaW5rIGl0IHNob3VsZCBq
dXN0IGJlIGEgc2ltcGxlIHRlc3QsIG1heWJlICcgOmlzCiAgICJteWxpc3QiICcgb3Igc29tZSBz
dWNoLiAgTm8/ICAoQmFycnkpXV0KCiAgIEV4YW1wbGUgMSB1c2VzIHRoZSAiZW52ZWxvcGUiIG9w
dGlvbiBbU2lldmVdIGFuZCB0aGUgInN1YmFkZHJlc3MiCiAgIGV4dGVuc2lvbiBbU3ViYWRkcmVz
c106CgogICAgICAgcmVxdWlyZSBbImV4dGxpc3RzIiwgImVudmVsb3BlIiwgInN1YmFkZHJlc3Mi
XTsKCiAgICAgICAjIFN1Ym1pc3Npb24gZnJvbSBsaXN0IG1lbWJlcnMgaXMgc2VudCB0byBhbGwg
bWVtYmVycwogICAgICAgaWYgYWxsb2YgKGVudmVsb3BlIDpkZXRhaWwgOmxpc3QgInRvIgogICAg
ICAgICAgICAgICAgICAgICAgICAgICJ0YWc6ZXhhbXBsZS5jb20sMjAwOS0wNS0yODpteWxpc3Qi
LAogICAgICAgICAgICAgICAgIGhlYWRlciA6bGlzdCAiZnJvbSIKICAgICAgICAgICAgICAgICAg
ICAgICAgInRhZzpleGFtcGxlLmNvbSwyMDA5LTA1LTI4Om15bGlzdCIpIHsKICAgICAgICAgICBy
ZWRpcmVjdCA6bGlzdCAidGFnOmV4YW1wbGUuY29tLDIwMDktMDUtMjg6bXlsaXN0IjsKICAgICAg
IH0KCgozLiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFNlY3VyaXR5IGNvbnNpZGVyYXRp
b25zIHJlbGF0ZWQgdG8gdGhlICJhZGRyZXNzIi8iZW52ZWxvcGUiLyJoZWFkZXIiCiAgIHRlc3Rz
IGFuZCAicmVkaXJlY3QiIGFjdGlvbiBkaXNjdXNzZWQgaW4gW1NpZXZlXSBhbHNvIGFwcGx5IHRv
IHRoaXMKICAgZG9jdW1lbnQuCgogICBBIGZhaWx1cmUgdG8gcmV0cmlldmUgZGF0YSBkdWUgdG8g
dGhlIHNlcnZlciBzdG9yaW5nIHRoZSBleHRlcm5hbAogICBsaXN0IG1lbWJlcnNoaXAgYmVpbmcg
ZG93biBvciBvdGhlcndpc2UgaW5hY2Nlc3NpYmxlIG1heSBhbHRlciB0aGUKICAgcmVzdWx0IG9m
IFNpZXZlIHByb2Nlc3NpbmcuICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIHRyZWF0IGEgdGVtcG9y
YXJ5CiAgIGZhaWx1cmUgdG8gcmV0cmlldmUgb3IgdmVyaWZ5IGV4dGVybmFsIGxpc3QgbWVtYmVy
c2hpcCBpbiB0aGUgc2FtZQogICBtYW5uZXIgYXMgYSB0ZW1wb3JhcnkgZmFpbHVyZSB0byByZXRy
aWV2ZSBhIFNpZXZlIHNjcmlwdC4gIEZvcgogICBleGFtcGxlLCBpZiB0aGUgU2lldmUgc2NyaXB0
IGlzIHN0b3JlZCBpbiB0aGUgTGlnaHR3ZWlnaHQgRGlyZWN0b3J5CiAgIEFjY2VzcyBQcm90b2Nv
bCBbTERBUF0gYW5kIHRoZSBzY3JpcHQgY2FuJ3QgYmUgcmV0cmlldmVkIHdoZW4gYQogICBtZXNz
YWdlIGlzIHByb2Nlc3NlZCwgdGhlbiB0aGUgYWdlbnQgcGVyZm9ybWluZyBTaWV2ZSBwcm9jZXNz
aW5nIGNhbgoKCgpNZWxuaWtvdiAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjMsIDIw
MTAgICAgICAgICAgICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgU2lldmUgRXh0ZW5z
aW9uOiBFeHRlcm5hbGx5IFN0b3JlZCBMaXN0cyAgICAgICBKdWx5IDIwMDkKCgogICBlaXRoZXIg
YXNzdW1lIHRoYXQgdGhlIHNjcmlwdCBkb2Vzbid0IGV4aXN0IG9yIGRlbGF5IG1lc3NhZ2UgZGVs
aXZlcnkKICAgdW50aWwgdGhlIHNjcmlwdCBjYW4gYmUgcmV0cmlldmVkIHN1Y2Nlc3NmdWxseS4g
IEV4dGVybmFsIGxpc3QKICAgbWVtYmVyc2hpcHMgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgaWYgdGhl
eSBhcmUgYSBwYXJ0IG9mIHRoZSBzY3JpcHQKICAgaXRzZWxmLCBzbyBhIHRlbXBvcmFyeSBmYWls
dXJlIHRvIHJldHJpZXZlIG9yIHF1ZXJ5IHRoZW0gc2hvdWxkIGJlCiAgIGhhbmRsZWQgaW4gdGhl
IHNhbWUgd2F5IGFzIGEgdGVtcG9yYXJ5IGZhaWx1cmUgdG8gcmV0cmlldmUgdGhlIFNpZXZlCiAg
IHNjcmlwdCBpdHNlbGYuCgogICBQcm90b2NvbHMvQVBJcyB1c2VkIHRvIHJldHJpZXZlL3Zlcmlm
eSBleHRlcm5hbCBsaXN0IG1lbWJlcnNoaXAgTVVTVAogICBwcm92aWRlIGFuIGFwcHJvcHJpYXRl
IGxldmVsIG9mIGNvbmZpZGVudGlhbGl0eSBhbmQgYXV0aGVudGljYXRpb24uCiAgIFVzdWFsbHks
IHRoYXQgd2lsbCBiZSBhdCBsZWFzdCB0aGUgc2FtZSBsZXZlbCBvZiBjb25maWRlbnRpYWxpdHkg
YXMKICAgcHJvdG9jb2xzL0FQSXMgdXNlZCB0byByZXRyaWV2ZSBTaWV2ZSBzY3JpcHRzLCBidXQg
b25seSB0aGUKICAgaW1wbGVtZW50YXRpb24gKG9yIGRlcGxveW1lbnQpIHdpbGwga25vdyB3aGF0
IGlzIGFwcHJvcHJpYXRlLgogICBUaGVyZSdzIGEgZGlmZmVyZW5jZSwgZm9yIGV4YW1wbGUsIGJl
dHdlZW4gbWFraW5nIGFuIExEQVAgcmVxdWVzdCBvbgogICBhIGNsb3NlZCBMQU4gdGhhdCdzIG9u
bHkgdXNlZCBmb3IgdHJ1c3RlZCBzZXJ2ZXJzIChpdCBtYXkgYmUgdGhhdAogICBuZWl0aGVyIGVu
Y3J5cHRpb24gbm9yIGF1dGhlbnRpY2F0aW9uIGlzIG5lZWRlZCksIG9uIGEgZmlyZXdhbGxlZCBM
QU4KICAgaW50ZXJuYWwgdG8gYSBjb21wYW55IChpdCBtaWdodCBiZSBPSyB0byBza2lwIGVuY3J5
cHRpb24sIGRlcGVuZGluZwogICB1cG9uIHBvbGljeSksIGFuZCBvbiB0aGUgb3BlbiBJbnRlcm5l
dCAoZW5jcnlwdGlvbiBhbmQgYXV0aGVudGljYXRpb24KICAgYXJlIHByb2JhYmx5IGJvdGggcmVx
dWlyZWQpLiAgSXQgYWxzbyBtYXR0ZXJzIHdoZXRoZXIgdGhlIGxpc3QgYmVpbmcKICAgYWNjZXNz
ZWQgaXMgcHJpdmF0ZSBvciBwdWJsaWMgKG5vIGVuY3J5cHRpb24gb3IgYXV0aGVudGljYXRpb24g
bWF5IGJlCiAgIG5lZWRlZCBmb3IgcHVibGljIGRhdGEsIGV2ZW4gb24gdGhlIEludGVybmV0KS4K
CiAgIEltcGxlbWVudGF0aW9ucyBvZiB0aGlzIGV4dGVuc2lvbnMgc2hvdWxkIGtlZXAgaW4gbWlu
ZCB0aGF0IG1hdGNoaW5nCiAgIHZhbHVlcyBhZ2FpbnN0IGFuIGV4dGVybmFsbHkgc3RvcmVkIGxp
c3QgY2FuIGJlIElPIGFuZC9vciBDUFUKICAgaW50ZW5zaXZlLiAgVGhpcyBjYW4gYmUgdXNlZCB0
byBkZW55IHNlcnZpY2UgdG8gdGhlIG1haWxzZXJ2ZXIgYW5kL29yCiAgIHRvIHNlcnZlcnMgcHJv
dmlkaW5nIGFjY2VzcyB0byBleHRlcm5hbGx5IHN0b3JlZCBtYWlsaW5nIGxpc3RzLiAgQQogICBu
YWl2ZSBpbXBsZW1lbnRhdGlvbiwgc3VjaCBhcyB0aGUgb25lIHRoYXQgdHJpZXMgdG8gcmV0cmll
dmUgY29udGVudAogICBvZiB0aGUgd2hvbGUgbGlzdCB0byBwZXJmb3JtIG1hdGNoaW5nIGNhbiBt
YWtlIHRoaXMgd29yc2UuICBCdXQgbm90ZQogICB0aGF0IG1hbnkgcHJvdG9jb2xzIHRoYXQgY2Fu
IGJlIHVzZWQgZm9yIGFjY2Vzc2luZyBleHRlcm5hbGx5IHN0b3JlZAogICBsaXN0cyBzdXBwb3J0
IGZsZXhpYmxlIHNlYXJjaGluZyBmZWF0dXJlcyB0aGF0IGNhbiBiZSB1c2VkIHRvCiAgIG1pbmlt
aXplIG5ldHdvcmsgdHJhZmZpYyBhbmQgbG9hZCBvbiB0aGUgZGlyZWN0b3J5IHNlcnZpY2UuICBG
b3IKICAgZXhhbXBsZSwgTERBUCBhbGxvd3MgZm9yIHNlYXJjaCBmaWx0ZXJzLiAgSW1wbGVtZW50
YXRpb25zIFNIT1VMRCB1c2UKICAgc3VjaCBmZWF0dXJlcyB3aGVuZXZlciB0aGV5IGNhbi4KCiAg
IE1hbnkgb3JnYW5pemF0aW9ucyBzdXBwb3J0IGV4dGVybmFsIGxpc3RzIHdpdGggdGhvdXNhbmRz
IG9mCiAgIHJlY2lwaWVudHMuICBJbiBvcmRlciB0byBhdm9pZCBtYWlsYm9tYnMgd2hlbiByZWRp
cmVjdGluZyBhIG1lc3NhZ2UKICAgdG8gYW4gZXh0ZXJuYWxseSBzdG9yZWQgbGlzdCwgaW1wbGVt
ZW50YXRpb25zIFNIT1VMRCBlbmZvcmNlIGxpbWl0cwogICBvbiB0aGUgbnVtYmVyIG9mIHJlY2lw
aWVudHMgYW5kL29yIG9uIGRvbWFpbnMgdG8gd2hpY2ggc3VjaAogICByZWNpcGllbnRzIGJlbG9u
Zy4KCgo0LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIGZvbGxvd2luZyB0ZW1wbGF0ZSBz
cGVjaWZpZXMgdGhlIElBTkEgcmVnaXN0cmF0aW9uIG9mIHRoZSBub3RpZnkKICAgU2lldmUgZXh0
ZW5zaW9uIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50OgoKICAgVG86IGlhbmFAaWFuYS5vcmcK
ICAgU3ViamVjdDogUmVnaXN0cmF0aW9uIG9mIG5ldyBTaWV2ZSBleHRlbnNpb24KICAgQ2FwYWJp
bGl0eSBuYW1lOiBleHRsaXN0cwoKCgpNZWxuaWtvdiAgICAgICAgICAgICAgICBFeHBpcmVzIEph
bnVhcnkgMjMsIDIwMTAgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAg
U2lldmUgRXh0ZW5zaW9uOiBFeHRlcm5hbGx5IFN0b3JlZCBMaXN0cyAgICAgICBKdWx5IDIwMDkK
CgogICBEZXNjcmlwdGlvbjogYWRkcyB0aGUgJzpsaXN0JyB0YWdnZWQgYXJndW1lbnQgdG8gJ2Fk
ZHJlc3MnLCAnaGVhZGVyJwogICBhbmQgJ2VudmVsb3BlJyB0ZXN0cywgYW5kIHRvIHRoZSAncmVk
aXJlY3QnIGFjdGlvbi4gIFRoZSAnOmxpc3QnCiAgIGFyZ3VtZW50IGNoYW5nZXMgYWRkcmVzcy9o
ZWFkZXIvZW52ZWxvcGUgdGVzdCB0byBtYXRjaCB2YWx1ZXMgYWdhaW5zdAogICB2YWx1ZXMgc3Rv
cmVkIGluIG9uZSBvciBtb3JlIGV4dGVybmFsbHkgc3RvcmVkIGxpc3QuICBUaGUgJzpsaXN0Jwog
ICBhcmd1bWVudCB0byB0aGUgcmVkaXJlY3QgYWN0aW9uIGNoYW5nZXMgdGhlIHJlZGlyZWN0IGFj
dGlvbiB0bwogICBmb3J3YXJkIHRoZSBtZXNzYWdlIHRvIGVtYWlsIGFkZHJlc3NlcyBzdG9yZWQg
aW4gdGhlIGV4dGVybmFsbHkKICAgc3RvcmVkIGxpc3QuCiAgIFJGQyBudW1iZXI6IHRoaXMgUkZD
CiAgIENvbnRhY3QgYWRkcmVzczoKICAgICAgIFRoZSBTaWV2ZSBkaXNjdXNzaW9uIGxpc3QgPGll
dGYtbXRhLWZpbHRlcnNAaW1jLm9yZz4KCiAgIFRoaXMgaW5mb3JtYXRpb24gc2hvdWxkIGJlIGFk
ZGVkIHRvIHRoZSBsaXN0IG9mIHNpZXZlIGV4dGVuc2lvbnMKICAgZ2l2ZW4gb24gaHR0cDovL3d3
dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9zaWV2ZS1leHRlbnNpb25zLgoKCjUuICBBY2tub3dsZWRn
ZW1lbnRzCgogICBUaGFua3MgdG8gQWxleGFuZHJvcyBWZWxsaXMsIEJhcnJ5IExlaWJhLCBOaWdl
bCBTd2luc29uLCBLamV0aWwKICAgVG9yZ3JpbSBIb21tZSwgRGF2ZSBDcmlkbGFuZCwgQ3lydXMg
RGFib28sIFBldGUgUmVzbmljayBmb3IgaWRlYXMsCiAgIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9u
cy4KCgo2LiAgUmVmZXJlbmNlcwoKNi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtBQk5G
XSAgICAgQ3JvY2tlciwgRC4sIEVkLiBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYgZm9y
IFN5bnRheAogICAgICAgICAgICAgIFNwZWNpZmljYXRpb25zOiBBQk5GIiwgUkZDIDUyMzQsIEph
bnVhcnkgMjAwOC4KCiAgIFtLd2RzXSAgICAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVz
ZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwg
UkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbU2lldmVdICAgIEd1ZW50aGVyLCBQLiBhbmQgVC4g
U2hvd2FsdGVyLCAiU2lldmU6IEFuIEVtYWlsIEZpbHRlcmluZwogICAgICAgICAgICAgIExhbmd1
YWdlIiwgUkZDIDUyMjgsIEphbnVhcnkgMjAwOC4KCiAgIFtVUkldICAgICAgQmVybmVycy1MZWUs
IFQuLCBGaWVsZGluZywgUi4sIGFuZCBMLiBNYXNpbnRlciwgIlVuaWZvcm0KICAgICAgICAgICAg
ICBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheCIsIFNURCA2NiwKICAg
ICAgICAgICAgICBSRkMgMzk4NiwgSmFudWFyeSAyMDA1LgoKNi4yLiAgSW5mb3JtYXRpdmUgUmVm
ZXJlbmNlcwoKICAgW0FDQVBdICAgICBOZXdtYW4sIEMuIGFuZCBKLiBNeWVycywgIkFDQVAgLS0g
QXBwbGljYXRpb24KICAgICAgICAgICAgICBDb25maWd1cmF0aW9uIEFjY2VzcyBQcm90b2NvbCIs
IFJGQyAyMjQ0LCBOb3ZlbWJlciAxOTk3LgoKICAgW0NhcmREQVZdICBEYWJvbywgQy4sICJ2Q2Fy
ZCBFeHRlbnNpb25zIHRvIFdlYkRBViAoQ2FyZERBVikiLCB3b3JrIGluCiAgICAgICAgICAgICAg
cHJvZ3Jlc3MsIGRyYWZ0LWlldGYtdmNhcmRkYXYtY2FyZGRhdiwgSnVseSAyMDA5LgoKICAgW0xE
QVBdICAgICBaZWlsZW5nYSwgSy4sICJMaWdodHdlaWdodCBEaXJlY3RvcnkgQWNjZXNzIFByb3Rv
Y29sCgoKCk1lbG5pa292ICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAyMywgMjAxMCAg
ICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0ICBTaWV2ZSBFeHRlbnNpb246
IEV4dGVybmFsbHkgU3RvcmVkIExpc3RzICAgICAgIEp1bHkgMjAwOQoKCiAgICAgICAgICAgICAg
KExEQVApOiBUZWNobmljYWwgU3BlY2lmaWNhdGlvbiBSb2FkIE1hcCIsIFJGQyA0NTEwLAogICAg
ICAgICAgICAgIEp1bmUgMjAwNi4KCiAgIFtTdWJhZGRyZXNzXQogICAgICAgICAgICAgIE11cmNo
aXNvbiwgSy4sICIiLCBSRkMgNTIzMywgSmFudWFyeSAyMDA4LgoKICAgW1RBRy1VUkldICBLaW5k
YmVyZywgVC4gYW5kIFMuIEhhd2tlLCAiVGhlICd0YWcnIFVSSSBTY2hlbWUiLAogICAgICAgICAg
ICAgIFJGQyA0MTUxLCBPY3RvYmVyIDIwMDUuCgoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgQWxleGV5
IE1lbG5pa292CiAgIElzb2RlIExpbWl0ZWQKICAgNSBDYXN0bGUgQnVzaW5lc3MgVmlsbGFnZQog
ICAzNiBTdGF0aW9uIFJvYWQKICAgSGFtcHRvbiwgTWlkZGxlc2V4ICBUVzEyIDJCWAogICBVSwoK
ICAgRW1haWw6IEFsZXhleS5NZWxuaWtvdkBpc29kZS5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKCk1lbG5pa292ICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAyMywgMjAx
MCAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCg=
--001636417b7df3d8ee046f4db864--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MEtfjA040490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 22 Jul 2009 07:55:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MEtfmF040489; Wed, 22 Jul 2009 07:55:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MEte1K040483 for <[e-mail]>; Wed, 22 Jul 2009 07:55:40 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 22 Jul 2009 07:55:38 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 22 Jul 2009 07:55:36 -0700 (PDT)
Date: Wed, 22 Jul 2009 07:49:17 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
In-reply-to: "Your message dated Wed, 22 Jul 2009 09:46:22 -0400" <[e-mail]>
To: Barry Leiba <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Content-transfer-encoding: 8BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >> But the same issues affect section 2.3.  If the list can't be
> >> enumerated, you can't redirect to it.
> >>
> > :list is not a match type in this case, again it is a black box.
> ...
> > So I would like to correct your statement. There is no need whatsoever to be
> > able to enumerate list membership in Sieve in order to redirect.
> > The only requirement is that whoever does mailing list expansion needs to be
> > able to do that. Such entity doesn't have to be the Sieve engine.

> Two things:
> 1. When I say that the list must be enumerable, I don't necessarily
> mean "by the Sieve engine."  It's possible for the list not to be
> enumerable at all, even by the list handler.  Examples are where the
> list stores hashes of email addresses (to preserve privacy, perhaps)
> and where the list stores mailbox patterns (all members of department
> Z have email addresses that start with "dz", so the list of department
> Z members is querieable ("Is X a member?"), but not enumerable).

Exactly so. And by the same token, a list you can redirect to may not
necessarily be queryable in any other way.

> 2. Ah, so you're suggesting that the Sieve engine, which knows how to
> do a redirect, should pass this on to the list handler, which now also
> has to know how to do a redirect.  I'm not sure that's a good idea,
> but I could perhaps be convinced.  I'm curious about what Ned thinks
> here.

Handling redirect :list by throwing the problem over the fence to a list
processors is an interesting approach. We actallly use a variant of it - the
sieve machinery performs variouos actions on the messeage but then invokes our
more general list expansion machinery to get the necessary address list.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6METbqK038732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 22 Jul 2009 07:29:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6METbJt038731; Wed, 22 Jul 2009 07:29:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6METPvV038705 for <[e-mail]>; Wed, 22 Jul 2009 07:29:35 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Wed, 22 Jul 2009 07:29:23 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 22 Jul 2009 07:29:20 -0700 (PDT)
Date: Wed, 22 Jul 2009 07:24:52 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
In-reply-to: "Your message dated Wed, 22 Jul 2009 11:38:06 +0100" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail], MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Barry Leiba wrote:

> >In my previous message I said that I had other issues with the
> >document.  Here they are:
> >
> >Making :list a match type sorts out my issues with section 2.2, so that's fine.
> >
> >But the same issues affect section 2.3.  If the list can't be
> >enumerated, you can't redirect to it.
> >
> :list is not a match type in this case, again it is a black box.

> >Section 2.3 needs to make it
> >clear that whether an external list can do this or not depends upon
> >the list, and it needs to say what happens if it can't (ignore, or
> >throw runtime error seem to be the two sensible choices, and I think I
> >prefer the latter).
> >
> >
> We should discuss this in Stockholm (and on the mailing list). I wasn't
> thinking about being able to use the header test without being able to
> reference the same list in redirect.

Well, I can sort of see an argument that you might expect to be able to
reference any list that you used in an _address_ test in redirect, but
header? Who says the lists we'll be checking headers against are of
addresses or anything that correlates to addresses?

And in fact there are even lists of addresses (hashed lists are the obvious
example) where you won't be able to reference them in redirect.

The opposite is going to be true as well. There are plenty of use cases for a
list you want people to be able to redirect to but not test the content of in
any way.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MDkXHH034972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 22 Jul 2009 06:46:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MDkXhq034971; Wed, 22 Jul 2009 06:46:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MDkMpr034934 for <[e-mail]>; Wed, 22 Jul 2009 06:46:33 -0700 (MST) (envelope-from [e-mail])
Received: by wa-out-1112.google.com with SMTP id n7so30523wag.26 for <[e-mail]>; Wed, 22 Jul 2009 06:46:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w27dw67QMt99b/OFtB+MNIeQnGMEhRtZij60i3O+Rqo=; bíJQmL9U4haZat2mCZ4+WTMVvd4PSAXPVijMTRKbHhyRWXFcGTeYc4eEjP+KDEbbSa omnx0rSRcrlLj2knTYexb/sGhP3iDW8GP9vZ7SLaEzkxchiJH0Ytyxl39rCnK5pR1WYt f5cEq1QhvXOFMHtuBPnumJ3trFzpBLSbc1PtYDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=m4pCPxAj5pxDFax1hRS7jQCzDiqpId48vmOcFdEprvIZI/aDTUbI8S34d/8kyqSDcZ 8i6eALjfs+P3err3JtW3ZhaLDTnuR43aflJk+62QyltY1gVuWTZAIz4J3F4qr7hk3P8Z axNUg1mjxdzQNpFI1gOH61doN/l9N7gYDt8hYMIME-Version: 1.0
Received: by 10.114.26.17 with SMTP id 17mr542362waz.133.1248270382105; Wed,  22 Jul 2009 06:46:22 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 22 Jul 2009 09:46:22 -0400
Message-ID: <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Barry Leiba <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>> But the same issues affect section 2.3.  If the list can't be
>> enumerated, you can't redirect to it.
>>
> :list is not a match type in this case, again it is a black box.
...
> So I would like to correct your statement. There is no need whatsoever to be
> able to enumerate list membership in Sieve in order to redirect.
> The only requirement is that whoever does mailing list expansion needs to be
> able to do that. Such entity doesn't have to be the Sieve engine.

Two things:
1. When I say that the list must be enumerable, I don't necessarily
mean "by the Sieve engine."  It's possible for the list not to be
enumerable at all, even by the list handler.  Examples are where the
list stores hashes of email addresses (to preserve privacy, perhaps)
and where the list stores mailbox patterns (all members of department
Z have email addresses that start with "dz", so the list of department
Z members is querieable ("Is X a member?"), but not enumerable).

2. Ah, so you're suggesting that the Sieve engine, which knows how to
do a redirect, should pass this on to the list handler, which now also
has to know how to do a redirect.  I'm not sure that's a good idea,
but I could perhaps be convinced.  I'm curious about what Ned thinks
here.

>> Section 2.3 needs to make it
>> clear that whether an external list can do this or not depends upon
>> the list, and it needs to say what happens if it can't (ignore, or
>> throw runtime error seem to be the two sensible choices, and I think I
>> prefer the latter).
>
> We should discuss this in Stockholm (and on the mailing list). I wasn't
> thinking about being able to use the header test without being able to
> reference the same list in redirect.

There's also the case where the list is not a list of email addresses.
 In that case, it can certainly be used for section 2.2, but not for
2.3.  2.3 still has to say what to do.  Repeating, I think it's a
"SHOULD [or maybe MUST] cause a runtime error" if the list can't be
used for redirect because of the type of list it is (which includes
the discussion above).

>> I'd rather decouple them, and just say that the Sieve processor MUST use
>> "appropriate security" to interact with the list,
>
> I think "appropriate security" is quite ambiguous.

I don't think it's ambiguous, but, not, it's not well specified.  I
expected to put more words in to be clearer, but the point is that
it's ultimately the responsibility of the implementation to know
what's appropriate.  There's a difference between making an LDAP
request in a closed LAN that's only used for trusted servers (neither
encryption nor authentication may be needed), a firewalled LAN for a
particular company (it might be OK to skip encryption, depending upon
policy), or the open Internet (encryption and authentication probably
required), and whether the list being accessed is private or public
(no encryption or authentication needed for public data, even on the
Internet).

We can't dictate any of that in the spec... we can only give examples
and advice, and leave the final choice of what's "appropriate" to the
implementation.

>> The normative text in the "mail bombs" consideration should move to
>> section 2.3, though I think it's still a good idea to mention the
>> issue here as well.
>
> I am not sure this is needed. Similar text in the base Sieve spec is in the
> Security Considerations section.

OK.  I don't have a very strong opinion here.  I think it's harmless
and possible helpful to put the normative bits earlier in the
document.  But it's OK with me if consensus is that it doesn't matter.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MAhG02019702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 22 Jul 2009 03:43:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MAhGQm019701; Wed, 22 Jul 2009 03:43:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MAhFpM019692 for <[e-mail]>; Wed, 22 Jul 2009 03:43:15 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.124] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 22 Jul 2009 11:43:14 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Wed, 22 Jul 2009 11:42:42 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Barry Leiba wrote:
>
>> In my previous message I said that I had other issues with the
>> document.  Here they are:
>>
>> Making :list a match type sorts out my issues with section 2.2, so 
>> that's fine.
>>
>> But the same issues affect section 2.3.  If the list can't be
>> enumerated, you can't redirect to it.
>
> :list is not a match type in this case, again it is a black box.

So I would like to correct your statement. There is no need whatsoever 
to be able to enumerate list membership in Sieve in order to redirect.
The only requirement is that whoever does mailing list expansion needs 
to be able to do that. Such entity doesn't have to be the Sieve engine.

>> Section 2.3 needs to make it
>> clear that whether an external list can do this or not depends upon
>> the list, and it needs to say what happens if it can't (ignore, or
>> throw runtime error seem to be the two sensible choices, and I think I
>> prefer the latter).
>
> We should discuss this in Stockholm (and on the mailing list). I 
> wasn't thinking about being able to use the header test without being 
> able to reference the same list in redirect.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MAcqSG019370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 22 Jul 2009 03:38:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6MAcqP2019369; Wed, 22 Jul 2009 03:38:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6MAce0t019355 for <[e-mail]>; Wed, 22 Jul 2009 03:38:51 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.124] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 22 Jul 2009 11:38:38 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Wed, 22 Jul 2009 11:38:06 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Barry Leiba wrote:

>In my previous message I said that I had other issues with the
>document.  Here they are:
>
>Making :list a match type sorts out my issues with section 2.2, so that's fine.
>
>But the same issues affect section 2.3.  If the list can't be
>enumerated, you can't redirect to it.
>
:list is not a match type in this case, again it is a black box.

>Section 2.3 needs to make it
>clear that whether an external list can do this or not depends upon
>the list, and it needs to say what happens if it can't (ignore, or
>throw runtime error seem to be the two sensible choices, and I think I
>prefer the latter).
>  
>
We should discuss this in Stockholm (and on the mailing list). I wasn't 
thinking about being able to use the header test without being able to 
reference the same list in redirect.

>Section 2.4 says that the syntax of the list name is a URI, but it
>doesn't talk about the semantics.  Along with the change to 2.2,
>section 2.4 needs to change to (1) note that some URI types make sense
>and some don't (Alexey already has this on his to-do list,
>
Right.

>and (2)
>explain that the URI has to resolve to something that can be used as a
>list in the manner specified in 2.2 and 2.3... and talk a little about
>what that means.  Specifically, it has to be something that can be
>given a string and can determine whether that string "is a member"...
>and that it MAY also be something that can return its members as a
>list or through an iterator.
>  
>
Ok.

>Section 3, Security Considerations, needs some work, I think.  First,
>I don't like that there's some normative language there that doesn't
>appear elsewhere.  I prefer to have the normative parts of Security
>Considerations be elsewhere in the document, in the parts that one
>expects to be normative.
>
>Second...
>   Protocols/APIs used to retrieve/verify external list membership MUST
>   provide at least the same level of confidentiality as protocols/APIs
>   used to retrieve Sieve scripts.  For example, if Sieve scripts are
>   retrieved using LDAP secured with Transport Layer Security (TLS)
>   encryption, then the protocol used to retrieve external list
>   membership must use a comparable mechanism for providing connection
>   confidentiality.  In particular, the protocol used to retrieve
>   external list membership must not be lacking encryption.
>
>I don't think this is right.  The connection between the Sieve
>processor and the Sieve script store might be very different to the
>connection it has with the external list.
>
Agreed.

>It's likely that it might
>not be necessary to use TLS to retrieve Sieve scripts, but IS
>necessary to use it to interact with the list, or vice-versa.
>
Right.

>I'd rather decouple them, and just say that the Sieve processor MUST use
>"appropriate security" to interact with the list,
>
I think "appropriate security" is quite ambiguous.

>and that that may mean using TLS, proper authentication, and whatnot -- but that it also
>might not... say, in a closed system where the Sieve processor acting
>on behalf of a user has direct access to the user's address book,
>without fear of interception.
>  
>
The intent was to cover this case.
I think an internal API which doesn't use a TCP protocol underneath (for 
example) and can't be intercepted, then it is considered as secure.

But obviously your reading of this text doesn't agree with my intent, so 
I will think about rewording.

>The normative text in the "mail bombs" consideration should move to
>section 2.3, though I think it's still a good idea to mention the
>issue here as well.
>  
>
I am not sure this is needed. Similar text in the base Sieve spec is in 
the Security Considerations section.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6M5tMuY000960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 21 Jul 2009 22:55:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6M5tLSH000959; Tue, 21 Jul 2009 22:55:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6M5t9qB000946 for <[e-mail]>; Tue, 21 Jul 2009 22:55:20 -0700 (MST) (envelope-from [e-mail])
Received: by pxi30 with SMTP id 30so2339716pxi.16 for <[e-mail]>; Tue, 21 Jul 2009 22:55:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g8Rh0Y7/hjNL8tRX0laErdLbk39qi+tVC78T82R6aPs=; bßYSwuZON+OAmG+S3SYOHjtiWgiZZLrhNwroxWkOHxfD54M0EWIt3zbWZUTloWWtkD qPh4oZCWKBB0MhxafYN7wFsWdMjHu90PDWODboxtfZ9qIe7VlJI2I2tcdR4CcDrY/6SO QSMZodtKKrfrB2cwBmEqBEPB66sh16dtEGCC8DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=sUt2gLyVx1Rne8ZS4ckY3ham4LPe2N8DUjGt8FLSFtircCREU9YYYBY0QmE82kZqaI sgKZ/4akab+weeZIoWbFa2N0uTZoveRWuulvCHfJv1KLjwsrBD76dO1wUxjC4SM9eBtq Aa0qTRiW7lHMGLCASliWUUfjCnwYpR3clxTHUMIME-Version: 1.0
Received: by 10.114.67.18 with SMTP id p18mr848319waa.160.1248242109439; Tue,  21 Jul 2009 22:55:09 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 22 Jul 2009 01:55:09 -0400
Message-ID: <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Barry Leiba <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In my previous message I said that I had other issues with the
document.  Here they are:

Making :list a match type sorts out my issues with section 2.2, so that's fine.

But the same issues affect section 2.3.  If the list can't be
enumerated, you can't redirect to it.  Section 2.3 needs to make it
clear that whether an external list can do this or not depends upon
the list, and it needs to say what happens if it can't (ignore, or
throw runtime error seem to be the two sensible choices, and I think I
prefer the latter).

Section 2.4 says that the syntax of the list name is a URI, but it
doesn't talk about the semantics.  Along with the change to 2.2,
section 2.4 needs to change to (1) note that some URI types make sense
and some don't (Alexey already has this on his to-do list, and (2)
explain that the URI has to resolve to something that can be used as a
list in the manner specified in 2.2 and 2.3... and talk a little about
what that means.  Specifically, it has to be something that can be
given a string and can determine whether that string "is a member"...
and that it MAY also be something that can return its members as a
list or through an iterator.

Section 3, Security Considerations, needs some work, I think.  First,
I don't like that there's some normative language there that doesn't
appear elsewhere.  I prefer to have the normative parts of Security
Considerations be elsewhere in the document, in the parts that one
expects to be normative.

Second...
   Protocols/APIs used to retrieve/verify external list membership MUST
   provide at least the same level of confidentiality as protocols/APIs
   used to retrieve Sieve scripts.  For example, if Sieve scripts are
   retrieved using LDAP secured with Transport Layer Security (TLS)
   encryption, then the protocol used to retrieve external list
   membership must use a comparable mechanism for providing connection
   confidentiality.  In particular, the protocol used to retrieve
   external list membership must not be lacking encryption.

I don't think this is right.  The connection between the Sieve
processor and the Sieve script store might be very different to the
connection it has with the external list.  It's likely that it might
not be necessary to use TLS to retrieve Sieve scripts, but IS
necessary to use it to interact with the list, or vice-versa.  I'd
rather decouple them, and just say that the Sieve processor MUST use
"appropriate security" to interact with the list, and that that may
mean using TLS, proper authentication, and whatnot -- but that it also
might not... say, in a closed system where the Sieve processor acting
on behalf of a user has direct access to the user's address book,
without fear of interception.

The normative text in the "mail bombs" consideration should move to
section 2.3, though I think it's still a good idea to mention the
issue here as well.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6LLK9Ec069764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 21 Jul 2009 14:20:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6LLK9xa069763; Tue, 21 Jul 2009 14:20:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-pz0-f188.google.com (mail-pz0-f188.google.com [209.85.222.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6LLJvq7069740 for <[e-mail]>; Tue, 21 Jul 2009 14:20:07 -0700 (MST) (envelope-from [e-mail])
Received: by pzk26 with SMTP id 26so2387121pzk.16 for <[e-mail]>; Tue, 21 Jul 2009 14:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bhÌIhc4hmLy9A0mFi+yoS/TaYTHAUGXdC23WhCT242QY=; b=x1ccuEsA7h/xlBc8SNcUY66Eo70NIpE8nabxQN7t26fYk9A+N4jwchhCK+X5FqqzFw 9h7q95313u+WBYjEu8WQgP/mBQNd5G0jLk4noYcHZrEY9EtqnJWWO0dR3Ev2WX7VIj1W bqvgEz5Tn3RmsZCSQHIQ78Tl1smG8GmV33JEYDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b¼P0KT3yVewdJSCQbjSkqaFmOOEJ8eGOoDx0iJ/fizbDa7OnZci778l+RR8RvuCewc eacEBT5ZGmsc0JBBvIBL153qpO5/J/tYGr+K4Ew4gqu7A1KoEetf13F7DbBGzJmoMoQI l0xw202mu7FliWc7pjrMNKd5jWorbjxA8lK2wMIME-Version: 1.0
Received: by 10.115.107.1 with SMTP id j1mr204916wam.62.1248211197103; Tue, 21  Jul 2009 14:19:57 -0700 (PDT)
Reply-To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 21 Jul 2009 17:19:57 -0400
Message-ID: <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
From: Barry Leiba <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: =?windows-1251?B?xOjr/+0gz+Dr4PPn7uI=?= <[e-mail]>, Ned Freed <[e-mail]>, [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Ned has answered this nicely. I was thinking about substring matches (kind
> of simplified :matches), but this can be thought of as an implementation
> details. I.e. we can consider an external list to be black box.

I agree with Ned completely, and Alexey sums it up perfectly: an
external list is a black box.  It was the lack of that semantic that
made me resistant to external lists before.  If :list is a match type,
that major issue goes away for me (though I still have others, but I
think they can be resolved).

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K9gXWK019433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 20 Jul 2009 02:42:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6K9gX4L019432; Mon, 20 Jul 2009 02:42:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K9gLMu019422 for <[e-mail]>; Mon, 20 Jul 2009 02:42:32 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.124] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SmQ7ª[e-mail]>; Mon, 20 Jul 2009 10:42:20 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Mon, 20 Jul 2009 10:41:50 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
CC: Ned Freed <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
References: <[e-mail]> <[e-mail]> <28941.1246868682.560969@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Дилян Палаузов wrote:

> 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?

Ned has answered this nicely. I was thinking about substring matches 
(kind of simplified :matches), but this can be thought of as an 
implementation details. I.e. we can consider an external list to be 
black box.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K1fvjs091151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 19 Jul 2009 18:41:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6K1fvIe091149; Sun, 19 Jul 2009 18:41:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6K1fjpi091135 for <[e-mail]>; Sun, 19 Jul 2009 18:41:56 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 19 Jul 2009 18:41:08 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 19 Jul 2009 18:41:03 -0700 (PDT)
Date: Sun, 19 Jul 2009 18:12:25 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
In-reply-to: "Your message dated Sun, 19 Jul 2009 21:41:45 +0200" <[e-mail]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <28941.1246868682.560969@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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@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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JKgWYl077201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 19 Jul 2009 13:42:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JKgW70077200; Sun, 19 Jul 2009 13:42:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JKgVLV077194 for <[e-mail]>; Sun, 19 Jul 2009 13:42:32 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 19 Jul 2009 13:42:26 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 19 Jul 2009 13:42:21 -0700 (PDT)
Date: Sun, 19 Jul 2009 13:13:56 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
In-reply-to: "Your message dated Sun, 19 Jul 2009 20:25:35 +0100" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <28941.1246868682.560969@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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?

Making the match type part of the list argument is just moving the information
around and not changing the underlying semantics. Having any specification at
aall of the match type other than "it's matching a list" is exactly what we
don't want and which cannot be supported. 

Perhaps some specific examples will make this clear. Suppose I have a list of
whitelisted addresses, but because of privacy concerns this list contains the 
SHA-1 hash of each address. The only match type such a list would support is
:is. And it's an inherent characteristic of the list that that's the only
match type.

Now suppose I  have a list of half a million or so strings I don't want to see
as part of a subject line. I've used some algorithm or other to turn this into
a data structure that will tell me if any of those substrings appear in a
single  pass over the subject. The implied match type for such a list is
:contains.

Now consider a list consisting of IP addresses and net masks. I want to check
and see if a given IP address matches anything on the list. (Assuming the list
content is properly normalized, this can be done for IPv4 with no more than 32
exact match comparisons, 128 for IPv6. Of course other, more sophisticated
approaches are also possible.) This list has an effective match type that
corresponds to nothing we currently have in sieve, yet it is a perfectly
reasonable sort of list to want to match against.

Now think for a moment what's involved with having a list that support :matches
or worse, :regex. You now have a list of patterns that have to be checked one
by one, and checking each one is pretty expensive. In other words,
enumerability is a requirement for such a list, and depending on how things are
stored, the match type may still be implied by the underlying storage
mechanism.

Again, there is no doubt that, for the subset of lists that are enumerable,
having the match type be separate makes sense and provides the most
flexibility. But many of the lists we're going to want to check aren't
enumerable, either because the underlying technology doesn't support it or
because enumeration is simply too expensive. And I really have to wonder
if allowing all the combinations when most of them are going to produce
a runtime error is the right way to design this.

And if we decide not to make :list a MATCH-TYPE, the text is going to have to
state that any particular combination of MATCH-TYPE and :list may produce a
runtime error for some subset of the available set of lists. This may even
extend to the default :is MATCH-TYPE, creating a situation where a MATCH-TYPE
has to be specified.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JJg6rP074303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 19 Jul 2009 12:42:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JJg610074302; Sun, 19 Jul 2009 12:42:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JJfskD074289 (version=TLSv1/SSLv3 cipher®S256-SHA bits%6 verify=NO) for <[e-mail]>; Sun, 19 Jul 2009 12:42:05 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1MScGe-0006aU-Kn; Sun, 19 Jul 2009 21:41:52 +0200
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.178.29] (krlh-5f72c0c3.pool.einsundeins.de [95.114.192.195]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id n6JJfpkq025505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 19 Jul 2009 19:41:51 GMT
Message-ID: <[e-mail]>
Date: Sun, 19 Jul 2009 21:41:45 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: Ned Freed <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
References: <[e-mail]>            <[e-mail]>            <28941.1246868682.560969@puncture> <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.95.2 at aegeeserv
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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?

Със здраве,
	дилян



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JJQ77j073503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 19 Jul 2009 12:26:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JJQ7M2073502; Sun, 19 Jul 2009 12:26:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JJQ6LG073496 for <[e-mail]>; Sun, 19 Jul 2009 12:26:06 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.25.192] (92.40.25.192.sub.mbb.three.co.uk [92.40.25.192])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 19 Jul 2009 20:26:04 +0100
Message-ID: <[e-mail]>
Date: Sun, 19 Jul 2009 20:25:35 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
References: <[e-mail]> <[e-mail]> <28941.1246868682.560969@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:
 [...]

> 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.

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?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JJ93a8072642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 19 Jul 2009 12:09:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JJ93RP072641; Sun, 19 Jul 2009 12:09:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JJ8prB072631 for <[e-mail]>; Sun, 19 Jul 2009 12:09:01 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 19 Jul 2009 12:08:46 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 19 Jul 2009 12:08:43 -0700 (PDT)
Date: Sun, 19 Jul 2009 11:46:53 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-melnikov-sieve-external-lists-02.txt
In-reply-to: "Your message dated Sun, 19 Jul 2009 19:38:47 +0100" <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <28941.1246868682.560969@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JIdTYC070662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 19 Jul 2009 11:39:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6JIdTDQ070661; Sun, 19 Jul 2009 11:39:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6JIdIJ5070651 for <[e-mail]>; Sun, 19 Jul 2009 11:39:29 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.25.192] (92.40.25.192.sub.mbb.three.co.uk [92.40.25.192])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 19 Jul 2009 19:39:16 +0100
Message-ID: <[e-mail]>
Date: Sun, 19 Jul 2009 19:38:47 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Comments on draft-melnikov-sieve-external-lists-02.txt
References: <[e-mail]> <[e-mail]> <28941.1246868682.560969@puncture> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Ned,
I've changed the subject and moving my reply to the Sieve mailing list, 
where I think it belongs.

Ned Freed wrote:
 [...]

>> 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.

> 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?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6FAF5jM076582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 15 Jul 2009 03:15:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6FAF5ls076581; Wed, 15 Jul 2009 03:15:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6FAErxD076551 for <[e-mail]>; Wed, 15 Jul 2009 03:15:04 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.170] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 15 Jul 2009 11:14:51 +0100
Message-ID: <[e-mail]>
Date: Wed, 15 Jul 2009 11:14:06 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Cyrus Daboo <[e-mail]>
CC: [e-mail]
Subject: Re: Proposed agenda
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo wrote:

> Hi folks,
> Below is a proposed agenda for the Stockholm meeting. If you have any 
> additions or changes please let me know asap.
>
> Also note that we have a 2 1/2 hour slot this time so I have been 
> generous in assigning time to each item. I would really like to see 
> issues with "active" drafts (include, imap/sieve, external-lists) all 
> dealt with at the meeting.

This looks fine to me.

> RegEx Discussion                                        (20 mins)

Is there an official draft now?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6F47gOc046341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 14 Jul 2009 21:07:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6F47gDm046340; Tue, 14 Jul 2009 21:07:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (daboo.name [151.201.22.177]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6F47Udx046327 for <[e-mail]>; Tue, 14 Jul 2009 21:07:41 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B6AF216CD472 for <[e-mail]>; Wed, 15 Jul 2009 00:07:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT5OkgO6D7Gm for <[e-mail]>; Wed, 15 Jul 2009 00:07:29 -0400 (EDT)
Received: from [10.0.1.2] (unknown [10.0.1.1]) by daboo.name (Postfix) with ESMTP id 5ABEA16CD467 for <[e-mail]>; Wed, 15 Jul 2009 00:07:29 -0400 (EDT)
Date: Wed, 15 Jul 2009 00:07:28 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Proposed agenda
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size52
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
Below is a proposed agenda for the Stockholm meeting. If you have any 
additions or changes please let me know asap.

Also note that we have a 2 1/2 hour slot this time so I have been generous 
in assigning time to each item. I would really like to see issues with 
"active" drafts (include, imap/sieve, external-lists) all dealt with at the 
meeting.

Agenda

Document status review                                  (10 mins)
WG Status review                                        (10 mins)

Notary (draft-freed-sieve-notary-05)                    ( 5 mins)
Notify SIP (draft-ietf-sieve-notify-sip-message-01)     ( 5 mins)

Include (draft-sieve-include-02)                        (20 mins)
IMAP/SIEVE (draft-ietf-lemonade-imap-sieve-06)          (30 mins)
External lists (draft-melnikov-sieve-external-lists-02) (30 mins)
RegEx Discussion                                        (20 mins)

Auto-reply (draft-george-sieve-autoreply-00)            ( 5 mins)

EAI Issues                                              ( 5 mins)
Benefits of SIEVE                                       (10 mins)

================================
Total:                                                  150 mins


-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6DGFXr4087462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 13 Jul 2009 09:15:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6DGFXWM087461; Mon, 13 Jul 2009 09:15:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6DGFXhb087455 for <[e-mail]>; Mon, 13 Jul 2009 09:15:33 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id ED29B3A6E55; Mon, 13 Jul 2009 09:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-mime-loop-09.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 13 Jul 2009 09:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.


	Title           : Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure
	Author(s)       : T. Hansen, C. Daboo
	Filename        : draft-ietf-sieve-mime-loop-09.txt
	Pages           : 22
	Date            : 2009-07-13

This document defines extensions to the Sieve email filtering
language to permit analysis and manipulation of the MIME body parts
of an email message.

Note

This document is being discussed on the MTA-FILTERS mailing list,
[e-mail].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-sieve-mime-loop-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[e-mail]>

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6DFH7BG083565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Mon, 13 Jul 2009 08:17:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n6DFH7eK083564; Mon, 13 Jul 2009 08:17:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-bw0-f215.google.com (mail-bw0-f215.google.com [209.85.218.215]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n6DFGtc4083534 for <[e-mail]>; Mon, 13 Jul 2009 08:17:06 -0700 (MST) (envelope-from [e-mail])
Received: by bwz11 with SMTP id 11so2121164bwz.10 for <[e-mail]>; Mon, 13 Jul 2009 08:16:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Z4glxM4SsLvppxQ3uCTiT5hUMmdYu4av1wj+bT1Fwec=; b=ZLSDpMViLWzY5lEHjko4xDLlf3oa7uov3JC2EL8Uen2wp1F5uvY/TmauSTqUdoiauN pvYrjgcVfx8RZ7bjAkEOkz1g1HAablISAC2my8PfK9Vtfs0C1PE9vFwRX44FFMfMuzlT /2xmOFeVARY1nHgHX5ybNZkdr8J1cuCLO3mFoDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; b=cjM8qj5oKfQxGgC9iJ+IHcdSiAJ8Cc1TbgN6wLkRumctWeX/IIhAh49uPHppT+4hOl 3Ob8Dosj37PNL5xPo1ilGNBCeAxGGfta97MCmPz/wybQXq+HnwWYe2Z1QnPNwXDpQhY3 CfihlvLCEsh4SsGtuwX/TTkoFkefBiC/mz6moMIME-Version: 1.0
Received: by 10.239.152.7 with SMTP id t7mr431145hbb.9.1247498214225; Mon, 13  Jul 2009 08:16:54 -0700 (PDT)
Reply-To: [e-mail]
Date: Mon, 13 Jul 2009 11:16:54 -0400
Message-ID: <[e-mail]>
Subject: Fwd: New Version Notification for draft-ietf-lemonade-imap-sieve-06
From: Barry Leiba <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've posted a new imap-sieve draft, which makes some updates and
includes as notes (search for "[[") Ned's issues with it.  I've also
moved the discussion here, in preparation for moving this document to
the sieve working group and away from lemonade -- we should talk about that
in Stockholm.  I'm asking the sieve chairs for a slot on the agenda in
Stockholm to talk about this draft, which we really should work on and
wrap up.

To that last end, I also ask that folks review what's there and make
comments, especially about (but not limited to) the "[[" notes.  If we
can sort out what to do with those (and explicit text is welcome), we
can make some progress.

I've set the reply-to on this message to go to the sieve mailing list,
at <[e-mail]>.

Barry

---------- Forwarded message ----------
From: IETF I-D Submission Tool <[e-mail]>
Date: Sat, Jul 11, 2009 at 11:33 AM
Subject: New Version Notification for draft-ietf-lemonade-imap-sieve-06
To: [e-mail]

A new version of I-D, draft-ietf-lemonade-imap-sieve-06.txt has been
successfuly submitted by Barry Leiba and posted to the IETF
repository.

Filename:        draft-ietf-lemonade-imap-sieve
Revision:        06
Title:           Support for Sieve in Internet Message Access Protocol (IMAP4)
Creation_date:   2009-07-11
WG ID:           lemonade
Number_of_pages: 24

Abstract:
Sieve defines an email filtering language that can, in principle,
plug into any point in the processing of an email message.  As
defined in the base specification, it plugs into mail delivery.  This
document defines how Sieve can plug into points in the IMAP protocol
where messages are created or changed, adding the option of user-
defined or installation-defined filtering (or, with Sieve extensions,
features such as notifications).Note

This document defines extensions to IMAP and Sieve.  For now, it is
the work of the Lemonade Working Group (Enhancements to Internet
email to support diverse service environments), but it will be moved
to the Sieve working group at some point.

1.  Discussion of this document should be taken to the Sieve mailing

 list at mailto:[e-mail]

2.  Subscription requests can be sent to

 mailto:[e-mail]?body=subscribe (send an

 email message with the word "subscribe" in the body).

3.  A WWW archive of back messages is available at

 http://www.ietf.org/mail-archive/web/sieve/index.html

4.  Older messages, which were posted to the lemonade mailing list,

 are archived at

 http://www.ietf.org/mail-archive/web/lemonade/index.html


The IETF Secretariat.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n65B2m9Q059776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Sun, 5 Jul 2009 04:02:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n65B2mcx059774; Sun, 5 Jul 2009 04:02:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n65B2aZa059757 for <[e-mail]>; Sun, 5 Jul 2009 04:02:47 -0700 (MST) (envelope-from [e-mail])
Received: from [94.197.196.78] (94.197.196.78.threembb.co.uk [94.197.196.78])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 5 Jul 2009 12:02:34 +0100
Message-ID: <[e-mail]>
Date: Sun, 05 Jul 2009 12:01:41 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: [Fwd: I-D Action:draft-melnikov-sieve-external-lists-02.txt]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------060207070701090905090504"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------060207070701090905090504
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

FYI.


--------------060207070701090905090504
Content-Type: message/rfc822;
 name="I-D Action:draft-melnikov-sieve-external-lists-02.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D Action:draft-melnikov-sieve-external-lists-02.txt"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine (Isode M-Box/14.5a0) with LMTP; Sun, 05 Jul 2009 12:00:41 +0100 (BST)
Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]> for <[e-mail]>;
          Sun, 5 Jul 2009 12:00:40 +0100
X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B963D3A6845;
	Sun,  5 Jul 2009 04:00:02 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 0)
	id 5CB813A6845; Sun,  5 Jul 2009 04:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Subject: I-D Action:draft-melnikov-sieve-external-lists-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Sun,  5 Jul 2009 04:00:01 -0700 (PDT)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/i-d-announce>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
	<mailto:[e-mail]?subject=subscribe>
Sender: [e-mail]
Errors-To: [e-mail]


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Sieve Extension: Externally Stored Lists
	Author(s)       : A. Melnikov
	Filename        : draft-melnikov-sieve-external-lists-02.txt
	Pages           : 7
	Date            : 2009-07-05

Sieve scripting language can be used for implementing of
whitelisting, blacklisting and personal distribution lists.
Currently this requires that all members of such lists be hardcoded
in the script itself.  Whenever a member of such list is added or
deleted, the script needs to be updated and possibly uploaded to a
mail server.

This document defines a Sieve extension for accessing externally
stored mailing lists, i.e. list whose members are stored externally
to the script, for example in LDAP (RFC 4510), ACAP (RFC 2244) or a
relational database.

ToDo

o  Need a way to advertise supported URI schemas in ManageSieve and

ihave.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-sieve-external-lists-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-melnikov-sieve-external-lists-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--NextPart--

--------------060207070701090905090504--