[Fwd: Re: Information and collaboration space for Sieve]

[Aaron Stone <[e-mail]>]

Hi folks,

Would those on the various Sieve WG's be interested in a Sieve wiki site
hosted at imc.org? And if so, be willing to manage user accounts to
those who want to post to the wiki?

Aaron

-------- Forwarded Message --------
From: Paul Hoffman <[e-mail]>
To: Aaron Stone <[e-mail]>
Subject: Re: Information and collaboration space for Sieve
Date: Tue, 31 Jan 2006 08:56:47 -0800

>Would you consider an access controlled wiki? Something that authors of
>drafts and frequent contributors could post to, but not just anybody.

Only if I didn't have to administer the posting rights. If the WG 
chairs like the idea and are willing to administer it, I'm happy to 
run it.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VKs0Ya025525; Tue, 31 Jan 2006 12:54:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0VKs0nq025524; Tue, 31 Jan 2006 12:54:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VKs0nt025518 for <[e-mail]>; Tue, 31 Jan 2006 12:54:00 -0800 (PST) (envelope-from [e-mail])
Received: by mail.serendipity.cx (Postfix, from userid 1003) id 69F6A6024E4A; Tue, 31 Jan 2006 12:53:57 -0800 (PST)
Received: from [10.0.1.139] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id DAA926024E3F for <[e-mail]>; Tue, 31 Jan 2006 12:53:54 -0800 (PST)
Subject: [Fwd: Re: Information and collaboration space for Sieve]
From: Aaron Stone <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
Content-Type: text/plain
Date: Tue, 31 Jan 2006 13:01:00 -0800
Message-Id: <1138741260.12024.95.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: !DSPAM:43dfce65296555054315974!
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,

Would those on the various Sieve WG's be interested in a Sieve wiki site
hosted at imc.org? And if so, be willing to manage user accounts to
those who want to post to the wiki?

Aaron

-------- Forwarded Message --------
From: Paul Hoffman <[e-mail]>
To: Aaron Stone <[e-mail]>
Subject: Re: Information and collaboration space for Sieve
Date: Tue, 31 Jan 2006 08:56:47 -0800

>Would you consider an access controlled wiki? Something that authors of
>drafts and frequent contributors could post to, but not just anybody.

Only if I didn't have to administer the posting rights. If the WG 
chairs like the idea and are willing to administer it, I'm happy to 
run it.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VIjrMJ009883; Tue, 31 Jan 2006 10:45:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0VIjrkO009882; Tue, 31 Jan 2006 10:45:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id k0VIjq3V009876 for <[e-mail]>; Tue, 31 Jan 2006 10:45:53 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25092 invoked by uid 101); 31 Jan 2006 13:45:52 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 31 Jan 2006 13:45:52 -0500
To: Ken Murchison <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
Subject: Re: Imapflags "hasflag" test interaction with relational draft
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
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, Jan 31, 2006 at 01:16:34PM -0500, Ken Murchison wrote:
> Alexey Melnikov wrote:
> >
> >This is possbile, but I think for all other tests the default comparator 
> >doesn't depend on match type.
> 
> Well, i;ascii-numeric is a SHOULD for :count (per Relational), and I 
> don't see why this can't be a MUST for hasflag :count, or :count in 
> general).

Relational says:

  The COUNT match type SHOULD only be used with numeric comparators.

which is quite different from saying that a different comparator should
be defaulted when using :count .  I think that trying to induce
different default comparators depending on combination of options opens
up a can of worms; i.e. I would agree that the default comparator should
not depend on the match type.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VIGcrN005871; Tue, 31 Jan 2006 10:16:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0VIGc2i005870; Tue, 31 Jan 2006 10:16:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VIGaDO005856 for <[e-mail]>; Tue, 31 Jan 2006 10:16:37 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.143] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id k0VIGZUI007882 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 31 Jan 2006 13:16:36 -0500
Message-ID: <[e-mail]>
Date: Tue, 31 Jan 2006 13:16:34 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Imapflags "hasflag" test interaction with relational draft
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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:
> Ken Murchison wrote:
> 
>> Alexey Melnikov wrote:
>>
>>> Ken Murchison has asked me how "hasflag" test interacts with 
>>> relational extension.
>>>
>>> hasflag :count will count the number of different flags in a variable.
>>> So
>>> hasflag :count "ge" "MyVariable" "5"
>>>
>>> returns true if the number of different flags in MyVariable is >= 
>>> "5". However note that the default comparator is i;ascii-casemap and 
>>> not i;ascii-numeric. I.e. hasflag test doesn't have the comparator 
>>> parameter. Does anybody see any value in adding the comparator 
>>> parameter to hasflag test?
>>
>>
>> No.  RELATIONAL already requires the presence of i;ascii-numeric, so 
>> you could just state that hasflag :count  uses i;ascii-numeric instead 
>> of i;ascii-casemap.
> 
> 
> This is possbile, but I think for all other tests the default comparator 
> doesn't depend on match type.

Well, i;ascii-numeric is a SHOULD for :count (per Relational), and I 
don't see why this can't be a MUST for hasflag :count, or :count in 
general).


-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VHBeEm096979; Tue, 31 Jan 2006 09:11:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0VHBe6j096978; Tue, 31 Jan 2006 09:11:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VHBdj6096972 for <[e-mail]>; Tue, 31 Jan 2006 09:11:39 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 31 Jan 2006 17:11:34 +0000
Message-ID: <[e-mail]>
Date: Tue, 31 Jan 2006 17:11:34 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Ken Murchison <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Imapflags "hasflag" test interaction with relational draft
References: <[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>

Ken Murchison wrote:

> Alexey Melnikov wrote:
>
>> Ken Murchison has asked me how "hasflag" test interacts with 
>> relational extension.
>>
>> hasflag :count will count the number of different flags in a variable.
>> So
>> hasflag :count "ge" "MyVariable" "5"
>>
>> returns true if the number of different flags in MyVariable is >= 
>> "5". However note that the default comparator is i;ascii-casemap and 
>> not i;ascii-numeric. I.e. hasflag test doesn't have the comparator 
>> parameter. Does anybody see any value in adding the comparator 
>> parameter to hasflag test?
>
> No.  RELATIONAL already requires the presence of i;ascii-numeric, so 
> you could just state that hasflag :count  uses i;ascii-numeric instead 
> of i;ascii-casemap.

This is possbile, but I think for all other tests the default comparator 
doesn't depend on match type.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VGsh7I093556; Tue, 31 Jan 2006 08:54:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0VGshPn093555; Tue, 31 Jan 2006 08:54:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.82]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VGsgSu093549 for <[e-mail]>; Tue, 31 Jan 2006 08:54:43 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.137.143] (69-171-17-197.kntnny.adelphia.net [69.171.17.197]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.4/8.13.4) with ESMTP id k0VGsgcT019515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 31 Jan 2006 11:54:42 -0500
Message-ID: <[e-mail]>
Date: Tue, 31 Jan 2006 11:54:40 -0500
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Imapflags "hasflag" test interaction with relational draft
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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:
> 
> Ken Murchison has asked me how "hasflag" test interacts with relational 
> extension.
> 
> hasflag :count will count the number of different flags in a variable.
> So
> hasflag :count "ge" "MyVariable" "5"
> 
> returns true if the number of different flags in MyVariable is >= "5". 
> However note that the default comparator is i;ascii-casemap and not 
> i;ascii-numeric. I.e. hasflag test doesn't have the comparator 
> parameter. Does anybody see any value in adding the comparator parameter 
> to hasflag test?

No.  RELATIONAL already requires the presence of i;ascii-numeric, so you 
could just state that hasflag :count  uses i;ascii-numeric instead of 
i;ascii-casemap.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VFL7ut080786; Tue, 31 Jan 2006 07:21:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0VFL7o7080785; Tue, 31 Jan 2006 07:21:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0VFL6UR080776 for <[e-mail]>; Tue, 31 Jan 2006 07:21:06 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 31 Jan 2006 15:21:03 +0000
Message-ID: <[e-mail]>
Date: Tue, 31 Jan 2006 15:21:03 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Imapflags "hasflag" test interaction with relational draft
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>

Ken Murchison has asked me how "hasflag" test interacts with relational 
extension.

hasflag :count will count the number of different flags in a variable.
So
hasflag :count "ge" "MyVariable" "5"

returns true if the number of different flags in MyVariable is >= "5". 
However note that the default comparator is i;ascii-casemap and not 
i;ascii-numeric. I.e. hasflag test doesn't have the comparator 
parameter. Does anybody see any value in adding the comparator parameter 
to hasflag test?

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0RMgZRR097829; Fri, 27 Jan 2006 14:42:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0RMgZpc097828; Fri, 27 Jan 2006 14:42:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0RMgYiv097821 for <[e-mail]>; Fri, 27 Jan 2006 14:42:34 -0800 (PST) (envelope-from [e-mail])
Received: by MSA with id 586FB51C5E0E8EFDBEFA516D85CC308034D83D79
Received: from [192.168.0.103] (ppp52-adsl-21.ath.forthnet.gr [62.1.107.21]) (authenticated bits=0) by msa.uoa.gr (8.12.11/8.12.11) with ESMTP id k0RMgRMU018576 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 28 Jan 2006 00:42:28 +0200 (EET)
Subject: Re: Central Sieve homepage
From: Alexandros Vellis <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: [e-mail]
In-Reply-To: <1138400834.17389.3.camel@localhost>
References: <1138336476.21043.48.camel@localhost> <[e-mail]> <1138400834.17389.3.camel@localhost>
Content-Type: text/plain
Organization: National & Kapodistrian University of Athens
Date: Sat, 28 Jan 2006 00:42:25 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UoAMSAId: 586FB51C5E0E8EFDBEFA516D85CC308034D83D79
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, 2006-01-27 at 14:27 -0800, Aaron Stone wrote:
> Oh, what about imc.org? Like, imc.org/sieve?

No problem, if they can offer adequate ways to access and edit content
in their servers.

BTW using Sourceforge is not a bad idea, because it will be independent
of any entity and will allow many people to participate and contribute.

I will try to update the pages I have resurrected, so that we'll have a
starting point.

-- 
Alexandros Vellis
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0RMKVwL097015; Fri, 27 Jan 2006 14:20:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0RMKVdQ097014; Fri, 27 Jan 2006 14:20:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0RMKU96097008 for <[e-mail]>; Fri, 27 Jan 2006 14:20:30 -0800 (PST) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id 55DF6601244B; Fri, 27 Jan 2006 14:20:28 -0800 (PST)
Received: from [192.168.0.4] (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with ESMTP id D84AF601893D; Fri, 27 Jan 2006 14:20:21 -0800 (PST)
Subject: Re: Central Sieve homepage
From: Aaron Stone <[e-mail]>
To: Alexandros Vellis <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <1138336476.21043.48.camel@localhost> <[e-mail]>
Content-Type: text/plain
Date: Fri, 27 Jan 2006 14:27:14 -0800
Message-Id: <1138400834.17389.3.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: !DSPAM:43da9cab186662141596903!
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>

Oh, what about imc.org? Like, imc.org/sieve?

We might also ask that a separate Sieve section be made on the page
http://www.imc.org/rfcs.html what with the Sieve extensions each
becoming its own RFC.

Aaron

On Fri, 2006-01-27 at 23:15 +0200, Alexandros Vellis wrote:
> Aaron Stone wrote:
> > Since the demise of Cyrusoft, is there a new central information webpage
> > with resourcs about Sieve? If not, I'd like to propose that sieve.sf.net
> > be registered as used as such. An open wiki, ala freedesktop.org, would
> > probably serve well as information store.
> 
> I started an attempt to make a site that has up-to-date information,
> starting with the existing document that Cyrus Daboo was maintaining. My
> effort is at http://email.uoa.gr/sieve/ . I wanted to update the document
> with extensive information about implementations and links to current
> drafts through the ietfreport.isoc.org site. Unfortunately I had other
> time-consuming things that kept me from it in the meantime.
> 
> If you agree with the effort, I can take the responsibility and make it
> up-to-date. I can also add a wiki or other tools according to popular
> demand.
> 
> There is also the wiki page at fastmail.fm that describes implementations
> of the various extensions and capabilities.
> 
> I know the domain name I have is not the greatest, perhaps we can change
> it. (sieve.info is very good and available ;) )
> 
> Alexandros
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0RLFDuM093611; Fri, 27 Jan 2006 13:15:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0RLFDVW093610; Fri, 27 Jan 2006 13:15:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0RLFBXO093597 for <[e-mail]>; Fri, 27 Jan 2006 13:15:12 -0800 (PST) (envelope-from [e-mail])
Received: by MSA with id 5DD208B01622D46C2FA84CB614E0AC81A461FDEC
Received: from webmail.noc.uoa.gr (webmail.noc.uoa.gr [195.134.100.73]) by msa.uoa.gr (8.12.11/8.12.11) with ESMTP id k0RLF4Rc018317; Fri, 27 Jan 2006 23:15:04 +0200 (EET)
Received: from 62.1.107.21 (SquirrelMail authenticated user avel) by webmail.uoa.gr with HTTP; Fri, 27 Jan 2006 23:15:04 +0200 (EET)
Message-ID: <[e-mail]>
In-Reply-To: <1138336476.21043.48.camel@localhost>
References: <1138336476.21043.48.camel@localhost>
Date: Fri, 27 Jan 2006 23:15:04 +0200 (EET)
Subject: Re: Central Sieve homepage
From: "Alexandros Vellis" <[e-mail]>
To: "Aaron Stone" <[e-mail]>
Cc: [e-mail]
User-Agent: SquirrelMail/1.4.6 [CVS] [http://email.uoa.gr]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-7
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-UoAMSAId: 5DD208B01622D46C2FA84CB614E0AC81A461FDEC
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>

Aaron Stone wrote:
> Since the demise of Cyrusoft, is there a new central information webpage
> with resourcs about Sieve? If not, I'd like to propose that sieve.sf.net
> be registered as used as such. An open wiki, ala freedesktop.org, would
> probably serve well as information store.

I started an attempt to make a site that has up-to-date information,
starting with the existing document that Cyrus Daboo was maintaining. My
effort is at http://email.uoa.gr/sieve/ . I wanted to update the document
with extensive information about implementations and links to current
drafts through the ietfreport.isoc.org site. Unfortunately I had other
time-consuming things that kept me from it in the meantime.

If you agree with the effort, I can take the responsibility and make it
up-to-date. I can also add a wiki or other tools according to popular
demand.

There is also the wiki page at fastmail.fm that describes implementations
of the various extensions and capabilities.

I know the domain name I have is not the greatest, perhaps we can change
it. (sieve.info is very good and available ;) )

Alexandros



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0R4RjW2019159; Thu, 26 Jan 2006 20:27:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0R4RjWC019158; Thu, 26 Jan 2006 20:27:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0R4RiJw019148 for <[e-mail]>; Thu, 26 Jan 2006 20:27:44 -0800 (PST) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id 4F93C601244B; Thu, 26 Jan 2006 20:27:42 -0800 (PST)
Received: from [192.168.0.4] (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with ESMTP id 0DDB8601893D for <[e-mail]>; Thu, 26 Jan 2006 20:27:41 -0800 (PST)
Subject: Central Sieve homepage
From: Aaron Stone <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Date: Thu, 26 Jan 2006 20:34:36 -0800
Message-Id: <1138336476.21043.48.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: !DSPAM:43d9a13e177361515062736!
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>

Since the demise of Cyrusoft, is there a new central information webpage
with resourcs about Sieve? If not, I'd like to propose that sieve.sf.net
be registered as used as such. An open wiki, ala freedesktop.org, would
probably serve well as information store.

Aaron



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0P1eLkY061893; Tue, 24 Jan 2006 17:40:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0P1eLYw061892; Tue, 24 Jan 2006 17:40:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from eastrmmtao04.cox.net (eastrmmtao04.cox.net [68.230.240.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0P1eJrB061885 for <[e-mail]>; Tue, 24 Jan 2006 17:40:19 -0800 (PST) (envelope-from [e-mail])
Received: from charger ([68.100.55.187]) by eastrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060125014016.JYMI19943.eastrmmtao04.cox.net@charger>; Tue, 24 Jan 2006 20:40:16 -0500
From: "Scott Hollenbeck" <[e-mail]>
To: "'Cyrus Daboo'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: IESG Review of draft-ietf-sieve-vacation
Date: Tue, 24 Jan 2006 20:40:13 -0500
Message-ID: <000501c62150$49647b20$0623520a@charger>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-reply-to: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-index: AcYhSNAj72awSETkSJ68FTtXXhplrgAB03Jw
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>

> -----Original Message-----
> From: Cyrus Daboo [mailto:[e-mail]] 
> Sent: Tuesday, January 24, 2006 7:47 PM
> To: Scott Hollenbeck; 'Ned Freed'
> Cc: [e-mail]
> Subject: RE: IESG Review of draft-ietf-sieve-vacation
> 
> Hi Scott,
> 
> --On January 19, 2006 1:46:00 PM -0500 Scott Hollenbeck 
> <[e-mail]> wrote:
> 
> > Thanks for the note, Ned.  It leads me to two more specific 
> questions:
> >
> > Does the document need to describe the issues noted below in an 
> > Internationalization Considerations section?  It might make sense.
> 
> My feeling is that what Ned described would be better off 
> being put in the base spec revision rather than vacation, 
> since its is applicable to base spec actions and other 
> extensions too. i.e. we don't need to add this directly to 
> vacation itself.
> 
> What do others on the list think?

That seems like a reasonable approach.  If others agree, can it be captured
as an issue to be addressed?

-Scott-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0P0kjGv058210; Tue, 24 Jan 2006 16:46:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0P0kjCe058209; Tue, 24 Jan 2006 16:46:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0P0kh8M058203 for <[e-mail]>; Tue, 24 Jan 2006 16:46:44 -0800 (PST) (envelope-from [e-mail])
Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id C81CCD2FB43; Tue, 24 Jan 2006 19:46:39 -0500 (EST)
Received: from frontend2.messagingengine.com ([10.202.2.151]) by frontend1.internal (MEProxy); Tue, 24 Jan 2006 19:46:39 -0500
X-Sasl-enc: +Vav9aHYTaXSC3ys5InEiiMFVPQl1zyMLh+OLZlgKmjE 1138149998
Received: from [10.0.1.2] (unknown [66.90.11.67]) by www.fastmail.fm (Postfix) with ESMTP id 3F42A57146F; Tue, 24 Jan 2006 19:46:36 -0500 (EST)
Date: Tue, 24 Jan 2006 19:46:39 -0500
From: Cyrus Daboo <[e-mail]>
To: Scott Hollenbeck <[e-mail]>, "'Ned Freed'" <[e-mail]>
cc: [e-mail]
Subject: RE: IESG Review of draft-ietf-sieve-vacation
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 Scott,

--On January 19, 2006 1:46:00 PM -0500 Scott Hollenbeck 
<[e-mail]> wrote:

> Thanks for the note, Ned.  It leads me to two more specific questions:
>
> Does the document need to describe the issues noted below in an
> Internationalization Considerations section?  It might make sense.

My feeling is that what Ned described would be better off being put in the 
base spec revision rather than vacation, since its is applicable to base 
spec actions and other extensions too. i.e. we don't need to add this 
directly to vacation itself.

What do others on the list think?

-- 
Cyrus Daboo



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0OMJNUw036277; Tue, 24 Jan 2006 14:19:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0OMJNJH036276; Tue, 24 Jan 2006 14:19:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0OMJKIL036239 for <[e-mail]>; Tue, 24 Jan 2006 14:19:20 -0800 (PST) (envelope-from [e-mail])
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F1WVS-00065h-UP; Tue, 24 Jan 2006 17:19:18 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, sieve mailing list <[e-mail]>, sieve chair <[e-mail]>, sieve chair <[e-mail]>
Subject: Protocol Action: 'Sieve Extension: Variables' to Proposed  Standard 
Message-Id: <[e-mail]>
Date: Tue, 24 Jan 2006 17:19:18 -0500
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>

The IESG has approved the following document:

- 'Sieve Extension: Variables '
   <draft-ietf-sieve-variables-08.txt> as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working 
Group. 

The IESG contact persons are Scott Hollenbeck and Ted Hardie.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-08.txt

Technical Summary

In advanced mail filtering rule sets, it is useful to keep state or
configuration details across rules.  This extension to the filtering
language Sieve changes the interpretation of strings, adds an action
to store data in variables, and supplies a new test so that the value
of a string can be examined.  This document updates RFC 3028.

Working Group Summary
 
The discussion about adding variables to the SIEVE mail filtering
language started 4-5 years ago during development of the IMAP flags
extension to SIEVE. The latter has been using a single implicit global
variable and several mailing list participants have expressed their wish
to have a more generic method of keeping state or configuration details
across rules. The ability to extract matching material from header fields
and perform further tests on it has also proven to be very useful. This
became even more apparent when the SIEVE regular expression draft was
written.

The document is minimalistic in its approach: several less used features
like automatically set current date/time variables got dropped from the 
document.

There was a discussion about having read-only variables automatically
set from different RFC 2822 message headers. There was no consensus to
add this to the document.

There was a discussion about having locally scoped variables. The
general feeling was that this feature complicates implementations quite
a bit for a feature very few Sieve scripts will find use for. So there
was no consensus to add this to the document, however, should the need
arise, it would be possible to add locally scoped variables as an 
extension.

Several WG members have proposed adding associative arrays. Some people
felt that this might be useful, but it will introduce extra implementation
complexity and could lead to implementation bugs. The WG has decided that
this can be postponed till later; the current "variables" document
doesn't prohibit this.
 
Protocol Quality

The WG asked the Security Area to perform a review of the document.
Two changes to the document has been done as the result of the review:
additional text in Security Considerations about silent truncation of
big values and an additional :quotewildcard modifier which gives a
convenient way to escape special matching characters in strings. Both
changes were discussed in details on the mailing list and have WG
consensus behind them.

There are already several implementations of the variables extension in
servers and more people have indicated that they are planning to 
implement it.
 
Scott Hollenbeck has reviewed this specification for the IESG.  Love
Hornquist Astrand and Jeffrey Hutzelman performed a security review
of the document.

Note to the RFC Editor

Please remove Section 0 from the document.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KKo6Er012778; Fri, 20 Jan 2006 12:50:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0KKo6jI012777; Fri, 20 Jan 2006 12:50:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KKo6PK012771 for <[e-mail]>; Fri, 20 Jan 2006 12:50:06 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F03Cs-0003UZ-Hz; Fri, 20 Jan 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-spamtestbis-02.txt 
Message-Id: <[e-mail]>
Date: Fri, 20 Jan 2006 15:50:02 -0500
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: Spamtest and Virustest Extensions
	Author(s)	: C. Daboo
	Filename	: draft-ietf-sieve-spamtestbis-02.txt
	Pages		: 12
	Date		: 2006-1-20
	
The SIEVE email filtering language "spamtest", "spamtestplus" and
   "virustest" extensions permit users to use simple, portable commands
   for spam and virus tests on email messages.  Each extension provides
   a new test using matches against numeric 'scores'.  It is the
   responsibility of the underlying SIEVE implementation to do the
   actual checks that result in values returned by the tests.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-spamtestbis-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-spamtestbis-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-spamtestbis-02.txt

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

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

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KKo4Ux012760; Fri, 20 Jan 2006 12:50:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0KKo46l012759; Fri, 20 Jan 2006 12:50:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KKo3pd012753 for <[e-mail]>; Fri, 20 Jan 2006 12:50:03 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F03Cs-0003UT-H6; Fri, 20 Jan 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-imapflags-03.txt 
Message-Id: <[e-mail]>
Date: Fri, 20 Jan 2006 15:50:02 -0500
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: IMAP flag Extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-sieve-imapflags-03.txt
	Pages		: 0
	Date		: 2006-1-20
	
Recent discussions have shown that it is desirable to set different
   [IMAP] flags on message delivery.  This can be done, for example,
   by a Sieve interpreter that works as a part of a Mail Delivery
   Agent.

   This document describes an extension to the Sieve mail filtering
   language for setting [IMAP] flags. The extension allows to set both
   [IMAP] system flags and [IMAP] keywords.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-imapflags-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-imapflags-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-imapflags-03.txt

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

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

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JIis7h072308; Thu, 19 Jan 2006 10:44:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0JIisI5072307; Thu, 19 Jan 2006 10:44:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zeke.ecotroph.net (zeke.hxr.us [69.31.8.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JIiqjA072297 for <[e-mail]>; Thu, 19 Jan 2006 10:44:52 -0800 (PST) (envelope-from [e-mail])
Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Thu, 19 Jan 2006 13:44:15 -0500 id 0158806E.43CFDDFF.0000130E
From: "Scott Hollenbeck" <[e-mail]>
To: "'Ned Freed'" <[e-mail]>
Cc: [e-mail]
Subject: RE: IESG Review of draft-ietf-sieve-vacation
Date: Thu, 19 Jan 2006 13:46:00 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-reply-to: <[e-mail]>
Thread-Index: AcYdJmu6iUg0Ka6FRx+uOQhKSJuzOQAARgvA
Message-ID: <[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>

Thanks for the note, Ned.  It leads me to two more specific questions:

Does the document need to describe the issues noted below in an
Internationalization Considerations section?  It might make sense.

Are there any normative dependencies to existing i18n RFCs or I-Ds?  I'm not
so sure.

-Scott-

> -----Original Message-----
> From: Ned Freed [mailto:[e-mail]] 
> Sent: Thursday, January 19, 2006 12:36 PM
> To: Scott Hollenbeck
> Cc: [e-mail]
> Subject: Re: IESG Review of draft-ietf-sieve-vacation
> 
> 
> > The discuss that has been shared with the document shepherd 
> is still in
> > place.  I need text from Cyrus (the document shepherd, 
> coordinated as
> > appropriate) to resolve that minor issue.  Details in the 
> I-D tracker:
> 
> > 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=1300
> > 5
> 
> > Perhaps more importantly, an AD asked about internationalization
> > considerations.  What are the i18n implications of 
> displaying the fields
> > specified in the protocol?
> 
> As posed the question is next to impossible to answer. The 
> vacation extension
> provides a means of constructing a fairly arbitary email 
> message, one which can
> include, among other things, multipart/alternative objects 
> containing material
> in different languages. "Displaying the fields" therefore 
> equates to how email
> messages in general are displayed, and you could write a 
> thousand pages on that
> particular topic and not even scratch the surface.
> 
> Now, as it happens our implementation of vacation sees heavy 
> use with various
> ISPs and enterprises that have serious multilingual support 
> requirements. So
> internationalized use of vacation is something I happen to 
> have a large amount
> of experience with. The main internationalization issue that 
> actually arises
> in practice is given the availability of vacation responses 
> in multiple
> languages, what's the best way to select one to use?
> 
> One way to do it is to use out-of-band information, such as a 
> preferredlanguage
> attribute in an LDAP entry associated with the message 
> originator, to generate
> a one-time sieve script containing appropriately selected 
> text. This only works
> when such out-of-band information is available, of course, 
> and it fails to deal
> with the fact that selecting appropriate text also needs to 
> be able to cope
> with things like sending different text to a fellow employee 
> versus to a total
> stranger.
> 
> This then argues strongly for handling internationalized text 
> selection in the
> sieve script itself. It is a trivial matter to have a script test the
> preferred-language or content-language header field and take action
> accordingly. These tests can then be coupled with additional 
> decision-making
> logic as needed to generate an appropriate vacation resonse 
> (or not, as the
> case may be).
> 
> GUI interfaces that generate sieve scripts can be used to 
> hide the complexity
> of much of this from end users. Figuring out the right set of 
> options to
> present in a GUI is a nontrivial proposition, but more 
> because of the need to
> send different sorts of responses to different classes of 
> people than because
> of the issues involved in selecting a response in an 
> appropriate language.
> 
> Of course one approach is to simply use 
> multipart/alternative, as I mentioned
> previously. For whatever reason this approach isn't terribly 
> popular with our
> customers. I could speculate at length as to why this is so, 
> but I don't see
> such speculation as relevant to the matter at hand. The key 
> point here is that
> in practice we successully use sieve vacation in very demanding
> internationalized environments all the time.
> 
> 				Ned
> 
> P.S. A legitimate question to ask is whether or not end users 
> are actually
> prepared to write their messages in multiple languages. AFAIK 
> we don't see much
> of that with US customers - no surprise there - but you'd be 
> surprised how many
> end users take advantage of the capability in countries like Japan.
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JIUOjd070814; Thu, 19 Jan 2006 10:30:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0JIUOiZ070813; Thu, 19 Jan 2006 10:30:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JIUL5p070803 for <[e-mail]>; Thu, 19 Jan 2006 10:30:23 -0800 (PST) (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, 19 Jan 2006 10:30:16 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1137695416; h=Date: 	 From:Subject:MIME-version:Content-type; b=C/q4wkrNOu8DkIA7haEoxy9TO eOMkfqItDLS2isqDInMdw3qggvSR3eYXG5qrQkvHwQa/ookBypobeG+NLxARw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 19 Jan 2006 10:30:14 -0800 (PST)
Cc: [e-mail]
To: Scott Hollenbeck <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 19 Jan 2006 09:36:24 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: IESG Review of draft-ietf-sieve-vacation
In-reply-to: "Your message dated Thu, 19 Jan 2006 12:00:23 -0500" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
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>

> The discuss that has been shared with the document shepherd is still in
> place.  I need text from Cyrus (the document shepherd, coordinated as
> appropriate) to resolve that minor issue.  Details in the I-D tracker:

> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1300
> 5

> Perhaps more importantly, an AD asked about internationalization
> considerations.  What are the i18n implications of displaying the fields
> specified in the protocol?

As posed the question is next to impossible to answer. The vacation extension
provides a means of constructing a fairly arbitary email message, one which can
include, among other things, multipart/alternative objects containing material
in different languages. "Displaying the fields" therefore equates to how email
messages in general are displayed, and you could write a thousand pages on that
particular topic and not even scratch the surface.

Now, as it happens our implementation of vacation sees heavy use with various
ISPs and enterprises that have serious multilingual support requirements. So
internationalized use of vacation is something I happen to have a large amount
of experience with. The main internationalization issue that actually arises
in practice is given the availability of vacation responses in multiple
languages, what's the best way to select one to use?

One way to do it is to use out-of-band information, such as a preferredlanguage
attribute in an LDAP entry associated with the message originator, to generate
a one-time sieve script containing appropriately selected text. This only works
when such out-of-band information is available, of course, and it fails to deal
with the fact that selecting appropriate text also needs to be able to cope
with things like sending different text to a fellow employee versus to a total
stranger.

This then argues strongly for handling internationalized text selection in the
sieve script itself. It is a trivial matter to have a script test the
preferred-language or content-language header field and take action
accordingly. These tests can then be coupled with additional decision-making
logic as needed to generate an appropriate vacation resonse (or not, as the
case may be).

GUI interfaces that generate sieve scripts can be used to hide the complexity
of much of this from end users. Figuring out the right set of options to
present in a GUI is a nontrivial proposition, but more because of the need to
send different sorts of responses to different classes of people than because
of the issues involved in selecting a response in an appropriate language.

Of course one approach is to simply use multipart/alternative, as I mentioned
previously. For whatever reason this approach isn't terribly popular with our
customers. I could speculate at length as to why this is so, but I don't see
such speculation as relevant to the matter at hand. The key point here is that
in practice we successully use sieve vacation in very demanding
internationalized environments all the time.

				Ned

P.S. A legitimate question to ask is whether or not end users are actually
prepared to write their messages in multiple languages. AFAIK we don't see much
of that with US customers - no surprise there - but you'd be surprised how many
end users take advantage of the capability in countries like Japan.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JGxGoC064121; Thu, 19 Jan 2006 08:59:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0JGxG8D064120; Thu, 19 Jan 2006 08:59:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zeke.ecotroph.net (zeke.ecotroph.NET [69.31.8.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JGxFAI064113 for <[e-mail]>; Thu, 19 Jan 2006 08:59:15 -0800 (PST) (envelope-from [e-mail])
Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Thu, 19 Jan 2006 11:58:38 -0500 id 0158806C.43CFC53E.00007C3B
From: "Scott Hollenbeck" <[e-mail]>
To: [e-mail]
Subject: IESG Review of draft-ietf-sieve-vacation
Date: Thu, 19 Jan 2006 12:00:23 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcYdGdZ52qml7eihQyKZBqfTVxCiDw==
Message-ID: <[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>

The discuss that has been shared with the document shepherd is still in
place.  I need text from Cyrus (the document shepherd, coordinated as
appropriate) to resolve that minor issue.  Details in the I-D tracker:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=1300
5

Perhaps more importantly, an AD asked about internationalization
considerations.  What are the i18n implications of displaying the fields
specified in the protocol?

-Scott-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IKo3rt077507; Wed, 18 Jan 2006 12:50:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0IKo3XF077505; Wed, 18 Jan 2006 12:50:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IKo2gc077491 for <[e-mail]>; Wed, 18 Jan 2006 12:50:02 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EzKFm-0007It-2o; Wed, 18 Jan 2006 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-notify-xmpp-00.txt 
Message-Id: <[e-mail]>
Date: Wed, 18 Jan 2006 15:50:02 -0500
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 Notification Mechanism: xmpp
	Author(s)	: P. Saint-Andre, A. Melnikov
	Filename	: draft-ietf-sieve-notify-xmpp-00.txt
	Pages		: 7
	Date		: 2006-1-18
	
   This document describes a profile of the Sieve extension for
   notifications, to allow notifications to be sent over the Extensible
   Messaging and Presence Protocol (XMPP), also known as Jabber.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-notify-xmpp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-notify-xmpp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-notify-xmpp-00.txt

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

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

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0GDuZUO016360; Mon, 16 Jan 2006 05:56:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0GDuZEq016359; Mon, 16 Jan 2006 05:56:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0GDuYpC016322 for <[e-mail]>; Mon, 16 Jan 2006 05:56:35 -0800 (PST) (envelope-from [e-mail])
Received: by MSA with id FC68A3BDAB2231CC8FC6821B867F81881BEF7449
Received: from null.noc.uoa.gr (null.noc.uoa.gr [195.134.100.40]) (authenticated bits=0) by msa.uoa.gr (8.12.11/8.12.11) with ESMTP id k0GDuKiq002852 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 16 Jan 2006 15:56:20 +0200 (EET)
Subject: Re: "Any header" test - possible?
From: Alexandros Vellis <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Organization: National & Kapodistrian University of Athens
Date: Mon, 16 Jan 2006 15:57:12 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UoAMSAId: FC68A3BDAB2231CC8FC6821B867F81881BEF7449
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, 2006-01-16 at 13:47 +0000, Alexey Melnikov wrote:

> I don't think so.
> Can you describe a use-case for this feature in more details?

I don't have a specific scenario.

I am only doing a simple mapping of IMAP SEARCH commands to Sieve
filtering rules, for the purpose of some GUI convenience: In your MUA,
do a search in your folders, and with just two clicks add the same
criteria in your Sieve script.

Among other things, IMAP SEARCH has the argument:

   TEXT <string>
        Messages that contain the specified string in the header or
        body of the message.

So it seems that this cannot really be specified as Sieve?

I was thinking along the line

    anyof( :body :contains 'foo' , :header _:all?_ :contains 'foo')


-- 
Alexandros Vellis
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0GDlGeO013610; Mon, 16 Jan 2006 05:47:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0GDlGK4013609; Mon, 16 Jan 2006 05:47:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0GDlFqe013598 for <[e-mail]>; Mon, 16 Jan 2006 05:47:16 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 16 Jan 2006 13:47:03 +0000
Message-ID: <[e-mail]>
Date: Mon, 16 Jan 2006 13:47:00 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Alexandros Vellis <[e-mail]>
CC: [e-mail]
Subject: Re: "Any header" test - possible?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Alexandros Vellis wrote:

>I am wondering how I could check for e.g. the existence of some text in
>*any* header.  [With the text not being an email address so
>that :address test is not what I really want].
>
>RFC3028 (+bis) would imply that this is not possible. string-list that
>is used in header-list has to have at least one string:
>
>string-list = "[" string *("," string) "]" / string
>                   ; if there is only a single string, the brackets
>                   ; are optional
>
>So saying
>
>  header :contains [] "some text"
>
>or 
>
>  header :contains "some text"
>
>,implying to match any header, is not valid.
>
>So, is it possible to do what I want in Sieve?
>  
>
I don't think so.
Can you describe a use-case for this feature in more details?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0GBNifN055769; Mon, 16 Jan 2006 03:23:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0GBNier055767; Mon, 16 Jan 2006 03:23:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0GBNhAK055670 for <[e-mail]>; Mon, 16 Jan 2006 03:23:44 -0800 (PST) (envelope-from [e-mail])
Received: by MSA with id F6A06BA153BBDED99A5D75FE4D05BEE0A1D36D51
Received: from null.noc.uoa.gr (null.noc.uoa.gr [195.134.100.40]) (authenticated bits=0) by msa.uoa.gr (8.12.11/8.12.11) with ESMTP id k0GBNa1d029413 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Mon, 16 Jan 2006 13:23:36 +0200 (EET)
Subject: "Any header" test - possible?
From: Alexandros Vellis <[e-mail]>
To: [e-mail]
Content-Type: text/plain
Organization: National & Kapodistrian University of Athens
Date: Mon, 16 Jan 2006 13:24:28 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UoAMSAId: F6A06BA153BBDED99A5D75FE4D05BEE0A1D36D51
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 am wondering how I could check for e.g. the existence of some text in
*any* header.  [With the text not being an email address so
that :address test is not what I really want].

RFC3028 (+bis) would imply that this is not possible. string-list that
is used in header-list has to have at least one string:

string-list = "[" string *("," string) "]" / string
                   ; if there is only a single string, the brackets
                   ; are optional

So saying

  header :contains [] "some text"

or 

  header :contains "some text"

,implying to match any header, is not valid.

So, is it possible to do what I want in Sieve?

-- 
Alexandros Vellis
[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0D9ItHr031345; Fri, 13 Jan 2006 01:18:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0D9ItdX031344; Fri, 13 Jan 2006 01:18:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0D9IsW4031338 for <[e-mail]>; Fri, 13 Jan 2006 01:18:55 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1ExL5B-0004oD-8j for [e-mail]; Fri, 13 Jan 2006 10:18:53 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #21) id 1ExL5B-00014t-68 for [e-mail]; Fri, 13 Jan 2006 10:18:53 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61 #35) id 1ExL56-0001XS-FN for [e-mail]; Fri, 13 Jan 2006 10:18:48 +0100
Date: Fri, 13 Jan 2006 10:18:48 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: testing for extensions during run-time
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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, Jan 12, 2006 at 03:22:59PM -0500, Barry Leiba wrote:
> If I should move that script to a system that doesn't support
> notify, I might still want it to "work", in that I'd want it to do
> everything except the pager bit.

Ok, so the focus of this new test, whatever we call it, is to enhance
script portability.  I use Sieve in a number of places, but all scripts
are so different that portability is the least I would think of.
Your applications are obviously very different.

> then I get what I want, and I don't have to change the script.  And if,
> some say, my system adds support for notify, I'll start getting paged
> without having to find out that it's been upgraded, and without having
> to put the notify code back into the script.

Not something I would like.  Out of a sudden previously dead code
gets active.  My phone number might have changed and now someone else
gets my notifications (my fault).  There may be a semantic mistake in
the previously dead code, something managesieve could not check before,
and now that it is active, it causes an error and my script terminates,
leaving a mess to be discovered when coming back from vacation.

To me, we are talking about two different issues, and "environment"
as we talk about it, combines them in an unfortunate way.  I prefer to
put different things in different extensions:

o  Getting to know which extensions are supported.  For your applications,
   a Sieve extension is useful.  For mine, something like managesieve,
   although I would never implement it, is more suitable.  Ok, I see no
   problem there.  "environment" may be good solution for Sieve and
   any sieve implementation certainly had no problem to support that.

o  Having a way of not letting unknown extensions cause script failure.
   But why restrict that to unknown extensions? How about exception
   handling, something like "try & catch"? That does not only catch
   semantic errors at the action level, but also at the argument/option
   level.  Your "if" test above only catches the first.

I don't think I need either, but a new extension that looks like a
test and requires the fundamental change from strict to somewhat lazy
error checking sounds very wrong to me.  Exceptions may not be the best
solution, but at least you expect them to change error handling, and
they do so universally.

Unfortunately, the case spec forbids:

  try { require "notify"; } catch { }

The "require" statement is only allowed at the beginning of scripts.
Too bad.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0D29uKW084650; Thu, 12 Jan 2006 18:09:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0D29ucB084649; Thu, 12 Jan 2006 18:09:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0D29ttl084640 for <[e-mail]>; Thu, 12 Jan 2006 18:09:56 -0800 (PST) (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, 12 Jan 2006 18:09:50 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1137118190; h=Date: 	 From:Subject:MIME-version:Content-type; b=M6Hr1uWVC45ixHiekb7dYjCig KEr7SNid46L+amVEVQ2dNRljY+7UeiZiKrVCkAzTFYMocHH09AHa6yFdhz3sg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 12 Jan 2006 18:09:48 -0800 (PST)
Cc: Ned Freed <[e-mail]>, [e-mail]
To: Aaron Stone <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 12 Jan 2006 18:09:17 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: testing for extensions during run-time
In-reply-to: "Your message dated Thu, 12 Jan 2006 17:26:37 -0800" <1137115597.5822.164.camel@localhost>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1137115597.5822.164.camel@localhost>
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, 2006-01-12 at 14:24 -0800, Ned Freed wrote:

> > Well, there has been talk about having some way in managesieve to get the list
> > of supported extensions, but AFAIK it has never made it into an actual
> > specification. Of course this may be more a result of no work having been done
> > on managesieve recently than anything else.

> I thought there was a CAPABILITY command... there certainly is in my
> implementation ;-)  Capabilities are presented in the greeting, too!

Forgot about that, sorry.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0D1KWeT080390; Thu, 12 Jan 2006 17:20:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0D1KWC4080389; Thu, 12 Jan 2006 17:20:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0D1KWmr080383 for <[e-mail]>; Thu, 12 Jan 2006 17:20:32 -0800 (PST) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id C1D7E608F7E4; Thu, 12 Jan 2006 17:20:29 -0800 (PST)
Received: from [192.168.0.6] (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with ESMTP id AF121608F7E2; Thu, 12 Jan 2006 17:20:26 -0800 (PST)
Subject: Re: testing for extensions during run-time
From: Aaron Stone <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [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]>
Content-Type: text/plain
Date: Thu, 12 Jan 2006 17:26:37 -0800
Message-Id: <1137115597.5822.164.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: !DSPAM:43c7005d183621025518759!
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, 2006-01-12 at 14:24 -0800, Ned Freed wrote:

> Well, there has been talk about having some way in managesieve to get the list
> of supported extensions, but AFAIK it has never made it into an actual
> specification. Of course this may be more a result of no work having been done
> on managesieve recently than anything else.

I thought there was a CAPABILITY command... there certainly is in my
implementation ;-)  Capabilities are presented in the greeting, too!

Aaron



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CNkJxx070193; Thu, 12 Jan 2006 15:46:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0CNkJq8070192; Thu, 12 Jan 2006 15:46:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CNkJEt070185 for <[e-mail]>; Thu, 12 Jan 2006 15:46:19 -0800 (PST) (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, 12 Jan 2006 15:46:02 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1137109562; h=Date: 	 From:Subject:MIME-version:Content-type; b=IzXFOMBzuS4MKMIQasWtqhDmC gV3ks8C98M86BW37UcqecMrAE5fyGeTvijmt3ckg5KeH69p5YxR3LlDVNdo2Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 12 Jan 2006 15:45:59 -0800 (PST)
Cc: [e-mail]
To: Barry Leiba <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 12 Jan 2006 14:24:27 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: testing for extensions during run-time
In-reply-to: "Your message dated Thu, 12 Jan 2006 15:22:59 -0500" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[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>

> Michael Haardt wrote:
> >>   if environment "extensions" "notify" {
> >>      ....
> >>   }
> >
> > I must be missing something, but why would you want to write scripts
> > that way? Which application would profit from this extension?
> >
> > I can imagine that a way to find out which extensions are available
> > is very useful for GUIs generating Sieve code, or even humans, but
> > for scripts?

> Well, the point of Sieve is for the scripts to be portable.  Ideally,
> I should be able to move a script from one environment to another,
> and it would still work.

> But now we have to consider the meaning of "work" [or "is" (it's a US
> politics joke; never mind)].  Suppose that a script was designed to
> to a whole bunch of stuff, using fileinto and redirect and whatnot,
> and then at the end it just wants to say, "OK, if, after all this,
> the message is going into a mailbox called "important", and the
> notify extension is available, then notify the recipient by pager.

> If I should move that script to a system that doesn't support
> notify, I might still want it to "work", in that I'd want it to do
> everything except the pager bit.  But if the script be coded thus:

>    require "environment", "fileinto", "notify"
>    ...
>    [do all the useful work]
>    ...
>    notify [...]

> then it will fail completely when it's run somewhere that doesn't
> support notify.  If I have the option of coding it this way:

>    require "environment", "fileinto"
>    ...
>    [do all the useful work]
>    ...
>    if environment "extensions" "notify" {
>      notify [...]
>    }

> then I get what I want, and I don't have to change the script.

I like this way of doing it. The "want" business used in an earlier example
didn't feel right, but this does.

There is precedent for this sort of thing, BTW. PostScript has the ability to
check for support for various extensions and only use them if they're
supported. (Or alternately, provide a different way to do something.) This
functionality used to be used a fair amount, although I haven't seen much of it
recently.

> And if,
> some say, my system adds support for notify, I'll start getting paged
> without having to find out that it's been upgraded, and without having
> to put the notify code back into the script.

Yes, although this does have a negative aspect - an upgrade changes behavior
and actives old code someone forgot was even there. This issue would certainly
need to be discussed in any specification we write.

> > If I used a GUI and it offers notifications, then I expect they are
> > available.

> (1) You're ignoring the script portability issue.
> (2) I would not make that assumption anyway.  There's no way for a GUI
> to query the Sieve system, and in a mix-and-match world there's no
> reason to assume we'll have bought the Sieve engine from the same
> source as we got the script builder from.

Well, there has been talk about having some way in managesieve to get the list
of supported extensions, but AFAIK it has never made it into an actual
specification. Of course this may be more a result of no work having been done
on managesieve recently than anything else.

> > I don't think the base specification unconditionally allows dead
> > code blocks that contain unknown extensions, like:
> >
> >   if false {
> >      unknown_extension;
> >   }
> >
> > Does the environment extension focus on the above usage and is it OK if
> > it enforces implementations to allow unknown extensions in dead code?

> I'm not sure I understand what you mean by any of that.
> I *think* you're asking whether the error is generated by the parser or
> by the execution, and I believe the answer is "execution".

Er, no. The base specification leaves this open. Implementations are free to
perform as much checking as they want before executing a script. It is
perfectly permissible to check and make sure that the script doesn't reference
any tests or actions that aren't listed in the require clause. Our
implementation does this, as a matter of fact.

The way we'd probably change this is to see if environment is listed  in the
require clause, and if it is disable this sort of checking. There's already a
way to disable this sort of strict checking, so this won't be hard for us to
implement.

I note in passing that only new tests, actions and comparators are amenable.
to this sort of thing. Something like

   if environment "extensions" "variables" ...

makes my head hurt.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CKjBSh049903; Thu, 12 Jan 2006 12:45:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0CKjB7Z049901; Thu, 12 Jan 2006 12:45:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CKjAgV049894 for <[e-mail]>; Thu, 12 Jan 2006 12:45:10 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.43) id 1Ex9Ji-0002uT-BD; Thu, 12 Jan 2006 21:45:06 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1Ex9Jd-0006ch-1E; Thu, 12 Jan 2006 21:45:01 +0100
Subject: Re: testing for extensions during run-time
From: Kjetil Torgrim Homme <[e-mail]>
To: Barry Leiba <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 12 Jan 2006 21:44:59 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.456, required 12, autolearn=disabled, AWL -0.46, UIO_MAIL_IS_INTERNAL -5.00)
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, 2006-01-12 at 15:22 -0500, Barry Leiba wrote:
> Michael Haardt wrote:
> > I don't think the base specification unconditionally allows dead
> > code blocks that contain unknown extensions, like:
> > 
> >   if false {
> >      unknown_extension;
> >   }
> > 
> > Does the environment extension focus on the above usage and is it OK if
> > it enforces implementations to allow unknown extensions in dead code?

this is not the focus of the "environment" extension.  it very well
might better be in a separate extension.

> I'm not sure I understand what you mean by any of that.
> I *think* you're asking whether the error is generated by the parser or
> by the execution, and I believe the answer is "execution".  So if
> "unknown_extension" is never executed, there should be no error.

either is allowed.

   Compile-time errors are ones in syntax that are detectable if a
   syntax check is done.
   [...]
   Implementations MAY choose to do a full parse, then evaluate the
   script, then do all actions.  Implementations might even go so far as
   to ensure that execution is atomic (either all actions are executed
   or none are executed).

-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CKN9fC048310; Thu, 12 Jan 2006 12:23:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0CKN92q048309; Thu, 12 Jan 2006 12:23:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CKN8j6048299 for <[e-mail]>; Thu, 12 Jan 2006 12:23:08 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k0CKPFt5017750 for <[e-mail]>; Thu, 12 Jan 2006 15:25:15 -0500
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k0CKN1k51792 for <[e-mail]>; Thu, 12 Jan 2006 15:23:01 -0500
Received: from [9.2.43.127] (saturn.watson.ibm.com [9.2.43.127]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k0CKN0u395622 for <[e-mail]>; Thu, 12 Jan 2006 15:23:00 -0500
Message-ID: <[e-mail]>
Date: Thu, 12 Jan 2006 15:22:59 -0500
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: testing for extensions during run-time
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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>

Michael Haardt wrote:
>>   if environment "extensions" "notify" {
>>      ....
>>   }
> 
> I must be missing something, but why would you want to write scripts
> that way? Which application would profit from this extension?
> 
> I can imagine that a way to find out which extensions are available
> is very useful for GUIs generating Sieve code, or even humans, but
> for scripts?

Well, the point of Sieve is for the scripts to be portable.  Ideally,
I should be able to move a script from one environment to another,
and it would still work.

But now we have to consider the meaning of "work" [or "is" (it's a US
politics joke; never mind)].  Suppose that a script was designed to
to a whole bunch of stuff, using fileinto and redirect and whatnot,
and then at the end it just wants to say, "OK, if, after all this,
the message is going into a mailbox called "important", and the
notify extension is available, then notify the recipient by pager.

If I should move that script to a system that doesn't support
notify, I might still want it to "work", in that I'd want it to do
everything except the pager bit.  But if the script be coded thus:

   require "environment", "fileinto", "notify"
   ...
   [do all the useful work]
   ...
   notify [...]

then it will fail completely when it's run somewhere that doesn't
support notify.  If I have the option of coding it this way:

   require "environment", "fileinto"
   ...
   [do all the useful work]
   ...
   if environment "extensions" "notify" {
     notify [...]
   }

then I get what I want, and I don't have to change the script.  And if,
some say, my system adds support for notify, I'll start getting paged
without having to find out that it's been upgraded, and without having
to put the notify code back into the script.

> If I used a GUI and it offers notifications, then I expect they are
> available.  

(1) You're ignoring the script portability issue.
(2) I would not make that assumption anyway.  There's no way for a GUI
to query the Sieve system, and in a mix-and-match world there's no
reason to assume we'll have bought the Sieve engine from the same
source as we got the script builder from.

> I don't think the base specification unconditionally allows dead
> code blocks that contain unknown extensions, like:
> 
>   if false {
>      unknown_extension;
>   }
> 
> Does the environment extension focus on the above usage and is it OK if
> it enforces implementations to allow unknown extensions in dead code?

I'm not sure I understand what you mean by any of that.
I *think* you're asking whether the error is generated by the parser or
by the execution, and I believe the answer is "execution".  So if
"unknown_extension" is never executed, there should be no error.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CGPm69022501; Thu, 12 Jan 2006 08:25:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0CGPmDl022500; Thu, 12 Jan 2006 08:25:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CGPlIQ022491 for <[e-mail]>; Thu, 12 Jan 2006 08:25:48 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.61) (envelope-from <[e-mail]>) id 1Ex5Gk-0002q4-F4 for [e-mail]; Thu, 12 Jan 2006 17:25:46 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 #21) id 1Ex5Gk-0006QW-Be for [e-mail]; Thu, 12 Jan 2006 17:25:46 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.61 #35) id 1Ex5Gj-0001HF-R8 for [e-mail]; Thu, 12 Jan 2006 17:25:45 +0100
Date: Thu, 12 Jan 2006 17:25:45 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: testing for extensions during run-time
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
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, Jan 11, 2006 at 02:14:59AM +0100, Kjetil Torgrim Homme wrote:
> 
> On Tue, 2006-01-10 at 19:06 -0500, Barry Leiba wrote:
> > I still wonder whether there ought to be a way to test for the presence
> > of an extension, rather than only to have the choice of *requiring* it
> > or not using it at all.  I can see a script wanting, for example, to
> > send a notification IF the Notify extension is available, but not
> > wanting the script to FAIL if it's not.
> 
> it certainly seems useful to me.  we could introduce an action, like:
> 
>   require "environment";
>   # or perhaps a separate extension.
>   want "notify";
>   if environment "extensions" "notify" {
>      ....
>   }

I must be missing something, but why would you want to write scripts
that way? Which application would profit from this extension?

I can imagine that a way to find out which extensions are available
is very useful for GUIs generating Sieve code, or even humans, but
for scripts?

If I used a GUI and it offers notifications, then I expect they are
available.  

I don't think the base specification unconditionally allows dead
code blocks that contain unknown extensions, like:

  if false {
     unknown_extension;
  }

Does the environment extension focus on the above usage and is it OK if
it enforces implementations to allow unknown extensions in dead code?

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CFYTKR017244; Thu, 12 Jan 2006 07:34:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0CFYT3q017243; Thu, 12 Jan 2006 07:34:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CFYSgO017237 for <[e-mail]>; Thu, 12 Jan 2006 07:34:28 -0800 (PST) (envelope-from [e-mail])
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Ex4T3-0001pB-HB; Thu, 12 Jan 2006 10:34:25 -0500
X-test-idtracker: no
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: 'Sieve Extension: Relational Tests' to Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 12 Jan 2006 10:34:25 -0500
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>

The IESG has received a request from the Sieve Mail Filtering Language WG to 
consider the following document:

- 'Sieve Extension: Relational Tests '
   <draft-ietf-sieve-3431bis-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2006-01-26.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-3431bis-04.txt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CAC50u082879; Thu, 12 Jan 2006 02:12:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0CAC5t8082878; Thu, 12 Jan 2006 02:12:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0CAC3fJ082862 for <[e-mail]>; Thu, 12 Jan 2006 02:12:05 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 12 Jan 2006 10:11:38 +0000
Message-ID: <[e-mail]>
Date: Wed, 11 Jan 2006 21:22:53 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-sieve-variables-07
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
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:

>Anyway, as the discussion's gone since the note I'm responding to,
>there seems to be agreement that this and other identifying stuff would
>be useful in an "Environment" extension, or some such.
>
I agree.

>  Really, I
>didn't think it needed to be in Variables -- just that Variables seemed
>a logical place to put it.  I'm happy to put it in its own extension
>that defines some new test, like this (using one of the examples from
>the imap-sieve draft):
>
>     require ["copy", "environment"];
>
>     if anyof (environment :is "cause" "APPEND",
>               environment :is "cause" "COPY")  {
>         if environment :is "mailbox" "ActionItems" {
>             redirect :copy "[e-mail]";
>         }
>     }
>
>Note, here, that I've used two "environment" items, called "cause" and
>"mailbox".
>
>I agree that I like this better than doing it with variables, and it
>means that if the "environment" extension is available, it can specify
>the "DELIVERY" cause that I'm asking for.  That satisfies everything.
>I'll write up an "Environment" extension draft, if y'all think I
>should.  Ned?  Alexey/Cyrus?
>  
>
Sure. Submit it as an individual draft first. The WG is sufficiently 
behind on existing milestones, so I think it is premature to start 
discussing adding this work to the charter.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0BGSAnf059442; Wed, 11 Jan 2006 08:28:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0BGSA48059441; Wed, 11 Jan 2006 08:28:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0BGS9gl059434 for <[e-mail]>; Wed, 11 Jan 2006 08:28:10 -0800 (PST) (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, 11 Jan 2006 08:28:05 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1136996885; h=Date: 	 From:Subject:MIME-version:Content-type; b=KT6SA28q8UQXdl2euAnrr0CZR E6SJCf1d1hMRPgP0FXVXXeatike8UHZHbCUap439P2QPrJMt7aEbpWal09PsQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Wed, 11 Jan 2006 08:28:02 -0800 (PST)
Cc: [e-mail]
To: Barry Leiba <[e-mail]>
Message-id: <[e-mail]>
Date: Wed, 11 Jan 2006 08:19:10 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-ietf-sieve-variables-07
In-reply-to: "Your message dated Tue, 10 Jan 2006 19:06:53 -0500" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[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>

> >> The problem is that when a script is written to ask "Why did I get
> >> called?", it will have to assume that if it doesn't know, it's
> >> because it got called by "mail delivery".
> >
> > I'm dubious about the notion that there will be lots of scripts
> > intended to be run in a variety of different contexts that need to
> > test this sort of thing.

> We don't (or at least I don't) know what the actual use cases are
> likely to be, so I don't know whether I agree with you or not.

It is precisely because the use cases are unknown that I'm dubious
about the extent to which the feature will be useful. Designing software
in the absence of compelling use cases often results in features of
limited utility.

OTOH, environment tests serve other purposes, and the cost of another keyword
in such a test is incredibly low.

> If we
> provide a good way to manage multiple scripts, perhaps with an
> extension to ManageSieve, it might turn out that people always want to
> do different things at the different processing points, and they'll
> always use separate scripts for each.  In that case, no, this isn't
> necessary.

> Or it might be that there are common things that people will want done,
> and they'll just occasionally want to test this to do something
> different now and then.  In that case, we need this.

My problem isn't that the various different scripts won't have tests in
common. They will. The problem is rather that the actions you'll want to
take will be quite different (this is almost axiomatic) and the ways the
actions will be coupled to the tests will probably vary considerably.

> Anyway, as the discussion's gone since the note I'm responding to,
> there seems to be agreement that this and other identifying stuff would
> be useful in an "Environment" extension, or some such.  Really, I
> didn't think it needed to be in Variables -- just that Variables seemed
> a logical place to put it.  I'm happy to put it in its own extension
> that defines some new test, like this (using one of the examples from
> the imap-sieve draft):

>      require ["copy", "environment"];

>      if anyof (environment :is "cause" "APPEND",
>                environment :is "cause" "COPY")  {
>          if environment :is "mailbox" "ActionItems" {
>              redirect :copy "[e-mail]";
>          }
>      }

> Note, here, that I've used two "environment" items, called "cause" and
> "mailbox".

Mailbox is a good one I hadn't thought of before. it clearly needs to be made
available. The notion of being able to distinguish between different sorts of
insertion operations is also interesting.

> I agree that I like this better than doing it with variables, and it
> means that if the "environment" extension is available, it can specify
> the "DELIVERY" cause that I'm asking for.  That satisfies everything.
> I'll write up an "Environment" extension draft, if y'all think I
> should.  Ned?  Alexey/Cyrus?

Absolutely! Why isn't it already an I-D? ;-)
 
> I still wonder whether there ought to be a way to test for the presence
> of an extension, rather than only to have the choice of *requiring* it
> or not using it at all.  I can see a script wanting, for example, to
> send a notification IF the Notify extension is available, but not
> wanting the script to FAIL if it's not.

I'm worried about this as well, but I'm not happy about the implications
of making such a change either. As Harald would say, "mumble".

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0B1F8Ei037394; Tue, 10 Jan 2006 17:15:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0B1F84w037393; Tue, 10 Jan 2006 17:15:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0B1F7ff037387 for <[e-mail]>; Tue, 10 Jan 2006 17:15:07 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1EwUZs-0005jt-34; Wed, 11 Jan 2006 02:15:04 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EwUZo-0000mb-6O; Wed, 11 Jan 2006 02:15:00 +0100
Subject: testing for extensions during run-time
From: Kjetil Torgrim Homme <[e-mail]>
To: Barry Leiba <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 11 Jan 2006 02:14:59 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.459, required 12, autolearn=disabled, AWL -0.46, UIO_MAIL_IS_INTERNAL -5.00)
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, 2006-01-10 at 19:06 -0500, Barry Leiba wrote:
> I still wonder whether there ought to be a way to test for the presence
> of an extension, rather than only to have the choice of *requiring* it
> or not using it at all.  I can see a script wanting, for example, to
> send a notification IF the Notify extension is available, but not
> wanting the script to FAIL if it's not.

it certainly seems useful to me.  we could introduce an action, like:

  require "environment";
  # or perhaps a separate extension.
  want "notify";
  if environment "extensions" "notify" {
     ....
  }

since the grammar of Sieve is regular, an unknown extension can't
introduce elements which changes syntax parsing.  furthermore, the
validity of the elements in the script can easily be verified during
upload: if you find an unknown keyword or element, you look upwards in
the blocks leading down to the statement.  if a block is conditional on
the existence of an extension, and the extension is unknown, ignore the
statement, otherwise flag the error and refuse the upload.  a
bytecompiler can omit the complete block in its representation.

an implementation which does no verification during upload is no worse
off with this mechanism than without.  random syntax or semantic errors
can appear anywhere and must be handled anyway.

an anyof test does throw a spanner in the works, though.  I think it is
appropriate to disallow this explictly (although a _bit_ ugly), and have
the validation during upload assume that an anyof which includes an
extension test is _always_ true, even when the extension is unsupported.
(this is still the code for the script verifier I'm talking about.)

actually, the "want" action may be superfluous, but I think it should be
used to keep dependencies explicit up front.

just some random thoughts,
-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0B071Tw030966; Tue, 10 Jan 2006 16:07:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0B0710s030965; Tue, 10 Jan 2006 16:07:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0B0715U030916 for <[e-mail]>; Tue, 10 Jan 2006 16:07:01 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k0B098uO018240 for <[e-mail]>; Tue, 10 Jan 2006 19:09:08 -0500
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k0B06sk421634 for <[e-mail]>; Tue, 10 Jan 2006 19:06:54 -0500
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k0B06su304776 for <[e-mail]>; Tue, 10 Jan 2006 19:06:54 -0500
Received: from SATURN ([9.12.234.178]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1136938013.191; Tue, 10 Jan 2006 19:06:53 -0400
Date: Tue, 10 Jan 2006 19:06:53 -0500
From: Barry Leiba <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-sieve-variables-07
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

>> The problem is that when a script is written to ask "Why did I get
>> called?", it will have to assume that if it doesn't know, it's
>> because it got called by "mail delivery".
> 
> I'm dubious about the notion that there will be lots of scripts
> intended to be run in a variety of different contexts that need to
> test this sort of thing.

We don't (or at least I don't) know what the actual use cases are
likely to be, so I don't know whether I agree with you or not.  If we
provide a good way to manage multiple scripts, perhaps with an
extension to ManageSieve, it might turn out that people always want to
do different things at the different processing points, and they'll
always use separate scripts for each.  In that case, no, this isn't
necessary.

Or it might be that there are common things that people will want done,
and they'll just occasionally want to test this to do something
different now and then.  In that case, we need this.

Anyway, as the discussion's gone since the note I'm responding to,
there seems to be agreement that this and other identifying stuff would
be useful in an "Environment" extension, or some such.  Really, I
didn't think it needed to be in Variables -- just that Variables seemed
a logical place to put it.  I'm happy to put it in its own extension
that defines some new test, like this (using one of the examples from
the imap-sieve draft):

     require ["copy", "environment"];

     if anyof (environment :is "cause" "APPEND",
               environment :is "cause" "COPY")  {
         if environment :is "mailbox" "ActionItems" {
             redirect :copy "[e-mail]";
         }
     }

Note, here, that I've used two "environment" items, called "cause" and
"mailbox".

I agree that I like this better than doing it with variables, and it
means that if the "environment" extension is available, it can specify
the "DELIVERY" cause that I'm asking for.  That satisfies everything.
I'll write up an "Environment" extension draft, if y'all think I
should.  Ned?  Alexey/Cyrus?

I still wonder whether there ought to be a way to test for the presence
of an extension, rather than only to have the choice of *requiring* it
or not using it at all.  I can see a script wanting, for example, to
send a notification IF the Notify extension is available, but not
wanting the script to FAIL if it's not.

Barry

--
Barry Leiba, Pervasive Computing Technology  ([e-mail])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0ANhUH6027046; Tue, 10 Jan 2006 15:43:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0ANhUhs027045; Tue, 10 Jan 2006 15:43:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0ANhTLh027016 for <[e-mail]>; Tue, 10 Jan 2006 15:43:29 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1EwT9B-0003jP-Fn; Wed, 11 Jan 2006 00:43:25 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EwT97-0000sg-AK; Wed, 11 Jan 2006 00:43:21 +0100
Subject: Re: draft-ietf-sieve-variables-07
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008a01c61521$df0ec8f0$70482952@nigelhome> <[e-mail]>
Content-Type: text/plain
Date: Wed, 11 Jan 2006 00:43:16 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.116, required 12, autolearn=disabled, AWL -0.12, UIO_MAIL_IS_INTERNAL -5.00)
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, 2006-01-10 at 09:07 -0800, Ned Freed wrote:
> > > I would therefore suggest an extension specifying an "environment" test as a
> > > better approach. I suspect we can come up with half a dozen things such a test
> > > could operate on.
> [...]
> I'm curious as to what sorts of things you have in this class. The things I
> immediately see as useful are the server name, the place in the process where
> the script is executing, and information relating to whether or not this script
> is executing standalone or has been called in some way from another script.

I'm also in favour of an "environment" extension rather than adding this
to variables.

in addition to server name, some identification for the site would be
useful, at least if the provider chooses to expose internal architecture
to end users (which we do).  other operational limits might be useful,
too, e.g. max size for messages, remaining quota (dynamic, so maybe not
appropriate), stuff like that.
-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0AIZdXr070842; Tue, 10 Jan 2006 10:35:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0AIZdSC070841; Tue, 10 Jan 2006 10:35:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0AIZdm6070834 for <[e-mail]>; Tue, 10 Jan 2006 10:35:39 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.207]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.3) with ESMTP id <[e-mail]>; Tue, 10 Jan 2006 10:35:33 -0800
Message-ID: <006b01c61614$b5044230$39482952@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008a01c61521$df0ec8f0$70482952@nigelhome> <[e-mail]>
Subject: Re: draft-ietf-sieve-variables-07
Date: Tue, 10 Jan 2006 18:35:57 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0AIZdm6070836
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 like this a lot.  I was struggling to articulate why I didn't like what was
> > being proposed, but this sounds very extensible.  I already have a
> > CSieveRunTimeEnvironment class in my solution and was already wanting to make
> > more information available to the script.
> 
> I'm curious as to what sorts of things you have in this class. The things I
> immediately see as useful are the server name, the place in the process where
> the script is executing, and information relating to whether or not this script
> is executing standalone or has been called in some way from another script.

It holds state/manages things like:
- Mail message
- Owner info
- Server info
- Variables
- Method to obtain spam score/virus scoret
- A cache of the spam score, virus score
- Methods for reporting errors

But my reason for the comment was the relating to "Information about the owner".  ie I'm thinking it might be useful to access mailowner/domain/mailserver configuration from within a sieve script.  Perhaps things like the server name, but also possibly mailbox properties like return addresses.

In the case of scripts that are executed against lots of mailboxes then I was also thinking of stuff like:

 Do initial basic sieve filtering
 if (User has paid me for feature X) {
   Do expensive sieve filtering
 }
 if (User has paid me for feature Y) {
   Do slightly less expensive sieve filtering
 }
 Do basic sieve filtering

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0AHCsPp058306; Tue, 10 Jan 2006 09:12:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0AHCsML058305; Tue, 10 Jan 2006 09:12:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0AHCpRu058284 for <[e-mail]>; Tue, 10 Jan 2006 09:12:53 -0800 (PST) (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]; Tue, 10 Jan 2006 09:12:46 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1136913165; h=Date: 	 From:Subject:MIME-version:Content-type; b=tAVDLbrio9RxUosFsN8bLLI0B nRhFImSo+k1rW0BZM6XYhPp9OF1VJtNh0XKmgz68tp0qkPX8GTV9YL0Sp8WOw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 10 Jan 2006 09:12:42 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>, [e-mail]
To: Nigel Swinson <[e-mail]>
Message-id: <[e-mail]>
Date: Tue, 10 Jan 2006 09:07:25 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-ietf-sieve-variables-07
In-reply-to: "Your message dated Mon, 09 Jan 2006 13:37:42 +0000" <008a01c61521$df0ec8f0$70482952@nigelhome>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=iso-8859-1
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <008a01c61521$df0ec8f0$70482952@nigelhome>
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 would therefore suggest an extension specifying an "environment" test as a
> > better approach. I suspect we can come up with half a dozen things such a test
> > could operate on.

> I like this a lot.  I was struggling to articulate why I didn't like what was
> being proposed, but this sounds very extensible.  I already have a
> CSieveRunTimeEnvironment class in my solution and was already wanting to make
> more information available to the script.

I'm curious as to what sorts of things you have in this class. The things I
immediately see as useful are the server name, the place in the process where
the script is executing, and information relating to whether or not this script
is executing standalone or has been called in some way from another script.

> I also agree that this should be an additional extension, primarily so it
> doesn't hold up variables, and secondarily cos I don't think it "needs" to be
> part of the base variables spec.

Complete agreement here.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k09Db8sr061847; Mon, 9 Jan 2006 05:37:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k09Db8fJ061846; Mon, 9 Jan 2006 05:37:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k09Db8Il061837 for <[e-mail]>; Mon, 9 Jan 2006 05:37:08 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.205]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.3) with ESMTP id <[e-mail]>; Mon, 9 Jan 2006 05:37:02 -0800
Message-ID: <008a01c61521$df0ec8f0$70482952@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Ned Freed" <[e-mail]>
Cc: "Kjetil Torgrim Homme" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: draft-ietf-sieve-variables-07
Date: Mon, 9 Jan 2006 13:37:42 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k09Db8Il061841
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 would therefore suggest an extension specifying an "environment" test as a
> better approach. I suspect we can come up with half a dozen things such a test
> could operate on.

I like this a lot.  I was struggling to articulate why I didn't like what was being proposed, but this sounds very extensible.  I already have a CSieveRunTimeEnvironment class in my solution and was already wanting to make more information available to the script.

I also agree that this should be an additional extension, primarily so it doesn't hold up variables, and secondarily cos I don't think it "needs" to be part of the base variables spec.

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k092E2Xi098276; Sun, 8 Jan 2006 18:14:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k092E2RZ098275; Sun, 8 Jan 2006 18:14:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k092E0gT098268 for <[e-mail]>; Sun, 8 Jan 2006 18:14:01 -0800 (PST) (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, 8 Jan 2006 18:13:57 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1136772837; h=Date: 	 From:Subject:MIME-version:Content-type; b=NmWKHU4gvKr9JjG/AkCzu+m1A yzrGo9b6CiL+4zNTZLAIxmV5kvtozf6EHNCg5VYlQkjQN0O6Aukrd9O9ONQXg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 08 Jan 2006 18:13:52 -0800 (PST)
Cc: Ned Freed <[e-mail]>, [e-mail]
To: Aaron Stone <[e-mail]>
Message-id: <[e-mail]>
Date: Sun, 08 Jan 2006 18:01:24 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-ietf-sieve-variables-07
In-reply-to: "Your message dated Sun, 08 Jan 2006 15:04:48 -0800" <1136761488.5822.9.camel@localhost>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1136761488.5822.9.camel@localhost>
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 Sun, 2006-01-08 at 08:37 -0800, Ned Freed wrote:
> [snip]
> > > So I'm suggesting that the variables spec define a base namespace
> > > (I'm suggesting "Sieve.").  And I'm suggesting that the variables
> > > spec define a variable that MUST be set ...

> >From a language implementation point of view, if you're going to reserve
> a keyword or a namespace, do it sooner rather than later.

Since namespaces are bound to future extensions by the current variables
draft, all namespaces are effectively reserved already.

> [snip]
> > I also think additional environmental information might be useful to  provide
> > to script. Indeed, I suspect that knowing, say, the name of the system you're
> > running on might be even more useful to scripts than being able to distinguish
> > between delivery and other places sieves are used.
> >
> > I would therefore suggest an extension specifying an "environment" test as a
> > better approach. I suspect we can come up with half a dozen things such a test
> > could operate on.

> Maybe? Sieve is a "little language" and I like to think of Sieve scripts
> as being these little gnomes that push my mail around. Gnomes don't
> think too hard about where they are or where they're going; gnomes just
> focus on what they're doing right now.

I'm sorry, but I have to disagree. Lots of people have more than one email
account and one of the goals of sieve is for a user to be able to define
something that works in multiple places. Wanting to have somewhat different
behavior depending on the environment is a fairly obvious thing to want to do,
even when all the different environments correspond to the same place in email
processing. As a specific example, i might want to have a very different
spamtest threshhold for the filter I use on my ISP account than the one I use
on my corporate account.

This isn't to say that there aren't significant barriers to script portability.
The most obvious one is the very real possibility that the set of supported
extensions is quite different in different environments. Since requires cannot
be conditionalized this forces scripts intended for multiple environments to be
written us9ing the least common denominator set of extensions, which is often
pretty unappealing.

This all gets especially nasty when you change places. The set of available
actions at delivery time is unavoidably different from the set of actions
available within an IMAP server. This is reflected in the sieve-in-IMAP draft
in various ways, including the omission of reject. So what should

	require "reject";

do in such a script?

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k091Euub093992; Sun, 8 Jan 2006 17:14:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k091Euab093991; Sun, 8 Jan 2006 17:14:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k091EtYZ093981 for <[e-mail]>; Sun, 8 Jan 2006 17:14:56 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.43) id 1EvlcZ-0004gr-Su; Mon, 09 Jan 2006 02:14:52 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EvlcS-0000wU-VM; Mon, 09 Jan 2006 02:14:44 +0100
Subject: Re: draft-ietf-sieve-variables-07
From: Kjetil Torgrim Homme <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: [e-mail]
In-Reply-To: <1136761488.5822.9.camel@localhost>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <1136761488.5822.9.camel@localhost>
Content-Type: text/plain
Date: Mon, 09 Jan 2006 02:14:42 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.351, required 12, autolearn=disabled, AWL -0.35, UIO_MAIL_IS_INTERNAL -5.00)
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 Sun, 2006-01-08 at 15:04 -0800, Aaron Stone wrote:
> Maybe? Sieve is a "little language" and I like to think of Sieve scripts
> as being these little gnomes that push my mail around. Gnomes don't
> think too hard about where they are or where they're going; gnomes just
> focus on what they're doing right now.

sorry, but I don't understand what this means.
-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k08Mx0Ai082574; Sun, 8 Jan 2006 14:59:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k08Mx0id082573; Sun, 8 Jan 2006 14:59:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lucite.serendipity.cx (IDENT:[e-mail] [66.92.2.88] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k08Mwxsw082566 for <[e-mail]>; Sun, 8 Jan 2006 14:58:59 -0800 (PST) (envelope-from [e-mail])
Received: by lucite.serendipity.cx (Postfix, from userid 1003) id BBF376010CE6; Sun,  8 Jan 2006 14:58:56 -0800 (PST)
Received: from [192.168.0.6] (localhost [127.0.0.1]) by lucite.serendipity.cx (Postfix) with ESMTP id 3DEB46010D31; Sun,  8 Jan 2006 14:58:49 -0800 (PST)
Subject: Re: draft-ietf-sieve-variables-07
From: Aaron Stone <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Sun, 08 Jan 2006 15:04:48 -0800
Message-Id: <1136761488.5822.9.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-DSPAM-Result: Innocent
X-DSPAM-Confidence: 0.6000
X-DSPAM-Probability: 0.0000
X-DSPAM-Signature: !DSPAM:43c19930292207105010007!
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 Sun, 2006-01-08 at 08:37 -0800, Ned Freed wrote:
[snip]
> > So I'm suggesting that the variables spec define a base namespace
> > (I'm suggesting "Sieve.").  And I'm suggesting that the variables
> > spec define a variable that MUST be set ...

>From a language implementation point of view, if you're going to reserve
a keyword or a namespace, do it sooner rather than later.

[snip]
> I also think additional environmental information might be useful to  provide
> to script. Indeed, I suspect that knowing, say, the name of the system you're
> running on might be even more useful to scripts than being able to distinguish
> between delivery and other places sieves are used.
> 
> I would therefore suggest an extension specifying an "environment" test as a
> better approach. I suspect we can come up with half a dozen things such a test
> could operate on.

Maybe? Sieve is a "little language" and I like to think of Sieve scripts
as being these little gnomes that push my mail around. Gnomes don't
think too hard about where they are or where they're going; gnomes just
focus on what they're doing right now.

Aaron



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k08GuGbL038126; Sun, 8 Jan 2006 08:56:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k08GuG4e038125; Sun, 8 Jan 2006 08:56:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k08GuEjD038108 for <[e-mail]>; Sun, 8 Jan 2006 08:56:14 -0800 (PST) (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, 8 Jan 2006 08:56:04 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1136739364; h=Date: 	 From:Subject:MIME-version:Content-type; b=Ob+XuC4eupA4ACGBdYCEuatMK S4Urf77F6hjWvFoODwha3i8/3ewwMzzehG7tljZx9jHtzS3jAYy5eJcG9vsCg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 08 Jan 2006 08:55:59 -0800 (PST)
Cc: Kjetil Torgrim Homme <[e-mail]>, [e-mail]
To: Barry Leiba <[e-mail]>
Message-id: <[e-mail]>
Date: Sun, 08 Jan 2006 08:37:11 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: draft-ietf-sieve-variables-07
In-reply-to: "Your message dated Mon, 19 Dec 2005 17:45:54 -0500" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[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>

> >> For the former: the lemonade extension adds a reserved variable which
> >> I'm currently calling "IMAPSieve.cause".  Its value is the action
> >> that caused the script to be run ("APPEND", "COPY", and so on).  It
> >> occurs to me that it'll be awkward for scripts to have to wonder
> >> what the absence of that variable means.  Wouldn't it be a good idea
> >> to have a reserved namespace called "Sieve.", and to have a variable
> >> called "Sieve.cause" that's ALWAYS available if variables are
> >> supported?  In the normal case, its value would be "DELIVERY", and
> >> extensions like mine can specify other values.  (This might also add
> >> an IANA item....)
> >
> > okay, so you think this namespace should be defined in the variables
> > draft?  I'm not too wild with the idea, since I really wanted -08
> > which I submitted yesterday to finally reach RFC status.

> Oh, well.  So it can be the -09 version that does; is that such a big
> deal?

Frankly, yes. We need to finish up this spec and get it out the door. The list
of potential additions of this general sort is for all intents and purposes
infinite.

> > I would expect the
> > extension to be required by anyone wanting to inspect that variable,
> > and so I don't see much benefit to making it a globally available
> > variable.

> The problem is that when a script is written to ask "Why did I get
> called?", it will have to assume that if it doesn't know, it's because
> it got called by "mail delivery".  Since we're at a point where we
> could get that modified in the variables draft now, I think we should.

I'm dubious about the notion that there will be lots of scripts intended to be
run in a variety of different contexts that need to test this sort of thing.
However, I have no objection to making such a test available, although I think
the right way to do it is as a separate extension and test, not as  a magic
variable. For one thing, this means that in order for such a test to work you
have to have the variables extension, and I worry that variables may not be
implemented or enabled in some performance-sensitive environments.

> So I'm suggesting that the variables spec define a base namespace (I'm
> suggesting "Sieve.").  And I'm suggesting that the variables spec
> define a variable that MUST be set (I'm suggesting "Sieve.cause",

"place" seems to me to be a more natural name for this, but I'm not wedded
to any particular term either.

> but
> I'm not particular about the name) that gives the reason the script was
> called.  I'm suggesting that the value for mail delivery be "DELIVERY".
> And I'm suggesting that the variables spec say that other extensions
> may add other values, if they create other causes for having Sieve
> scripts called.  It seems a simple change, and a useful one in the long
> run.

I don't necessarily see running sieves in different environments as
necessitating additional extensions. It seems to me a simple "places" registry
would be sufficient. And it probably should allow for vendor-supplied places
since I suspect there will be non-standard uses of sieve. (In fact I know there
will be because we already have two in our product and another two are
planned.)

I also think additional environmental information might be useful to  provide
to script. Indeed, I suspect that knowing, say, the name of the system you're
running on might be even more useful to scripts than being able to distinguish
between delivery and other places sieves are used.

I would therefore suggest an extension specifying an "environment" test as a
better approach. I suspect we can come up with half a dozen things such a test
could operate on.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k03Ko3ZO048928; Tue, 3 Jan 2006 12:50:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k03Ko3Um048924; Tue, 3 Jan 2006 12:50:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k03Ko2sB048908 for <[e-mail]>; Tue, 3 Jan 2006 12:50:02 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Ett6X-00005g-Oi; Tue, 03 Jan 2006 15:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-vacation-05.txt 
Message-Id: <[e-mail]>
Date: Tue, 03 Jan 2006 15:50:01 -0500
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:  Vacation Extension
	Author(s)	: T. Showalter, N. Freed
	Filename	: draft-ietf-sieve-vacation-05.txt
	Pages		: 16
	Date		: 2006-1-3
	
This document describes an extension to the Sieve email filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages.  Various safety features are
   included to prevent problems such as message loops.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-vacation-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-vacation-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-vacation-05.txt

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

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

--OtherAccess--

--NextPart--