Re: Standard to selectively disable rules in sieve script?

[Alexey Melnikov <[e-mail]>]

Hi Patrick,

Patrick Ben Koetter wrote:

>* Nigel Swinson <[e-mail]>:
>  
>
>>>for the case of temporarily disabling a rule,  I think the most obvious
>>>method is a simple
>>>
>>>   if false { }
>>>
>>>around the block.  that construct can hardly be used for anything else.
>>>using comments is bad, since comments should be truly freeform and
>>>without meaning.
>>>      
>>>
>>Agreed, and this is actually what I chose to do with our implementation.  It
>>has the added advantage of still doing compilation/syntax checking on the
>>disabled rule, whereas if it was just commented out it'll all be ignored...
>>    
>>
>It seems that there's an agreement on temporarily disabling a rule.
>People should use:
>
>        if false { }
>
>
>I am fairly new to this list and not accustomed with its procedures. What
>would I have to do to propose this agreement to become a standard?  
>
You need to write a short IETF draft on this and then get it published 
as an RFC.
Contact me off-list if you need to know more details.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2VGOpjo025732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Mar 2008 09:24:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2VGOpQ5025731; Mon, 31 Mar 2008 09:24:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (piper.mulberrymail.com [151.201.22.177] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2VGOmPH025723 for <[e-mail]>; Mon, 31 Mar 2008 09:24:51 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id A0715525A55 for <[e-mail]>; Mon, 31 Mar 2008 12:24:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozYFhKQR8D-h for <[e-mail]>; Mon, 31 Mar 2008 12:24:47 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 5F53F525A4E for <[e-mail]>; Mon, 31 Mar 2008 12:24:46 -0400 (EDT)
Date: Mon, 31 Mar 2008 12:24:43 -0400
From: Cyrus Daboo <[e-mail]>
To: SIEVE <[e-mail]>
Subject: Charter update
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
We have heard back from most people and at this point the Chairs are happy 
that there is enough interest for us to re-charter and take on the new 
proposed work.

Couple of points:

- Both draft-freed-sieve-date-index-08.txt and 
draft-freed-sieve-environment-03.txt are now progressing through IESG. 
Therefore we propose dropping those from the new charter.

- A suggestion was made to add a work item to address EAI/IDN issues. It 
was felt better for us to address this rather than have EAI take the work 
on, but we would like to here from others on what they think about this.

The new charter below reflects the changes discussed above. Next we will 
come up with some milestones and then hand off to the AD.

---
The SIEVE email filtering language is specified in RFC 5228, together with 
a number of extensions.

The SIEVE working group is being re-chartered to:

(1) Finish work on existing in-progress Working Group documents:

	(a) Body (draft-ietf-sieve-body-07.txt)
	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
	(c) Edit header (draft-ietf-sieve-editheader-10.txt)
	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

(2) Finalize and publish the following SIEVE extensions as proposed 
standards:

	(a) iHave (draft-freed-sieve-ihave-01.txt)
	(b) Notary (draft-freed-sieve-notary-01.txt)
	(c) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
	(d) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
	(e) ManageSIEVE (draft-martin-managesieve-08.txt)
	(f) RegEx (draft-ietf-sieve-regex-00.txt)
	(g) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
	(h) Include/multi-script (draft-daboo-sieve-include-05.txt)
	(i) Address data (draft-melnikov-sieve-external-lists-01)

Additional drafts may be added to this list, but only via a charter
revision. There must also be demonstrable willingness in the SIEVE
development community to actually implement a given extension before
it can be added to this charter.

(3) Work on a specification to describe how EAI/IDN issues should be 
handled in SIEVE.

(4) Work on a "Benefits of SIEVE" guide for client and server vendors that:
	(a) Describes the SIEVE protocol and its suite of extensions.
	(b) Explains the benefits of server-side filtering in practical terms.
	(c) Shows how client-side filtering can be migrated to SIEVE.

(5) Produce one or more informational RFCs containing a set of test scripts 
and test email messages that are to be filtered by the scripts, and the 
expected results of that filtering. This will serve as the basis of a 
interoperability test suite to help determine the suitability of moving the 
base specification and selected extensions to Draft status.


-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2SLb0O3092900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Mar 2008 14:37:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2SLb0do092899; Fri, 28 Mar 2008 14:37:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2SLawg6092893 for <[e-mail]>; Fri, 28 Mar 2008 14:36:59 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 28 Mar 2008 14:36:56 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 28 Mar 2008 14:36:52 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Fri, 28 Mar 2008 14:16:44 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-freed-sieve-environment-04
In-reply-to: "Your message dated Thu, 27 Mar 2008 00:32:21 +0100" <1206574341.16281.60.camel@oslhomkje>
References: <[e-mail]> <[e-mail]> <1206459316.16281.2.camel@oslhomkje> <[e-mail]> <1206574341.16281.60.camel@oslhomkje>
To: Kjetil Torgrim Homme <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1206740214; h=Date:	 From:Subject:MIME-version:Content-type; b=AZsijpzUWp2025FAAr1aMLN1b MRi7Fl9SXi1lWJtDX55U2PAUOhmT0+i4heCa5G/MkeedlC7ZfKTn2WoR2wdsQ==
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, 2008-03-25 at 09:52 -0700, Ned Freed wrote:
> > > On Sun, 2008-03-23 at 10:50 -0700, Ned Freed wrote:
> > > > Also a good point. I have added:
> > > >
> > > >   The remote-host environment item defined in this specification is usually
> > > >   determined by performing a PTR DNS lookup on the client IP address. This
> > > >   information may come from an untrusted source. For example, the test:
> [...]
> > > sorry, I don't understand what this means.  is the existence of a PTR
> > > record sufficient?
> >
> > Who knows? The mechanism used to obtian the remote-host isn't (and should not
> > be) specified. As such, a PTR could be sufficient. Or it may not be - some
> > systems do a backwards-forwards check. And there can even be cases when a PTR
> > record isn't needed - DNS names aren't the only game in town, you know.

> ok.  I think it could be made a little clearer, though.  how about:

>         How to determine the remote-host environment item defined in
>         this specification is left up to the implementation, e.g, if TLS
>         is in use, the remote system's name can be extracted from the
>         client certificate if the signer is trusted.  Probably more
>         commonly it will be determined by performing a PTR DNS lookup on
>         the client IP address.  This information may come from an
>         untrusted source.  For example, the test:

I really don't want to get into the whole TLS cert thing in this document.

> another alternative, with no specific details about alternatives:

>         An implementation can use any technique to determine the
>         remote-host environment item defined in this specification, and
>         the trustworthiness of the result will vary.  One common method
>         will be to perform a PTR DNS lookup on the client IP address.
>         This information may come from an untrusted source.  For
>         example, the test:

This, OTOH, is fine. I'll include it in the next revision.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RJm7rs032173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 12:48:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2RJm7qe032172; Thu, 27 Mar 2008 12:48:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2RJm3IA032162 for <[e-mail]>; Thu, 27 Mar 2008 12:48:07 -0700 (MST) (envelope-from [e-mail])
Received: by MSA with id 830EE57A5F47DABBFC6D4DD4BFED9B012ED9E420
Received: from laptop.lan (ppp26-141dynamic.athens.acn.gr [213.5.26.141]) (authenticated bits=0) by msa.uoa.gr (8.14.1/8.14.1) with ESMTP id m2RJm1IZ020009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 27 Mar 2008 21:48:02 +0200 (EET)
Date: Thu, 27 Mar 2008 21:48:01 +0200
From: Alexandros Vellis <[e-mail]>
To: [e-mail]
Subject: Re: Standard to selectively disable rules in sieve script?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1206575521.16281.72.camel@oslhomkje> <[e-mail]> <[e-mail]>
Organization: National and Kapodistrian University of Athens
X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.0; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-UoAMSAId: 830EE57A5F47DABBFC6D4DD4BFED9B012ED9E420
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>

Tony Hansen <[e-mail]> wrote: 
> There still needs to be something to translate that "disable=yes"
> into, and I think the "if false {}" construct is as reasonable a
> thing as any.

Agreed.


To the original poster:

It's a challenge to represent a script in a user interface. The
designer of the UI would have to think of many clever ways to represent
things like many conditions with complicated and/or logic in an
if-block, nested if-blocks, else blocks, intermediate actions etc..
That is, in order to make it usable to many people who are accustomed
to the filters interfaces of Outlook or Thunderbird.

While the "simplified" UIs that currently exist for Sieve work for some
people, it would be much more acceptable to have proper Sieve parsing
in as many applications as possible. Whether that happens because of
clients that use XML tools and servers that serve an XML representation
of Sieve, or because of clients that parse scripts by using Sieve
parsers[1], that's irrelevant -- for the users anyway.

Avel :)

[1] http://sieve.info/libraries 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2R93H9q067618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Mar 2008 02:03:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2R93Hvq067617; Thu, 27 Mar 2008 02:03:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.state-of-mind.de (mail.state-of-mind.de [194.126.158.26]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2R93CvD067604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 27 Mar 2008 02:03:16 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by mail.state-of-mind.de (Postfix) with ESMTP id 9462E80FA66 for <[e-mail]>; Thu, 27 Mar 2008 10:04:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=state-of-mind.de; s=mail0801; t=1206608676; bh=d9OMrEE9RCDvJGgBOTylMmUfxCV0fqyiU3iE7c l17gs=; h=X-Virus-Scanned:Date:From:To:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:In-Reply-To: User-Agent; b=SkunWR8xu7iso9ZptdBb7XT4D8e99g08v+l8sORIPvO7iP4N9sdX uurl7yn2qR1l/FxHCJXbvINhUQkkmkbI/UFr/KK7KqjN5FvjOe5uD19vQO1kR9LpG0l dcm/7pbkPfETT6I3usVzl+AFT2TKM5Co1rrokhFf9E2QbeLuCh7k=
X-Virus-Scanned: amavisd-new at state-of-mind.de
Received: from mail.state-of-mind.de ([127.0.0.1]) by localhost (mail.state-of-mind.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id THRaayEmK+nN for <[e-mail]>; Thu, 27 Mar 2008 10:04:36 +0100 (CET)
Received: from state-of-mind.de (gw.state-of-mind.de [62.245.202.194]) by mail.state-of-mind.de (Postfix) with ESMTP id 1FBA780C25D for <[e-mail]>; Thu, 27 Mar 2008 10:04:36 +0100 (CET)
Date: Thu, 27 Mar 2008 10:03:11 +0100
From: Patrick Ben Koetter <[e-mail]>
To: [e-mail]
Subject: Re: Standard to selectively disable rules in sieve script?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <1206575521.16281.72.camel@oslhomkje> <00c001c88fa7$1e8e1ec0$6401a8c0@nigelhome>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <00c001c88fa7$1e8e1ec0$6401a8c0@nigelhome>
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
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>

* Nigel Swinson <[e-mail]>:
> > for the case of temporarily disabling a rule,  I think the most obvious
> > method is a simple
> >
> >    if false { }
> >
> > around the block.  that construct can hardly be used for anything else.
> > using comments is bad, since comments should be truly freeform and
> > without meaning.
> 
> Agreed, and this is actually what I chose to do with our implementation.  It
> has the added advantage of still doing compilation/syntax checking on the
> disabled rule, whereas if it was just commented out it'll all be ignored...

It seems that there's an agreement on temporarily disabling a rule.
People should use:

        if false { }


I am fairly new to this list and not accustomed with its procedures. What
would I have to do to propose this agreement to become a standard?

Thanks,

p@rick

-- 
state of mind
Agentur für Kommunikation, Design und Softwareentwicklung

Patrick Koetter            Tel: [phone]
Echinger Strasse 3         Fax: [phone]
85386 Eching               Web: http://www.state-of-mind.de

Amtsgericht München        Partnerschaftsregister PR 563



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2R2AcuC034349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 19:10:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2R2Acfp034348; Wed, 26 Mar 2008 19:10:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2R2AaqA034338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 26 Mar 2008 19:10:37 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-8.tower-121.messagelabs.com!1206583834!22209274!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.128.141]
Received: (qmail 26299 invoked from network); 27 Mar 2008 02:10:35 -0000
Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-8.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2008 02:10:35 -0000
Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m2R2AYIG001794 for <[e-mail]>; Wed, 26 Mar 2008 19:10:34 -0700
Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m2R2ARMP001744 for <[e-mail]>; Wed, 26 Mar 2008 19:10:28 -0700
Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m2R2ARSL005960 for <[e-mail]>; Wed, 26 Mar 2008 21:10:27 -0500
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m2R2AKKE005854 for <[e-mail]>; Wed, 26 Mar 2008 21:10:20 -0500
Received: from [135.210.32.121] (unknown[135.210.32.121](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20080327021019gw100l7oaee> (Authid: tony); Thu, 27 Mar 2008 02:10:20 +0000
Message-ID: <[e-mail]>
Date: Wed, 26 Mar 2008 22:11:02 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Standard to selectively disable rules in sieve script?
References: <[e-mail]>	 <[e-mail]> <1206575521.16281.72.camel@oslhomkje> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.6
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>

There still needs to be something to translate that "disable=yes" into, 
and I think the "if false {}" construct is as reasonable a thing as any.

	Tony

Cyrus Daboo wrote:
> 
> 
> If this is something that clients want to do interoperably, we should 
> probably ask Ned to add a "disable=(yes|no)" attribute to the XML 
> <control> elements in draft-freed-sieve-in-xml, so that there is an 
> explicit and easy way to do this in XML without having to resort to the 
> if false {} construct.
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2R1Sr8P031424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 18:28:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2R1SrWk031423; Wed, 26 Mar 2008 18:28:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (piper.mulberrymail.com [151.201.22.177] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2R1SnMl031414 for <[e-mail]>; Wed, 26 Mar 2008 18:28:52 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C07C34C96C3; Wed, 26 Mar 2008 21:28:48 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9l4D-GWyHti; Wed, 26 Mar 2008 21:28:48 -0400 (EDT)
Received: from [10.0.1.7] (unknown [10.0.1.7]) by daboo.name (Postfix) with ESMTP id 99B3C4C96B7; Wed, 26 Mar 2008 21:28:47 -0400 (EDT)
Date: Wed, 26 Mar 2008 21:28:45 -0400
From: Cyrus Daboo <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>, Aaron Stone <[e-mail]>
cc: Patrick Ben Koetter <[e-mail]>, [e-mail]
Subject: Re: Standard to selectively disable rules in sieve script?
Message-ID: <[e-mail]>
In-Reply-To: <1206575521.16281.72.camel@oslhomkje>
References: <[e-mail]>	 <[e-mail]> <1206575521.16281.72.camel@oslhomkje>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 Kjetil,

--On March 27, 2008 12:52:01 AM +0100 Kjetil Torgrim Homme 
<[e-mail]> wrote:

> agreed.  reconstructing the semantics of the rules is a challenge, e.g,
> consider a UI where there's a simple rule for matching mailing lists.
> this would probably be a macro with lots of heuristics, checking List-Id
> but also Sender and stuff like that.  when loaded into a different
> client it should of course handle this, but it may present the rule as a
> sequence of tests rather than a single macro.  IMHO, it's not realistic
> to standardise these things, since we will never catch all the
> use-cases.
>
> for the case of temporarily disabling a rule,  I think the most obvious
> method is a simple
>
>    if false { }
>
> around the block.  that construct can hardly be used for anything else.
> using comments is bad, since comments should be truly freeform and
> without meaning.

If this is something that clients want to do interoperably, we should 
probably ask Ned to add a "disable=(yes|no)" attribute to the XML <control> 
elements in draft-freed-sieve-in-xml, so that there is an explicit and easy 
way to do this in XML without having to resort to the if false {} construct.

-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2R0Bv78025627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 17:11:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2R0BvUw025626; Wed, 26 Mar 2008 17:11:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2R0BtZm025617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 26 Mar 2008 17:11:56 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jefil-0006JJ-5I for [e-mail]; Thu, 27 Mar 2008 01:11:55 +0100
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx9.uio.no) by mail-mx9.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jefik-0000oG-4p for [e-mail]; Thu, 27 Mar 2008 01:11:54 +0100
Received: from pat-gw.osl.fast.no ([217.144.235.5] helo=[192.168.2.4]) by mail-mx9.uio.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <[e-mail]>) id 1Jefij-0000nz-TG for [e-mail]; Thu, 27 Mar 2008 01:11:54 +0100
Subject: Re: [Fwd: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
From: Kjetil Torgrim Homme <[e-mail]>
Reply-To: [e-mail]
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Thu, 27 Mar 2008 01:11:53 +0100
Message-Id: <1206576713.16281.90.camel@oslhomkje>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, none)
X-UiO-Scanned: 94A828B48B096D33EF86A1E7B9ADF21BE6F8858D
X-UiO-SR-test: 4E41979754CB211FC273F06D28DA9FD1374D99E2
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 34 total 7543119 max/h 8345 blacklist 0 greylist 0 ratelimit 0
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>

[Hannes Tschofenig <[e-mail]>]:
>    o  The "Received:" fields from the triggering message MAY be retained
>       in the notification message, as these may help detect and prevent
>       mail loops.  The "Auto-Submitted" header field MUST be placed
>       above these (see Section 2.7.1).  URI headers with hname
>       "received" are considered unsafe, and will be ignored.
> 
> Why is this a MAY and not a MUST? 

normal bounces do not copy Received fields, either.  RFC 3464 is silent
on this issue, but the example messages do not contain "extraneous"
Received fields.  of course DSNs have null envelope-from, which is a
better safeguard.

as long as the implementation adds Auto-Submitted and make sure not to
respond to Auto-Submitted messages, the risk of a loop is very small,
even if other autoresponders have never heard of that header.  they will
need to actively remove that header field to cause a loop, and if an
implementation is that broken, who knows what it'll do to Received?

the notification is a freshly generated message, so to me it is "lying"
about the message's origins to include Received fields which are really
about another message.

-- 
Kjetil T.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QNqNKF024251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 16:52:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QNqNjW024247; Wed, 26 Mar 2008 16:52:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QNqL1r024225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 26 Mar 2008 16:52:22 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JefPa-0002qe-Vn; Thu, 27 Mar 2008 00:52:07 +0100
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx8.uio.no) by mail-mx8.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JefPa-0002up-K8; Thu, 27 Mar 2008 00:52:06 +0100
Received: from pat-gw.osl.fast.no ([217.144.235.5] helo=[192.168.2.4]) by mail-mx8.uio.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <[e-mail]>) id 1JefPa-0002u3-Ef; Thu, 27 Mar 2008 00:52:06 +0100
Subject: Re: Standard to selectively disable rules in sieve script?
From: Kjetil Torgrim Homme <[e-mail]>
To: Aaron Stone <[e-mail]>
Cc: Patrick Ben Koetter <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 27 Mar 2008 00:52:01 +0100
Message-Id: <1206575521.16281.72.camel@oslhomkje>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, none)
X-UiO-Scanned: 5AC90FDEF00203122D9C26992FEADDAD640C70A6
X-UiO-SR-test: F1447EACB170ECC4EB6099F9C1D861704E5BACC0
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 401 total 7543059 max/h 8345 blacklist 0 greylist 0 ratelimit 0
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, 2008-03-26 at 15:58 -0700, Aaron Stone wrote:
> Most of the Sieve clients don't actually parse the Sieve rulesets,  
> unfortunately. They tend to do what Avelsieve does, which is to leave  
> itself a comment in a particular format (for Avelsieve, it's a  
> serialized PHP array) so that it knows what the next block of code does.
> 
> This does indeed limit interoperability of clients.
> 
> If the clients did all parse the Sieve itself, and could edit each  
> other's rules using their respective gui's, then actually I think we  
> would need some agreement on how to mark a rule inactive (so that it  
> could be left in the script and turned back on by another client  
> without having to re-create it). It's a good point, though I don't  
> have a good answer myself.

agreed.  reconstructing the semantics of the rules is a challenge, e.g,
consider a UI where there's a simple rule for matching mailing lists.
this would probably be a macro with lots of heuristics, checking List-Id
but also Sender and stuff like that.  when loaded into a different
client it should of course handle this, but it may present the rule as a
sequence of tests rather than a single macro.  IMHO, it's not realistic
to standardise these things, since we will never catch all the
use-cases.

for the case of temporarily disabling a rule,  I think the most obvious
method is a simple

   if false { }

around the block.  that construct can hardly be used for anything else.
using comments is bad, since comments should be truly freeform and
without meaning.

-- 
Kjetil T.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QNWT1R022786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 16:32:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QNWT8J022785; Wed, 26 Mar 2008 16:32:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QNWPSK022778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 26 Mar 2008 16:32:28 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jef6W-000826-Fl; Thu, 27 Mar 2008 00:32:24 +0100
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx2.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1Jef6W-00038a-Am; Thu, 27 Mar 2008 00:32:24 +0100
Received: from pat-gw.osl.fast.no ([217.144.235.5] helo=[192.168.2.4]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[e-mail]>) id 1Jef6W-00038S-7H; Thu, 27 Mar 2008 00:32:24 +0100
Subject: Re: Comments on draft-freed-sieve-environment-04
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <1206459316.16281.2.camel@oslhomkje> <[e-mail]>
Content-Type: text/plain
Date: Thu, 27 Mar 2008 00:32:21 +0100
Message-Id: <1206574341.16281.60.camel@oslhomkje>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, none)
X-UiO-Scanned: 9FD28212B980FE49920F8D8FE1DE5A8031F291BE
X-UiO-SR-test: 1E76970EB6112D88974F33C882E23676DF8F7FF0
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 222 total 7542880 max/h 8345 blacklist 0 greylist 0 ratelimit 0
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, 2008-03-25 at 09:52 -0700, Ned Freed wrote:
> > On Sun, 2008-03-23 at 10:50 -0700, Ned Freed wrote:
> > > Also a good point. I have added:
> > >
> > >   The remote-host environment item defined in this specification is usually
> > >   determined by performing a PTR DNS lookup on the client IP address. This
> > >   information may come from an untrusted source. For example, the test:
[...]
> > sorry, I don't understand what this means.  is the existence of a PTR
> > record sufficient?
> 
> Who knows? The mechanism used to obtian the remote-host isn't (and should not
> be) specified. As such, a PTR could be sufficient. Or it may not be - some
> systems do a backwards-forwards check. And there can even be cases when a PTR
> record isn't needed - DNS names aren't the only game in town, you know.

ok.  I think it could be made a little clearer, though.  how about:

        How to determine the remote-host environment item defined in
        this specification is left up to the implementation, e.g, if TLS
        is in use, the remote system's name can be extracted from the
        client certificate if the signer is trusted.  Probably more
        commonly it will be determined by performing a PTR DNS lookup on
        the client IP address.  This information may come from an
        untrusted source.  For example, the test:

another alternative, with no specific details about alternatives:

        An implementation can use any technique to determine the
        remote-host environment item defined in this specification, and
        the trustworthiness of the result will vary.  One common method
        will be to perform a PTR DNS lookup on the client IP address.
        This information may come from an untrusted source.  For
        example, the test:

what do you think?
-- 
Kjetil T.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QMwUHm019649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 15:58:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QMwU4q019647; Wed, 26 Mar 2008 15:58:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QMwT4e019641 for <[e-mail]>; Wed, 26 Mar 2008 15:58:30 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.64.64] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 043F93D91; Wed, 26 Mar 2008 16:03:37 -0700 (PDT)
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Aaron Stone <[e-mail]>
To: Patrick Ben Koetter <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Standard to selectively disable rules in sieve script?
Date: Wed, 26 Mar 2008 15:58:27 -0700
References: <[e-mail]>
X-Mailer: Apple Mail (2.919.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Most of the Sieve clients don't actually parse the Sieve rulesets, =20
unfortunately. They tend to do what Avelsieve does, which is to leave =20=

itself a comment in a particular format (for Avelsieve, it's a =20
serialized PHP array) so that it knows what the next block of code does.

This does indeed limit interoperability of clients.

If the clients did all parse the Sieve itself, and could edit each =20
other's rules using their respective gui's, then actually I think we =20
would need some agreement on how to mark a rule inactive (so that it =20
could be left in the script and turned back on by another client =20
without having to re-create it). It's a good point, though I don't =20
have a good answer myself.

Aaron


On Mar 26, 2008, at 2:45 PM, Patrick Ben Koetter wrote:
>
> I've been reading the RFCs and couldn't find an answer to the =20
> following
> question:
>
> Is there a standard syntax/notation to disable a single rule/command =20=

> within a
> sieve script that contains more than one rule/command?
>
> I couldn't find anything in the RFCs, but what I found is that =20
> everybody seems
> to use comments to disable a rule. So far so good...
>
> The bad thing seems to be that even though everybody agrees to use =20
> comments
> nobody seems to agree on one way to do it - one way all =20
> implementations
> understand.
>
> My research indicates that interoperability among sieve script =20
> clients is lost
> when it comes to disabling rules.
>
> A script edited by avelsieve - this is pure fiction, I didn't test =20
> this, but
> it serves to proove my point - (probably) won't work for KMail, =20
> because KMail
> is unable to recognize rules that have been disabled by avelsieve =20
> and vice
> versa.
>
> If I am correct, then - in my eyes - this is a major drawback in =20
> making Sieve
> useful and popular.
>
> Am I missing something?
>
> Thanks,
>
> p@rick
>
> --=20
> state of mind
> Agentur f=FCr Kommunikation, Design und Softwareentwicklung
>
> Patrick Koetter            Tel: [phone]
> Echinger Strasse 3         Fax: [phone]
> 85386 Eching               Web: http://www.state-of-mind.de
>
> Amtsgericht M=FCnchen        Partnerschaftsregister PR 563
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QMGL5p015846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 15:16:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QMGL5Q015845; Wed, 26 Mar 2008 15:16:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QMGKPV015838 for <[e-mail]>; Wed, 26 Mar 2008 15:16:21 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 627124AC1B; Wed, 26 Mar 2008 23:16:19 +0100 (CET)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1206569779-47076-1271; Wed, 26 Mar 2008 23:16:19 +0100
Message-Id: <[e-mail]>
Date: Wed, 26 Mar 2008 23:15:26 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Arnt Gulbrandsen writes:
> Alexey Melnikov writes:
>> Folks, Cyrus and I as chairs need more feedback on whether SHOULDs 
>> need to be changed to MUSTs. See my forwarded reply.
>
> I don't mind making these MUST.

I guess I really mean "I don't mind, but I don't really see the point 
and SHOULD seems strong enough". Quoting 2119:

    ... there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QLjOwZ013612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 14:45:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QLjOAY013611; Wed, 26 Mar 2008 14:45:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.state-of-mind.de (mail.state-of-mind.de [194.126.158.26]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QLjLIw013604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 26 Mar 2008 14:45:23 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by mail.state-of-mind.de (Postfix) with ESMTP id B3A0480F9FE; Wed, 26 Mar 2008 22:46:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=state-of-mind.de; s=mail0801; t=1206568004; bh=LE43ffBuAX9KjZmNR8jvSG/X5GUF/XL9893IYy XAzR4=; h=X-Virus-Scanned:Date:From:To:Subject:Message-ID: Mail-Followup-To:MIME-Version:Content-Type:Content-Disposition: Content-Transfer-Encoding:User-Agent; b=PUSwsuiyLEpv6VVsDYnE8eo7Sp Q+eaaJMLmU5e55Um//a8PrPDX+WWg0M0kcnfaSUO+4bIltQO+Fvl/6q1LkPi0+aWDXn v/QvRWXB2GfmRWuL4wip+gzEkeHEccKusfYZhrkHeXV7M41isuCMloTaJDeNIaUMfvb 4h01sS8Ww3o=
X-Virus-Scanned: amavisd-new at state-of-mind.de
Received: from mail.state-of-mind.de ([127.0.0.1]) by localhost (mail.state-of-mind.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ALgj2c4AfP0u; Wed, 26 Mar 2008 22:46:44 +0100 (CET)
Received: from state-of-mind.de (gw.state-of-mind.de [62.245.202.194]) by mail.state-of-mind.de (Postfix) with ESMTP id 08D2C80F9CE; Wed, 26 Mar 2008 22:46:44 +0100 (CET)
Date: Wed, 26 Mar 2008 22:45:19 +0100
From: Patrick Ben Koetter <[e-mail]>
To: [e-mail]
Subject: Standard to selectively disable rules in sieve script?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've been reading the RFCs and couldn't find an answer to the following
question:

Is there a standard syntax/notation to disable a single rule/command within a
sieve script that contains more than one rule/command?

I couldn't find anything in the RFCs, but what I found is that everybody seems
to use comments to disable a rule. So far so good...

The bad thing seems to be that even though everybody agrees to use comments
nobody seems to agree on one way to do it - one way all implementations
understand.

My research indicates that interoperability among sieve script clients is lost
when it comes to disabling rules.

A script edited by avelsieve - this is pure fiction, I didn't test this, but
it serves to proove my point - (probably) won't work for KMail, because KMail
is unable to recognize rules that have been disabled by avelsieve and vice
versa.

If I am correct, then - in my eyes - this is a major drawback in making Sieve
useful and popular.

Am I missing something?

Thanks,

p@rick

-- 
state of mind
Agentur für Kommunikation, Design und Softwareentwicklung

Patrick Koetter            Tel: [phone]
Echinger Strasse 3         Fax: [phone]
85386 Eching               Web: http://www.state-of-mind.de

Amtsgericht München        Partnerschaftsregister PR 563



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QHWnEm086692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 10:32:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QHWnOd086691; Wed, 26 Mar 2008 10:32:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QHWms3086684 for <[e-mail]>; Wed, 26 Mar 2008 10:32:49 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 9E8A94ACFD; Wed, 26 Mar 2008 18:32:47 +0100 (CET)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1206552767-47076-1160; Wed, 26 Mar 2008 18:32:47 +0100
Message-Id: <[e-mail]>
Date: Wed, 26 Mar 2008 18:31:54 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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 writes:
> Folks, Cyrus and I as chairs need more feedback on whether SHOULDs 
> need to be changed to MUSTs. See my forwarded reply.

I don't mind making these MUST.

Except that I do just a little, but I'd wiggle even in case of MUST. 
Details below.

>>>   o  The "Subject:" field of the notification message MUST
...

If I were to implement notify-mailto, my code might use different RFC 
2047 encoding. If the original subject is invalid in some way I 
wouldn't respond in kind.

>> The part that reads:
>>
>>      If ":from" is not specified or is not valid, the envelope sender 
>>      of the notification message SHOULD be set either to the 
>>      envelope "to" field from the triggering message, as used by 
>>      Sieve, or to a fixed email address (so it "comes from the 
>>      notification system"), at the discretion of the implementation.
>>
>> already list all possible alternatives, so I don't think it is a 
>> SHOULD either.

Those aren't all possible alternatives, so although I don't mind MUST I 
rather like keeping SHOULD. (One other alternative is a system address 
with a single-use subaddress.)

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QHWX1g086674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 10:32:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QHWXCl086673; Wed, 26 Mar 2008 10:32:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QHWT3a086649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 26 Mar 2008 10:32:32 -0700 (MST) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m2QHWJjj002336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 13:32:19 -0400 (EDT)
Date: Wed, 26 Mar 2008 13:32:19 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Barry Leiba <[e-mail]>, [e-mail]
cc: [e-mail]
Subject: Re: secdir review of draft-ietf-sieve-notify-mailto-07.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 Wednesday, March 26, 2008 01:13:33 PM -0400 Barry Leiba 
<[e-mail]> wrote:

> In particular, I don't agree with Alexey's thought that if WE can't think
> of an alternative value for a field, our advice should be MUST.  I much
> prefer the other approach: if there's not a compelling reason for MUST,
> make it SHOULD and let the implementation determine whether there's a
> good reason not to comply with that (remember the meaning of SHOULD).

I agree with Barry here.  This is exactly what SHOULD is for.

-- Jeff



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QHDgOU084597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 10:13:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QHDg3v084596; Wed, 26 Mar 2008 10:13:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QHDcTr084588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 26 Mar 2008 10:13:41 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m2QHDZIw010017 for <[e-mail]>; Wed, 26 Mar 2008 13:13:35 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2QHDZS2392160 for <[e-mail]>; Wed, 26 Mar 2008 13:13:35 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m2QHDZuV006433 for <[e-mail]>; Wed, 26 Mar 2008 13:13:35 -0400
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m2QHDZxK006425 for <[e-mail]>; Wed, 26 Mar 2008 13:13:35 -0400
Received: from Uranus-009002090184.watson.ibm.com ([9.2.90.184]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1206551614.6596; Wed, 26 Mar 2008 12:13:34 -0400
Message-ID: <[e-mail]>
Date: Wed, 26 Mar 2008 13:13:33 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: secdir review of draft-ietf-sieve-notify-mailto-07.txt
References: <[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>

> Folks, Cyrus and I as chairs need more feedback on whether SHOULDs need 
> to be changed to MUSTs. See my forwarded reply.


Alexey didn't forward my response to Hannes's review, so here's the 
relevant part of it:

--------------------------------------------------------
On the SHOULD vs MUST list, Alexey has actually had the same questions. 
  It's a clarification I've recently put in, because the text had said 
"is" (as in, "If the mailto URI contains a "body" header, the value of 
that header is used as the body of the notification message.")

I considered it this way:  In cases where it seemed that it really 
matters -- that some sense of interoperability of notifications is 
affected -- I used MUST. Otherwise, I used SHOULD or MAY.  In other 
words, I tried to avoid using MUST, where MUST wasn't necessary.

Alexey commented to me that it seemed to him that if there was no other 
reasonable choice, we ought to have MUST.  On the other hand, it seems 
to me that if there's not a *reason* for MUST, we ought to leave the 
choice to the implementor (or to whoever configures the system, or 
whatever), rather than being needlessly specific about something that 
really doesn't matter.
--------------------------------------------------------

I'm willing to change to MUST (obviously, I will if that's the WG 
consensus), but my strong sense is that it's wrong to prescribe 
behaviour that doesn't matter.  For Sieve notifications, it seems to me 
that "interoperability" means that one can move a script to another 
Sieve implementation and get reasonably consistent results in the 
notifications, such that the user would have a substantially similar 
experience.  My sense, there, is that what matters most is the subject 
of the message, so that's the only MUST (apart from Auto-Submitted, 
which has a functional purpose).  The other part that's probably 
important is the body, but there are various reasons for an 
implementation to want to control the body -- security configuration, 
notification infrastructure, whatever.  So that's a SHOULD.

In particular, I don't agree with Alexey's thought that if WE can't 
think of an alternative value for a field, our advice should be MUST.  I 
much prefer the other approach: if there's not a compelling reason for 
MUST, make it SHOULD and let the implementation determine whether 
there's a good reason not to comply with that (remember the meaning of 
SHOULD).

I normally don't like SHOULD in protocols.  This is a case where I think 
SHOULD is entirely appropriate.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QG3JGw076361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 09:03:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QG3JEK076360; Wed, 26 Mar 2008 09:03:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QG3ISi076353 for <[e-mail]>; Wed, 26 Mar 2008 09:03:18 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R-pzxQBh6H=[e-mail]>; Wed, 26 Mar 2008 16:03:17 +0000
Message-ID: <[e-mail]>
Date: Wed, 26 Mar 2008 16:02:48 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
References: <[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>

Folks, Cyrus and I as chairs need more feedback on whether SHOULDs need 
to be changed to MUSTs. See my forwarded reply.

Alexey Melnikov wrote:

> Subject:
> Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt
> From:
> Alexey Melnikov <[e-mail]>
> Date:
> Wed, 26 Mar 2008 13:04:19 +0000
> To:
> Hannes Tschofenig <[e-mail]>
>
> To:
> Hannes Tschofenig <[e-mail]>
> CC:
> [e-mail], [e-mail], Cyrus Daboo 
> <[e-mail]>, Lisa Dusseault <[e-mail]>
>
>
> Hi Hannes,
> Below are my opinions as a Sieve WG participant and not as the Sieve 
> WG chair:
>
> Hannes Tschofenig wrote:
> [...]
>
>>   o  The "To:" header field and the envelope recipient(s) of the
>>      notification message SHOULD be set to the address(es) specified in
>>      the URI (including any URI headers where the hname is "to").
>>
>> This could be a MUST as well. Otherwise you might want to say to what 
>> it is set in other cases.  
>>
> Indeed.
>
>>   o  The "Subject:" field of the notification message MUST contain the
>>      value defined by the :message notify tag, as described in
>>      [Notify].  If there is no :message tag and there is a "subject"
>>      header on the URI, then that value SHOULD be used.  If that is
>>      also absent, the subject SHOULD be retained from the triggering
>>      message.  Note that Sieve [Variables] can be used to advantage
>>      here, as shown in the example in Section 3.
>>
>>
>> Shouldn't the last SHOULD be a MUST? There do not seem to be too many 
>> other useful choices.
>
> Agreed. The only other choice I can think of is an implementation 
> defined string. I am not sure it is a good choice, but if it is, it 
> should be explicitly listed.
>
> Actually I think that both SHOULDs should be MUSTs.
> I am just imagining a support person trying to argue with a customer 
> about why a particular notification email had wrong subject, when the 
> "subject" URI header was specified.
>
>>   o  The "From:" header field of the notification message SHOULD be set
>>      to the value of the ":from" parameter to the notify action, if one
>>      is specified, has email address syntax and is valid according to
>>      the implementation specific security checks (see Section 3.3 of
>>      [Notify]).  If ":from" is not specified or is not valid, the
>>      "From:" header field of the notification message SHOULD be set
>>      either to the envelope "to" field from the triggering message, as
>>      used by Sieve, or to a fixed email address (so it "comes from the
>>      notification system"), at the discretion of the implementation.
>>      This may not be overridden by a "from" URI header, and any such
>>      URI header MUST be ignored.
>>
>>   o  If the envelope sender of the triggering message is empty, the
>>      envelope sender of the notification message MUST be empty as well,
>>      to avoid message loops.  Otherwise, the envelope sender of the
>>      notification message SHOULD be set to the value of the ":from"
>>      parameter to the notify action, if one is specified, has email
>>      address syntax and is valid according to the implementation
>>      specific security checks (see Section 3.3 of [Notify]).  If
>>      ":from" is not specified or is not valid, the envelope sender of
>>      the notification message SHOULD be set either to the envelope "to"
>>      field from the triggering message, as used by Sieve, or to a fixed
>>      email address (so it "comes from the notification system"), at the
>>      discretion of the implementation.  This may not be overridden by a
>>      "from" URI header, and any such URI header MUST be ignored.
>>
>>
>> For these two paragraphs the same question applies; why a SHOULD 
>> instead of a MUST
>>
> I also think the SHOULDs should be MUSTs here.
>
> I think  "address ... is valid according to the implementation 
> specific security checks" already provides enough leeway to 
> implementations if they want not to use a particular :from value.
>
> The part that reads:
>
>      If ":from" is not specified or is not valid, the envelope sender of
>      the notification message SHOULD be set either to the envelope "to"
>      field from the triggering message, as used by Sieve, or to a fixed
>      email address (so it "comes from the notification system"), at the
>      discretion of the implementation.
>
> already list all possible alternatives, so I don't think it is a 
> SHOULD either.
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QD83No059880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 06:08:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QD83H2059879; Wed, 26 Mar 2008 06:08:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QD8243059873 for <[e-mail]>; Wed, 26 Mar 2008 06:08:03 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 26 Mar 2008 13:07:58 +0000
Message-ID: <[e-mail]>
Date: Wed, 26 Mar 2008 13:07:38 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Content-Type: multipart/mixed; boundary="------------090204080804030901070008"
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>

--------------090204080804030901070008
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



--------------090204080804030901070008
Content-Type: message/rfc822;
 name="Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine.isode.net (Isode M-Box/14.2v0) with LMTP; Wed, 26 Mar 2008 13:04:40 +0000 (GMT)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) 
          by rufus.isode.com (submission channel) via TCP with ESMTPA 
          id <[e-mail]>; Wed, 26 Mar 2008 13:04:40 +0000
Message-ID: <[e-mail]>
Date: Wed, 26 Mar 2008 13:04:19 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
            Gecko/20050915
X-Accept-Language: en-us, en
To: Hannes Tschofenig <[e-mail]>
CC: [e-mail], [e-mail], Cyrus Daboo <[e-mail]>, Lisa Dusseault <[e-mail]>
Subject: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt
References: <[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

Hi Hannes,
Below are my opinions as a Sieve WG participant and not as the Sieve WG 
chair:

Hannes Tschofenig wrote:
 [...]

>   o  The "To:" header field and the envelope recipient(s) of the
>      notification message SHOULD be set to the address(es) specified in
>      the URI (including any URI headers where the hname is "to").
>
>This could be a MUST as well. Otherwise you might want to say to what it is set in other cases. 
>  
>
Indeed.

>   o  The "Subject:" field of the notification message MUST contain the
>      value defined by the :message notify tag, as described in
>      [Notify].  If there is no :message tag and there is a "subject"
>      header on the URI, then that value SHOULD be used.  If that is
>      also absent, the subject SHOULD be retained from the triggering
>      message.  Note that Sieve [Variables] can be used to advantage
>      here, as shown in the example in Section 3.
>
>
>Shouldn't the last SHOULD be a MUST? There do not seem to be too many other useful choices. 
>
Agreed. The only other choice I can think of is an implementation 
defined string. I am not sure it is a good choice, but if it is, it 
should be explicitly listed.

Actually I think that both SHOULDs should be MUSTs.
I am just imagining a support person trying to argue with a customer 
about why a particular notification email had wrong subject, when the 
"subject" URI header was specified.

>   o  The "From:" header field of the notification message SHOULD be set
>      to the value of the ":from" parameter to the notify action, if one
>      is specified, has email address syntax and is valid according to
>      the implementation specific security checks (see Section 3.3 of
>      [Notify]).  If ":from" is not specified or is not valid, the
>      "From:" header field of the notification message SHOULD be set
>      either to the envelope "to" field from the triggering message, as
>      used by Sieve, or to a fixed email address (so it "comes from the
>      notification system"), at the discretion of the implementation.
>      This may not be overridden by a "from" URI header, and any such
>      URI header MUST be ignored.
>
>   o  If the envelope sender of the triggering message is empty, the
>      envelope sender of the notification message MUST be empty as well,
>      to avoid message loops.  Otherwise, the envelope sender of the
>      notification message SHOULD be set to the value of the ":from"
>      parameter to the notify action, if one is specified, has email
>      address syntax and is valid according to the implementation
>      specific security checks (see Section 3.3 of [Notify]).  If
>      ":from" is not specified or is not valid, the envelope sender of
>      the notification message SHOULD be set either to the envelope "to"
>      field from the triggering message, as used by Sieve, or to a fixed
>      email address (so it "comes from the notification system"), at the
>      discretion of the implementation.  This may not be overridden by a
>      "from" URI header, and any such URI header MUST be ignored.
>
>
>For these two paragraphs the same question applies; why a SHOULD instead of a MUST
>
I also think the SHOULDs should be MUSTs here.

I think  "address ... is valid according to the implementation specific 
security checks" already provides enough leeway to implementations if 
they want not to use a particular :from value.

The part that reads:

      If ":from" is not specified or is not valid, the envelope sender of
      the notification message SHOULD be set either to the envelope "to"
      field from the triggering message, as used by Sieve, or to a fixed
      email address (so it "comes from the notification system"), at the
      discretion of the implementation.

already list all possible alternatives, so I don't think it is a SHOULD 
either.


--------------090204080804030901070008--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QD7po9059844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 06:07:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QD7pcc059843; Wed, 26 Mar 2008 06:07:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QD7juO059831 for <[e-mail]>; Wed, 26 Mar 2008 06:07:50 -0700 (MST) (envelope-from [e-mail])
Received: by MSA with id 5EF61C1D1BFEFD0740CE3458AB8DA718E430207A
Received: from webmail.noc.uoa.gr (webmail.noc.uoa.gr [195.134.100.73]) by msa.uoa.gr (8.14.1/8.14.1) with ESMTP id m2QD7hVp012193 for <[e-mail]>; Wed, 26 Mar 2008 15:07:43 +0200 (EET)
Received: from 88.197.8.246 (SquirrelMail authenticated user avel) by webmail.uoa.gr with HTTP; Wed, 26 Mar 2008 15:07:43 +0200 (EET)
Message-ID: <[e-mail]>
Date: Wed, 26 Mar 2008 15:07:43 +0200 (EET)
Subject: Re: Proposed charter change
From: "Alexandros Vellis" <[e-mail]>
To: "SIEVE" <[e-mail]>
User-Agent: SquirrelMail/1.4.12 [SVN] [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: 5EF61C1D1BFEFD0740CE3458AB8DA718E430207A
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 following, as an implementor of UI for creation of scripts. Most of
the features I "intend to support" will depend on the features that first
become available in servers. :)

> (1) Finish work on existing in-progress Working Group documents:
>
> 	(a) Body (draft-ietf-sieve-body-07.txt)
supported

> 	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
support an old notify version, will update to all new notification drafts
in the future

> 	(c) Edit header (draft-ietf-sieve-editheader-10.txt)
Intend to support in the future

> 	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
Intend to support in the future

> 	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)
partially supported, intend to complete implementation

>
> (2) Finalize and publish the following SIEVE extensions as proposed
> standards:
>
> 	(a) Date/Index (draft-freed-sieve-date-index-08.txt)
Intend to support in the future

> 	(b) iHave (draft-freed-sieve-ihave-01.txt)
No plans

> 	(c) Environment (draft-freed-sieve-environment-03.txt)
No plans

> 	(d) Notary (draft-freed-sieve-notary-01.txt)
No plans

> 	(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
Intend to support in the future. One of the most interesting drafts for
me. Allowing people to use XML tools to manipulate Sieve scripts would,
IMHO, help advance the development and popularity of UI tools for editing
Sieve.

> 	(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
Intend to support in the future

> 	(g) ManageSIEVE (draft-martin-managesieve-08.txt)
Intend to update to new revision

> 	(h) RegEx (draft-ietf-sieve-regex-00.txt)
supported

> 	(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
Intend to support in the future

> 	(k) Include/multi-script (draft-daboo-sieve-include-05.txt)
Intend to support in the future

> 	(k) Address data (draft-melnikov-sieve-external-lists-01)
Intend to support in the future :-)

-- 
Alexandros Vellis



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QD7dWU059820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Mar 2008 06:07:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2QD7dIC059819; Wed, 26 Mar 2008 06:07:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2QD7cXT059809 for <[e-mail]>; Wed, 26 Mar 2008 06:07:39 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 26 Mar 2008 13:07:36 +0000
Message-ID: <[e-mail]>
Date: Wed, 26 Mar 2008 13:07:17 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Content-Type: multipart/mixed; boundary="------------050106050600080504060709"
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>

--------------050106050600080504060709
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



--------------050106050600080504060709
Content-Type: message/rfc822;
 name="[secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="[secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine.isode.net (Isode M-Box/14.2v0) with LMTP; Tue, 25 Mar 2008 21:02:46 +0000 (GMT)
Received: from pch.mit.edu ([18.7.21.90]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <[e-mail]>;
          Tue, 25 Mar 2008 21:02:18 +0000
X-SPF-Result: PASS rufus.isode.com: domain of mit.edu designates 18.7.21.90 as permitted sender
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2PL08SC019220;
	Tue, 25 Mar 2008 17:00:10 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
	[18.7.7.76])
	by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m2PKx6kx018838
	for <[e-mail]>; Tue, 25 Mar 2008 16:59:06 -0400
Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id
	m2PKwweW020288
	for <[e-mail]>; Tue, 25 Mar 2008 16:58:59 -0400 (EDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by mit.edu (Spam Firewall) with SMTP id C557A10449B5
	for <[e-mail]>; Tue, 25 Mar 2008 16:58:37 -0400 (EDT)
Received: (qmail invoked by alias); 25 Mar 2008 20:58:36 -0000
Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4])
	[91.154.103.163]
	by mail.gmx.net (mp054) with SMTP; 25 Mar 2008 21:58:36 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+VQh0di2KVbhrxN2Iyn2nZBiOfbegnacdzilvrht
	CYvo6/79iJCpxz
Message-ID: <[e-mail]>
Date: Tue, 25 Mar 2008 22:58:49 +0200
From: Hannes Tschofenig <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: [e-mail]
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: [e-mail]
Subject: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: Security Area Directorate <secdir.mit.edu>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/secdir>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <https://mailman.mit.edu/mailman/private/secdir>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/secdir>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These comments 
were written primarily for the benefit of the security area directors.  Document 
editors and WG chairs should treat these comments just like any other last call 
comments.

draft-ietf-sieve-notify-mailto-07.txt is an extension to draft-ietf-sieve-notify-12
to allow notifications to be sent by electronic mail.

Although I have not follwed the SIEVE work this document is fairly easy to read. 
The security consideration section is short but points to draft-ietf-sieve-notify-12.txt
and SIEVE. Fine to me! 

I was only wondering a bit about the placements of SHOULDs instead of MUSTs. 

A few examples below: 


   o  If the mailto URI contains a "body" header, the value of that
      header SHOULD be used as the body of the notification message.  If
      there is no "body" header, it is up to the implementation whether
      to leave the body empty or to use an excerpt of the original
      message.


Why isn't the first SHOULD a MUST? 


   o  The "Received:" fields from the triggering message MAY be retained
      in the notification message, as these may help detect and prevent
      mail loops.  The "Auto-Submitted" header field MUST be placed
      above these (see Section 2.7.1).  URI headers with hname
      "received" are considered unsafe, and will be ignored.

Why is this a MAY and not a MUST? 


   o  The "To:" header field and the envelope recipient(s) of the
      notification message SHOULD be set to the address(es) specified in
      the URI (including any URI headers where the hname is "to").

This could be a MUST as well. Otherwise you might want to say to what it is set in other cases. 


   o  The "Subject:" field of the notification message MUST contain the
      value defined by the :message notify tag, as described in
      [Notify].  If there is no :message tag and there is a "subject"
      header on the URI, then that value SHOULD be used.  If that is
      also absent, the subject SHOULD be retained from the triggering
      message.  Note that Sieve [Variables] can be used to advantage
      here, as shown in the example in Section 3.


Shouldn't the last SHOULD be a MUST? There do not seem to be too many other useful choices. 


   o  The "From:" header field of the notification message SHOULD be set
      to the value of the ":from" parameter to the notify action, if one
      is specified, has email address syntax and is valid according to
      the implementation specific security checks (see Section 3.3 of
      [Notify]).  If ":from" is not specified or is not valid, the
      "From:" header field of the notification message SHOULD be set
      either to the envelope "to" field from the triggering message, as
      used by Sieve, or to a fixed email address (so it "comes from the
      notification system"), at the discretion of the implementation.
      This may not be overridden by a "from" URI header, and any such
      URI header MUST be ignored.

   o  If the envelope sender of the triggering message is empty, the
      envelope sender of the notification message MUST be empty as well,
      to avoid message loops.  Otherwise, the envelope sender of the
      notification message SHOULD be set to the value of the ":from"
      parameter to the notify action, if one is specified, has email
      address syntax and is valid according to the implementation
      specific security checks (see Section 3.3 of [Notify]).  If
      ":from" is not specified or is not valid, the envelope sender of
      the notification message SHOULD be set either to the envelope "to"
      field from the triggering message, as used by Sieve, or to a fixed
      email address (so it "comes from the notification system"), at the
      discretion of the implementation.  This may not be overridden by a
      "from" URI header, and any such URI header MUST be ignored.


For these two paragraphs the same question applies; why a SHOULD instead of a MUST



Ciao
Hannes


_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir

--------------050106050600080504060709--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PIcAnd055442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Mar 2008 11:38:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2PIcA3U055441; Tue, 25 Mar 2008 11:38:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PIc7wE055427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 25 Mar 2008 11:38:08 -0700 (MST) (envelope-from [e-mail])
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m2PIc6fI014409 for <[e-mail]>; Tue, 25 Mar 2008 14:38:06 -0400
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2PIc3xI191176 for <[e-mail]>; Tue, 25 Mar 2008 12:38:03 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m2PIc3CZ003191 for <[e-mail]>; Tue, 25 Mar 2008 12:38:03 -0600
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m2PIc2YH003170; Tue, 25 Mar 2008 12:38:03 -0600
Received: from Uranus-009002042023.watson.ibm.com ([9.2.42.23]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1206470282.6265; Tue, 25 Mar 2008 13:38:02 -0400
Message-ID: <[e-mail]>
Date: Tue, 25 Mar 2008 14:38:02 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: Proposed charter change
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>

> Please review this and comment.

I think the proposed recharter is fine.

> We would like to see a "show of hands" from implementers on each of the 
> new extensions being proposed so that we can judge the interest in each.

I'm currently out of the loop of implementing.  While I'd like to change 
that, it's not likely with my current set of projects.  I don't know 
what plans, if any, the product divisions here have for Sieve.

> (3) Work on a "Benefits of SIEVE" guide for client and server vendors that:
>     (a) Describes the SIEVE protocol and its suite of extensions.
>     (b) Explains the benefits of server-side filtering in practical terms.
>     (c) Shows how client-side filtering can be migrated to SIEVE.

I'll happily co-author this, and perhaps take a stab at a first draft. 
One or two co-authors would be nice.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PGtKvE044110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Mar 2008 09:55:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2PGtKPc044109; Tue, 25 Mar 2008 09:55:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PGtJ67044102 for <[e-mail]>; Tue, 25 Mar 2008 09:55:19 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 25 Mar 2008 09:55:16 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 25 Mar 2008 09:55:13 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Tue, 25 Mar 2008 09:52:49 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-freed-sieve-environment-04
In-reply-to: "Your message dated Tue, 25 Mar 2008 16:35:16 +0100" <1206459316.16281.2.camel@oslhomkje>
References: <[e-mail]> <[e-mail]> <1206459316.16281.2.camel@oslhomkje>
To: Kjetil Torgrim Homme <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1206464115; h=Date:	 From:Subject:MIME-version:Content-type; b=SD9Jq0AjUfYGooiFdUVfq5si6 8iZoAGEkwKlTMW3/ohLXgjYqAw/qXVlWH+wZi8iMApm2CEnYryzGUZwZUUxSQ==
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, 2008-03-23 at 10:50 -0700, Ned Freed wrote:
> > Also a good point. I have added:
> >
> >   The remote-host environment item defined in this specification is usually
> >   determined by performing a PTR DNS lookup on the client IP address. This
> >   information may come from an untrusted source. For example, the test:
> >
> >     if environment :matches "remote-host" "*.mydomain.com" { ... }
> >
> >   is not a good way to test whether the message came from 'outside' becaus
> >   anyone who can create a PTR record can create one that refers to whatever
> >   domain they choose.
> [...]
> >
> > I think a simpler way to handle this is to say that the name will
> > be blank if it cannot be resolved into a host name. How about:
> >
> >  "remote-host"
> >            => Host name of remote SMTP/LMTP/Submission client, if
> >               applicable and available. The empty string will be returned
> >               if for some reason this information cannot be obtained for
> >               the current client.

> sorry, I don't understand what this means.  is the existence of a PTR
> record sufficient?

Who knows? The mechanism used to obtian the remote-host isn't (and should not
be) specified. As such, a PTR could be sufficient. Or it may not be - some
systems do a backwards-forwards check. And there can even be cases when a PTR
record isn't needed - DNS names aren't the only game in town, you know.

> it seems so, given the above added caveat.  if so --
> how is a script able to detect a forgery?

It can't. That's the point.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PFZbGv035662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Mar 2008 08:35:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2PFZb7b035661; Tue, 25 Mar 2008 08:35:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PFZZ5e035649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 25 Mar 2008 08:35:37 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JeBBU-0000RX-QL; Tue, 25 Mar 2008 16:35:32 +0100
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx2.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1JeBBQ-0003h2-4v; Tue, 25 Mar 2008 16:35:28 +0100
Received: from pat-gw.osl.fast.no ([217.144.235.5] helo=[192.168.2.4]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <[e-mail]>) id 1JeBBP-0003fB-Dh; Tue, 25 Mar 2008 16:35:28 +0100
Subject: Re: Comments on draft-freed-sieve-environment-04
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 25 Mar 2008 16:35:16 +0100
Message-Id: <1206459316.16281.2.camel@oslhomkje>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, none)
X-UiO-Scanned: 0BCE3E91C581F57FB166B5180A277F8902038558
X-UiO-SR-test: 4EB7E043F1E04A429DEFDBA52F967E09DDA0A0C9
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 949 total 7512551 max/h 8345 blacklist 0 greylist 0 ratelimit 0
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, 2008-03-23 at 10:50 -0700, Ned Freed wrote:
> Also a good point. I have added:
> 
>   The remote-host environment item defined in this specification is usually
>   determined by performing a PTR DNS lookup on the client IP address. This
>   information may come from an untrusted source. For example, the test:
> 
>     if environment :matches "remote-host" "*.mydomain.com" { ... }
> 
>   is not a good way to test whether the message came from 'outside' becaus
>   anyone who can create a PTR record can create one that refers to whatever
>   domain they choose.
[...]
> 
> I think a simpler way to handle this is to say that the name will
> be blank if it cannot be resolved into a host name. How about:
> 
>  "remote-host"
>            => Host name of remote SMTP/LMTP/Submission client, if
>               applicable and available. The empty string will be returned
>               if for some reason this information cannot be obtained for
>               the current client.

sorry, I don't understand what this means.  is the existence of a PTR
record sufficient?  it seems so, given the above added caveat.  if so --
how is a script able to detect a forgery?

-- 
med venleg helsing,
Kjetil T.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PAZKTT098348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Mar 2008 03:35:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2PAZKQw098346; Tue, 25 Mar 2008 03:35:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PAZIRm098327 for <[e-mail]>; Tue, 25 Mar 2008 03:35:19 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 25 Mar 2008 10:35:14 +0000
Message-ID: <[e-mail]>
Date: Mon, 24 Mar 2008 21:42:09 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Recent changes to draft-ietf-sieve-notify-mailto
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Barry kindly summarized his changes in -07. I though that they should 
> be mentioned on the mailing list.
>
> Barry Leiba wrote:
>
>> I've just submitted an -07 draft, as agreed in Philadelphia, and 
>> that's the version that should be reviewed for Last Call.  There are 
>> three main changes:
>>
>> 1. In section 2.7, I changed a number of instances of "is" to "MUST 
>> be" or "SHOULD be", as in 'The "From:" header field of the 
>> notification message is set to [...].'
>
Speaking as an individual WG participant: I disagree with some new 
SHOULDs (I think they must be MUSTs ;-)) and will post a separate 
message on this.

>> 2. In section 2.7, I qualified Auto-Submitted as a trace field, and 
>> specified that it MUST be placed above the Received fields that were 
>> copied from the triggering message.  Now that Auto-Submitted is 
>> referred to in two places, I created a new section, 2.7.1, that 
>> specifies it.
>>
>> 3. I added two OPTIONAL parameters to auto-submitted (owner-email and 
>> owner-token), and I changed the registry definition and the example 
>> accordingly.
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PAZKrx098349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Mar 2008 03:35:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2PAZKtb098347; Tue, 25 Mar 2008 03:35:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PAZI3R098328 for <[e-mail]>; Tue, 25 Mar 2008 03:35:19 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 25 Mar 2008 10:35:14 +0000
Message-ID: <[e-mail]>
Date: Mon, 24 Mar 2008 21:40:42 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Recent changes to draft-ietf-sieve-notify-mailto
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Barry kindly summarized his changes in -07. I though that they should be 
mentioned on the mailing list.

Barry Leiba wrote:

> I've just submitted an -07 draft, as agreed in Philadelphia, and 
> that's the version that should be reviewed for Last Call.  There are 
> three main changes:
>
> 1. In section 2.7, I changed a number of instances of "is" to "MUST 
> be" or "SHOULD be", as in 'The "From:" header field of the 
> notification message is set to [...].'
>
> 2. In section 2.7, I qualified Auto-Submitted as a trace field, and 
> specified that it MUST be placed above the Received fields that were 
> copied from the triggering message.  Now that Auto-Submitted is 
> referred to in two places, I created a new section, 2.7.1, that 
> specifies it.
>
> 3. I added two OPTIONAL parameters to auto-submitted (owner-email and 
> owner-token), and I changed the registry definition and the example 
> accordingly.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PAZGRw098321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Mar 2008 03:35:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2PAZGa0098320; Tue, 25 Mar 2008 03:35:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2PAZDVi098310 for <[e-mail]>; Tue, 25 Mar 2008 03:35:14 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 25 Mar 2008 10:35:12 +0000
Message-ID: <[e-mail]>
Date: Mon, 24 Mar 2008 21:10:06 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: Philip Guenther <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-freed-sieve-environment-04
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>

(Speaking as an individual contributor.)

Ned Freed wrote:

>> Perhaps there should be a prefix on the value that indicates the 
>> address family, or it should be formatted like the 'host'
>> part of URI?
>
>> Note that the obvious test of
>>      environment :matches "remote-ip" "*.*.*.*"
>
>> will match an IPv6 address literal if the implementation uses the
>>      x:x:x:x:x:x:d.d.d.d
>> form, such as with the IPv4 compat addresses, ala "::FFFF:1.2.3.4".
>
>> (Yes, this thought was triggered by the "IPv6-only" experiment during 
>> the
>> IETF technical plenary.)
>
> Well, I certainly hope that for any given address there's exactly one 
> way it
> will end up being represented. If that's not the case then there's a 
> major
> problem that goes far beyond this specific issue.
>
> There's also the issue of how any future sort of address should be 
> handled.
> Since RFC 2821 has already had to deal with this I think the best way 
> to handle
> it is by referring to the formats defined there. I currently have:
>
> "remote-ip"
>           => IP address of remote SMTP/LMTP/Submission client, if
>              applicable and available. IPv4, IPv6, and other types of
>              addresses are respectively represented in the formats
>              defined by the IPv4-address-literal, IPv6-address-literal,
>              and General-address-literal productions defined in
>              [RFC 2821] section 4.1.3.

As a side note, I think RFC 2821 IPv6 format sucks, because it doesn't 
match what socket functions return on various OSes. (RFC 2821 uses
"IPv6:" prefix). But it is too late to fix that. So, under the 
circumstances, your proposal is quite reasonable.

>> There probably should be a security consideration that explains that the
>> value of the "remote-host" item may be controlled by an untrusted 
>> source.
>> For example, the test
>>      environment :matches "remote-host" "*.mydomain.com"
>
>> is *not* a good way to test whether the message came from 'outside' 
>> unless
>> the implementation there's some sort of IP->host->IP consistency check
>> made.
>
> Also a good point. I have added:
>
>  The remote-host environment item defined in this specification is 
> usually
>  determined by performing a PTR DNS lookup on the client IP address. This
>  information may come from an untrusted source. For example, the test:
>
>    if environment :matches "remote-host" "*.mydomain.com" { ... }
>
>  is not a good way to test whether the message came from 'outside' becaus

typo: because

>  anyone who can create a PTR record can create one that refers to 
> whatever
>  domain they choose. 

The text looks good to me.

>> (The sendmail MTA faced the above issues some time ago for the 
>> pre-defined
>> variables it provides to its rulesets.  To quote the sendmail operations
>> guide, it defined variables as follows:
>>        ${client_addr}
>>             The  IP  address  of  the  SMTP   client.    IPv6
>>             addresses  are  tagged  with  "IPv6:"  before the
>>             address.  Defined in the SMTP server only.
>
>>        ${client_name}
>>             The host name of the SMTP client.   This  may  be
>>             the  client's  bracketed IP address in the form [
>>             nnn.nnn.nnn.nnn    ]    for    IPv4     and     [
>>             IPv6:nnnn:...:nnnn  ] for IPv6 if the client's IP
>>             address is not resolvable, or if it is resolvable
>>             but  the  IP  address  of  the  resolved hostname
>>             doesn't match the original IP  address.   Defined
>>             in    the    SMTP    server   only.    See   also
>>             ${client_resolve}.
>
> I think a simpler way to handle this is to say that the name will
> be blank if it cannot be resolved into a host name. How about:

I like that.

> "remote-host"
>           => Host name of remote SMTP/LMTP/Submission client, if
>              applicable and available. The empty string will be returned
>              if for some reason this information cannot be obtained for
>              the current client.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2O2sYgA091384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Mar 2008 19:54:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2O2sYvx091383; Sun, 23 Mar 2008 19:54:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2O2sWHe091376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 23 Mar 2008 19:54:33 -0700 (MST) (envelope-from [e-mail])
Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m2O2u9qX026966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Mar 2008 19:56:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1206327371; bh=J2thFoEZQb6PsT++XzSJYJl6fjR6Vs8Re/h6 PHGQTeI=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type:X-MM-Ex-RefId; b=LPO0SgYgbqupdsf3a47elm2 jx6ZtN2ohP6k1oraQ1rzeu9KgdC2ZVwDI8quECymQ1eQG08cIc+Q4aWFdvpzPkgJLs/ 41IMCwbUQcWoNNyAhPtVL5TAJPQHSQP/kTyIpJrm9uTIIgsINPJ1330PrnvJACTctPh yyemne/1Fh9gew=
Received: from [192.168.0.2] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m2O2s9ri022983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Mar 2008 19:54:27 -0700
X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m2O2s9ri022983
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1206327269; bh=J2thFoEZQb6PsT++XzSJYJl6fjR6Vs8Re/h6 PHGQTeI=; h=Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:User-Agent:MIME-Version:Content-Type: X-MM-Ex-RefId; b=Q5lz4nL4ubCXIxrkhzOCwik4eidQYZvcB8j804UoL+TcxfJ2v Ca9bhNt0cOKCrjrZKMrI1l6iYEG2MxEsREbqoDn3+wd4++9f9sDQlb6Uiv/gXDnYEdD 0QORcoADISR7LzKawTdQoX+XP3TSc9DEJ3gFjHbwI38Cvn28PKgfK28=
Date: Sun, 23 Mar 2008 20:54:09 -0600
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Ned Freed <[e-mail]>
cc: [e-mail]
Subject: Re: Comments on draft-freed-sieve-environment-04
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.00 (BSO 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-MM-Ex-RefId: 149371::080323195428-0D54DB90-0DD55A7F/0-0/0-1
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, 23 Mar 2008, Ned Freed wrote:
<elided>

Looks good now, thanks.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2NL6enr058002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Mar 2008 14:06:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2NL6eid058001; Sun, 23 Mar 2008 14:06:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2NL6dkb057987 for <[e-mail]>; Sun, 23 Mar 2008 14:06:39 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 23 Mar 2008 14:06:16 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 23 Mar 2008 11:34:01 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Sun, 23 Mar 2008 10:50:10 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Comments on draft-freed-sieve-environment-04
In-reply-to: "Your message dated Wed, 19 Mar 2008 02:01:52 -0600" <[e-mail]>
References: <[e-mail]>
To: Philip Guenther <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1206306376; h=Date:	 From:Subject:MIME-version:Content-type; b=KIwB0UdCPSn/fVDSZQWVqYeqJ 3MSx/k8BeLeYBBk+KYEAprHbzLBOfayahcLvZkGYMb+w/c2GAzk6sG7u4BLKw==
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>

> If the SMTP session was over IPv6, what should the "remote-ip" environment
> item be set to?

I would think that in this case it would obviously be the IPv6 address.
However, I take your point that the format of such addresses needs to be
specified - the underlying standards for address formats having failed to
specify this with sufficient clarity or generality, it is now up to every
application protocol where such addresses appear to deal with it separately.
Sigh. Not the way it should be, but how it is.

  Perhaps there should be a prefix on the value that
> indicates the address family, or it should be formatted like the 'host'
> part of URI?

> Note that the obvious test of
>  	environment :matches "remote-ip" "*.*.*.*"

> will match an IPv6 address literal if the implementation uses the
>  	x:x:x:x:x:x:d.d.d.d
> form, such as with the IPv4 compat addresses, ala "::FFFF:1.2.3.4".

> (Yes, this thought was triggered by the "IPv6-only" experiment during the
> IETF technical plenary.)

Well, I certainly hope that for any given address there's exactly one way it
will end up being represented. If that's not the case then there's a major
problem that goes far beyond this specific issue.

There's also the issue of how any future sort of address should be handled.
Since RFC 2821 has already had to deal with this I think the best way to handle
it is by referring to the formats defined there. I currently have:

 "remote-ip"
           => IP address of remote SMTP/LMTP/Submission client, if
              applicable and available. IPv4, IPv6, and other types of
              addresses are respectively represented in the formats
              defined by the IPv4-address-literal, IPv6-address-literal,
              and General-address-literal productions defined in
              [RFC 2821] section 4.1.3.

> There probably should be a security consideration that explains that the
> value of the "remote-host" item may be controlled by an untrusted source.
> For example, the test
>  	environment :matches "remote-host" "*.mydomain.com"

> is *not* a good way to test whether the message came from 'outside' unless
> the implementation there's some sort of IP->host->IP consistency check
> made.

Also a good point. I have added:

  The remote-host environment item defined in this specification is usually
  determined by performing a PTR DNS lookup on the client IP address. This
  information may come from an untrusted source. For example, the test:

    if environment :matches "remote-host" "*.mydomain.com" { ... }

  is not a good way to test whether the message came from 'outside' becaus
  anyone who can create a PTR record can create one that refers to whatever
  domain they choose.

> (The sendmail MTA faced the above issues some time ago for the pre-defined
> variables it provides to its rulesets.  To quote the sendmail operations
> guide, it defined variables as follows:
>        ${client_addr}
>             The  IP  address  of  the  SMTP   client.    IPv6
>             addresses  are  tagged  with  "IPv6:"  before the
>             address.  Defined in the SMTP server only.

>        ${client_name}
>             The host name of the SMTP client.   This  may  be
>             the  client's  bracketed IP address in the form [
>             nnn.nnn.nnn.nnn    ]    for    IPv4     and     [
>             IPv6:nnnn:...:nnnn  ] for IPv6 if the client's IP
>             address is not resolvable, or if it is resolvable
>             but  the  IP  address  of  the  resolved hostname
>             doesn't match the original IP  address.   Defined
>             in    the    SMTP    server   only.    See   also
>             ${client_resolve}.

I think a simpler way to handle this is to say that the name will
be blank if it cannot be resolved into a host name. How about:

 "remote-host"
           => Host name of remote SMTP/LMTP/Submission client, if
              applicable and available. The empty string will be returned
              if for some reason this information cannot be obtained for
              the current client.


>        ${client_ptr}
>             The  result  of  the PTR lookup for the client IP
>             address.    Note:   this   is   the    same    as
>             ${client_name}  if  and only if ${client_resolve}
>             is OK.  Defined in the SMTP server only.

>        ${client_resolve}
>             Holds  the  result  of  the  resolve   call   for
>             ${client_name}.  Possible values are:

>                 OK        resolved successfully
>                 FAIL      permanent lookup failure
>                 FORGED    forward lookup doesn't match reverse lookup
>                 TEMP      temporary lookup failure

>             Defined   in  the  SMTP  server  only.   sendmail
>             performs a hostname lookup on the IP  address  of
>             the  connecting client.  Next the IP addresses of
>             that hostname are looked up.  If  the  client  IP
>             address  does  not  appear in that list, then the
>             hostname is maybe forged.  This is  reflected  as
>             the  value  FORGED  for  ${client_resolve} and it
>             also shows up in $_ as "(may be forged)".

> While client_ptr and client_resolve are probably overkill for the sieve
> environment extension, the tagging in client_addr and precise definition
> of when client_name contains a name and not an address literal seem like
> practical guidance in this area.)

I agree - see above for my proposed solution for this issue.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LHvj4i036414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2008 10:57:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2LHvjNe036413; Fri, 21 Mar 2008 10:57:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LHvin0036406 for <[e-mail]>; Fri, 21 Mar 2008 10:57:45 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id B2A163A6A05; Fri, 21 Mar 2008 11:00:01 -0700 (PDT)
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-editheader-11.txt 
Message-Id: <[e-mail]>
Date: Fri, 21 Mar 2008 11:00:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Email Filtering: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-11.txt
	Pages		: 12
	Date		: 2008-3-21
	
This document defines two new actions for the "Sieve" email
   filtering language that add and delete email header fields.

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

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LDYiF6012304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Mar 2008 06:34:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2LDYiEY012303; Fri, 21 Mar 2008 06:34:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2LDYhha012290 for <[e-mail]>; Fri, 21 Mar 2008 06:34:43 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 36EF43A6C27; Fri, 21 Mar 2008 06:36:59 -0700 (PDT)
X-idtracker: yes
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]>
Subject: Protocol Action: 'Sieve Email Filtering: Body  Extension' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Fri, 21 Mar 2008 06:37:00 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Sieve Email Filtering: Body Extension '
   <draft-ietf-sieve-body-09.txt> as a Proposed Standard

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

The IESG contact persons are Lisa Dusseault and Chris Newman.

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

Technical Summary
 
The SIEVE body extension adds tests for the occurrence of one or more
strings in the body of an email message.

The draft has a detailed description of how interactions with other
SIEVE extensions/actions are handled.

The security considerations section covers several identified security
concerns.

Working Group Summary

This document has been discussed and reviewed in the SIEVE Working Group.
There is strong consensus in the Working Group to publish this document
as a Proposed Standard.

Document Quality

A number of implementations of this extension have already been
developed and in some cases deployed. Most participants are eager to see
this specification published as an RFC.

Lisa Dusseault reviewed this spec for the IESG.

Document Shepherd: Cyrus Daboo <mailto:[e-mail]>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2KKsHTY026758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Mar 2008 13:54:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2KKsHWG026757; Thu, 20 Mar 2008 13:54:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2KKsFME026750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 20 Mar 2008 13:54:16 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m2KKsCdj020252 for <[e-mail]>; Thu, 20 Mar 2008 16:54:12 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2KKsC8o1072076 for <[e-mail]>; Thu, 20 Mar 2008 16:54:12 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m2KKsCnY008544 for <[e-mail]>; Thu, 20 Mar 2008 16:54:12 -0400
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m2KKsCC5008530 for <[e-mail]>; Thu, 20 Mar 2008 16:54:12 -0400
Received: from Uranus-009002042023.watson.ibm.com ([9.2.42.23]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1206046451.5369; Thu, 20 Mar 2008 15:54:11 -0400
Message-ID: <[e-mail]>
Date: Thu, 20 Mar 2008 16:54:11 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: action reject and smtp RCPT TO:
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]> <kfU0rHTCtRBPBX/[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>

Ned Freed said...
> AFAIK nobodhy is talking about not allowing this. The question is 
> whether or
> not we should specify all of the nuances involved in supporting this 
> mode of
> operation, and if we're going to whether or not this is the right place 
> to do
> it. I remain to be convinced of the need to specify this and I'm opposed to
> doing it in this document.

Where to do it is, I think, the key point.  And so I'll point out that 
Randy Gellens has a draft in lemonade, currently called "Notifications 
Architecture": 
http://tools.ietf.org/wg/lemonade/draft-ietf-lemonade-notifications/

The plan is to fold some Sieve-related stuff into it and perhaps rename 
it to "Notifications and Filter Architecture".  That might be a 
reasonable place to put this sort of discussion.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2KGRjti097260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Mar 2008 09:27:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2KGRjRw097259; Thu, 20 Mar 2008 09:27:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2KGRiY0097252 for <[e-mail]>; Thu, 20 Mar 2008 09:27:45 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 4ABF928C3A3; Thu, 20 Mar 2008 09:30:01 -0700 (PDT)
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-body-09.txt 
Message-Id: <[e-mail]>
Date: Thu, 20 Mar 2008 09:30:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Email Filtering: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-09.txt
	Pages		: 13
	Date		: 2008-3-20
	
This document defines a new command for the "Sieve" email
   filtering language that tests for the occurrence of one or more
   strings in the body of an email message.

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

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2K6EE9N024743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2008 23:14:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2K6EEOt024742; Wed, 19 Mar 2008 23:14:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2K6EDDR024736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 19 Mar 2008 23:14:14 -0700 (MST) (envelope-from [e-mail])
Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m2K6FkNK018689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Mar 2008 23:15:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1205993746; bh=yaFM3lMVNjtwddruvo1SghOpYpEINckXVf4B K6c2VaI=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:Message-ID:User-Agent:MIME-Version:Content-Type: X-MM-Ex-RefId; b=UeXTwkIRcppjpxIWkWz+leY0be4sxee99Gigw+Z8MZaL3MIv/ KpkZFFq855B/X3Vzd6EAkRJw8dvPQJZzhhmg3RrFtFR/4VQoUnDv2bRVQoLwoSst3RY 4fKi4u8BnZGoBX15ZWBZBH4fPZtbroR0C8v7B5wKr1lUTI8B7SHvNHo=
Received: from [192.168.0.2] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id m2K6DuOe027730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2008 23:14:10 -0700
X-DKIM: Sendmail DKIM Filter v2.2.2 fife.sendmail.com m2K6DuOe027730
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1205993654; bh=yaFM3lMVNjtwddruvo1SghOpYpEINckXVf4BK 6c2VaI=; h=Date:From:X-X-Sender:To:cc:Subject:Message-ID:User-Agent: MIME-Version:Content-Type:X-MM-Ex-RefId; b=kY845BABlBWQfGP0O4usmtp +jP7UqS1GXzl1XeJMJaje8nYHT01KRs/RcXngM7qfd1EiSU/WbD9SVMNx5eQ1h1t7Re x+aTwiXfElahBionEyvx66OPiX2H4SS9/2M+sfk+QLrp2MKY7QAhGBnJCRZOxrEOHmQ VQhxEYhac2uem8=
Date: Thu, 20 Mar 2008 00:13:49 -0600
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
cc: Lisa Dusseault <[e-mail]>
Subject: new body draft (-09) submitted
Message-ID: <[e-mail]>
User-Agent: Alpine 1.00 (BSO 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-MM-Ex-RefId: 149371::080319231412-2E538B90-33CCF66F/0-0/0-1
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 just submitted draft-ietf-sieve-body-09.txt with a handful of minor 
tweaks.  Could have done them as notes to the RFC editor, but as long as 
I'm feeling spritely, might as well just roll a new rev...

To quote the changelog in the draft:

11.1 Changes from draft-ietf-sieve-body-08.txt

    Add a "Capability Identifier" section to match existing RFCs.

    Make the normative and information references subsections of a
    "References" section to match existing RFCs.

    Tweak description field of the IANA registration.

    Change "wild card" to "wildcard".


A couple of those were in response to a review done by Christian Vogt back 
in January.  I had misfiled his comments and only found them again after 
the -08 revision was posted.  His major concern was that the 'no body' vs 
'empty body' distinction should not be made; I disagree and pushed back on 
that, citing parallelism with the 'header' and 'address' tests and the 
observation that the distinction can only affect tests that actually match 
the empty body.  While it's unlikely that a real user filter would care 
about this, a filter processing messages that were programmatically 
generated might.  <shurg>


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2JKtvSq059519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2008 13:55:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2JKtvhP059518; Wed, 19 Mar 2008 13:55:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m2JKttkx059512 for <[e-mail]>; Wed, 19 Mar 2008 13:55:56 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 69936 invoked by uid 101); 19 Mar 2008 16:55:55 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 19 Mar 2008 16:55:55 -0400
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Final sanity check on draft-ietf-sieve-mime-loop-04.txt
Message-ID: <[e-mail]>
References: <[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>

Hi,

nitpicking:

3.  Sieve Loops

5th(ish) paragraph contains:

   > If that
   > MIME part is a terminal MIME part (i.e. does not contain other MIME
   > parts) then the nested "for_every_loop" is simply ignored.

I believe this intends to say

   ... the nested "for_every_part" loop is imply ignored.

==========

4.1.  Test "header"

9th paragraph:

   > When used inside the context of a "for_every_part" iterator, and with
   > an ":anychild" tagged argument, the "header" test will examine the
   > current MIME part context and all it's nested MIME body parts,
   > returning true if any of them satisfies the test.

"it's" should be "its" -- picky, picky.

==========

9.2.  Example 2

In the example, the "enclose" action:

   >     enclose :subject "Warning" :text
   > WARNING! The enclosed message contains executable attachments.
   > These attachments types may contain a computer virus program
   > that can infect your computer and potentially damage your data.
   > 
   > Before clicking on these message attachments, you should verify
   > with the sender that this message was sent by them and not a
   > computer virus.
   > .

needs to end with a semicolon.

==========

less nitty:

I was about to go into some stuff about how I thought it would be better
to lay a fundamental foundation of MIME awareness on which this
extension could be layered; about how :mime not only seems superflous
but conflicts with :mime syntax and meaning in other extensions; about
how I'd rather see a generalized parameter extraction for headers that
had a parameter-list syntax (as opposed to :type and so forth).  But
then I realized I said a bunch of that last summer, but apparently
without any sympathy :)  That's the way it goes, but just for reference,
I still am of many of these opinions (and perhaps others ...):

   http://www.imc.org/ietf-mta-filters/mail-archive/msg03658.html

even though I see I fumble-fingered some bit(s) of it.

Yours,
mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2JCurnp007413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2008 05:56:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2JCurh5007412; Wed, 19 Mar 2008 05:56:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.andrew.cmu.edu (smtp.andrew.cmu.edu [128.2.10.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2JCunTa007400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 19 Mar 2008 05:56:51 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.137.23] (cpe-69-207-86-125.buffalo.res.rr.com [69.207.86.125]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.13.8/8.13.8) with ESMTP id m2JCulIh015950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Mar 2008 08:56:47 -0400
Message-ID: <[e-mail]>
Date: Wed, 19 Mar 2008 08:56:02 -0400
From: Ken Murchison <[e-mail]>
Organization: Carnegie Mellon University
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: Proposed charter change
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.60 on 128.2.10.83
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo wrote:

> We would like to see a "show of hands" from implementers on each of the 
> new extensions being proposed so that we can judge the interest in each.

Here's what CMU currently has implemented and what I'm thinking about 
the rest.


>     (a) Body (draft-ietf-sieve-body-07.txt)

Done.  Will update if necessary.

>     (b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)

Need to update to latest notify architecture and then fix mailto.

>     (c) Edit header (draft-ietf-sieve-editheader-10.txt)
>     (d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)

Not sure if we'd do either of these short term.

>     (e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

Will update to whatever is appropriate at the LMTP injection point.

>     (a) Date/Index (draft-freed-sieve-date-index-08.txt)

Will probably give this a good look.

>     (b) iHave (draft-freed-sieve-ihave-01.txt)

Already have a patch floating around.

>     (c) Environment (draft-freed-sieve-environment-03.txt)

Will probably give this a good look.

>     (d) Notary (draft-freed-sieve-notary-01.txt)
>     (e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
>     (f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)

Not sure if we'd do any of these short term.  XML would probably be at 
the top of the list.

>     (g) ManageSIEVE (draft-martin-managesieve-08.txt)

Done.

>     (h) RegEx (draft-ietf-sieve-regex-00.txt)

Done.  Will update accordingly.

>     (j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)

Not at the top of my list.

>     (k) Include/multi-script (draft-daboo-sieve-include-05.txt)

Done.

>     (k) Address data (draft-melnikov-sieve-external-lists-01)

Will have to think about this some more.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2J87GGC067255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2008 01:07:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2J87GaK067254; Wed, 19 Mar 2008 01:07:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2J87F3U067248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 19 Mar 2008 01:07:16 -0700 (MST) (envelope-from [e-mail])
Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m2J88koF014106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Mar 2008 01:08:46 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1205914126; bh=qh7TiqdvmxROS82e7eDAlir+gglLUzAyaNeh 7ZZ1YWc=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:Message-ID:User-Agent:MIME-Version:Content-Type: X-MM-Ex-RefId; b=oy91Nn/+1z5OM5jOhFKwB7dJMMEWV9xGUdSu0kDscqzrzS901 45faUECqP6YrleChndrFhVEa3cVlJbzhGA18pocJvQ8EcdHAigehChKgU8CuZRn6Fjo dZvhQQLqd/bVUSWiiHOMXPoHos1qG0DviEU9n7/0KKqPXvaaF9OYpSU=
Received: from [192.168.0.2] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id m2J82xH1028973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2008 01:08:17 -0700
X-DKIM: Sendmail DKIM Filter v2.2.2 spork.sendmail.com m2J82xH1028973
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1205914099; bh=qh7TiqdvmxROS82e7eDAlir+gglLUzAyaNeh 7ZZ1YWc=; h=Date:From:X-X-Sender:To:cc:Subject:Message-ID: User-Agent:MIME-Version:Content-Type:X-MM-Ex-RefId; b=jmX6Wa5SlJol TK9ntCq4stLG+ETq4f1zgIAVAfk1pgO3n3Ge92p76LfaQj0smPZy04CAKgjiJZyng8a Bm5py4T5hf5LEfkffNTMVuESJJwS4wWC+hhcdC1nsQWNwLdJ6moSoLio2IyaXI5lZqR qHPIUG17RTbVAPpPPq4WznySM=
Date: Wed, 19 Mar 2008 02:01:52 -0600
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Ned Freed <[e-mail]>
cc: [e-mail]
Subject: Comments on draft-freed-sieve-environment-04
Message-ID: <[e-mail]>
User-Agent: Alpine 1.00 (BSO 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-MM-Ex-RefId: 149371::080319010818-0E88FB90-527599E9/0-0/0-1
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>

If the SMTP session was over IPv6, what should the "remote-ip" environment 
item be set to?  Perhaps there should be a prefix on the value that 
indicates the address family, or it should be formatted like the 'host' 
part of URI?

Note that the obvious test of
 	environment :matches "remote-ip" "*.*.*.*"

will match an IPv6 address literal if the implementation uses the
 	x:x:x:x:x:x:d.d.d.d
form, such as with the IPv4 compat addresses, ala "::FFFF:1.2.3.4".

(Yes, this thought was triggered by the "IPv6-only" experiment during the 
IETF technical plenary.)


There probably should be a security consideration that explains that the 
value of the "remote-host" item may be controlled by an untrusted source. 
For example, the test
 	environment :matches "remote-host" "*.mydomain.com"

is *not* a good way to test whether the message came from 'outside' unless 
the implementation there's some sort of IP->host->IP consistency check 
made.


(The sendmail MTA faced the above issues some time ago for the pre-defined 
variables it provides to its rulesets.  To quote the sendmail operations 
guide, it defined variables as follows:
       ${client_addr}
            The  IP  address  of  the  SMTP   client.    IPv6
            addresses  are  tagged  with  "IPv6:"  before the
            address.  Defined in the SMTP server only.

       ${client_name}
            The host name of the SMTP client.   This  may  be
            the  client's  bracketed IP address in the form [
            nnn.nnn.nnn.nnn    ]    for    IPv4     and     [
            IPv6:nnnn:...:nnnn  ] for IPv6 if the client's IP
            address is not resolvable, or if it is resolvable
            but  the  IP  address  of  the  resolved hostname
            doesn't match the original IP  address.   Defined
            in    the    SMTP    server   only.    See   also
            ${client_resolve}.

       ${client_ptr}
            The  result  of  the PTR lookup for the client IP
            address.    Note:   this   is   the    same    as
            ${client_name}  if  and only if ${client_resolve}
            is OK.  Defined in the SMTP server only.

       ${client_resolve}
            Holds  the  result  of  the  resolve   call   for
            ${client_name}.  Possible values are:

                OK        resolved successfully
                FAIL      permanent lookup failure
                FORGED    forward lookup doesn't match reverse lookup
                TEMP      temporary lookup failure

            Defined   in  the  SMTP  server  only.   sendmail
            performs a hostname lookup on the IP  address  of
            the  connecting client.  Next the IP addresses of
            that hostname are looked up.  If  the  client  IP
            address  does  not  appear in that list, then the
            hostname is maybe forged.  This is  reflected  as
            the  value  FORGED  for  ${client_resolve} and it
            also shows up in $_ as "(may be forged)".

While client_ptr and client_resolve are probably overkill for the sieve 
environment extension, the tagging in client_addr and precise definition 
of when client_name contains a name and not an address literal seem like 
practical guidance in this area.)


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2II4u5a083692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 11:04:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2II4uW9083691; Tue, 18 Mar 2008 11:04:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2II4tv3083680 for <[e-mail]>; Tue, 18 Mar 2008 11:04:55 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-scoring_explanation:
X-Spam-Score-spf_status:
X-Spam-Score-Spamcatcher1: c4cada40cab260410670f1f881840ccb
X-Spam-Score-Summary: 2,0,0,d02c0112dcf0853e,a0ea87fb493ec7f7,[e-mail],,RULES_HIT:2:355:379:481:539:540:541:542:543:567:599:601:945:946:968:973:980:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1535:1587:1593:1594:1605:1606:1730:1747:1766:1792:2073:2075:2078:2198:2199:2378:2393:2553:2559:2562:2693:2731:2828:2894:3027:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4117:4250:4425:4605:5007:6261:7522:7576:7903,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
X-Spam-Score-Countries:
X-Spam-Score-Charsets: iso-8859-1
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.205]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 18 Mar 2008 11:04:54 -0700
Message-ID: <024001c88922$91936af0$6501a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "MTA filtering mailing list" <[e-mail]>
References: <[e-mail]>
Subject: Re: Final sanity check on draft-ietf-sieve-mime-loop-04.txt
Date: Tue, 18 Mar 2008 18:04:52 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1914
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914
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 like to ask all people who commented on the document earlier to
>    review if their comments were addressed. If there are no comments on
the
>    document before March 21st, I would recommend its publication.

4.1. Test "header"
-   The "header" test is extended with the addition of a new ":mime"
-   tagged argument and its associated options.
+   The "header" test is extended with the addition of new ":mime"
+   and ":anychild" tagged arguments and their associated options.

I guess this doesn't have to be the case, but I think it would make sense to
use header :anychild without a :mime argument in order to test header of
attached rfc2822 messages, or indeed to test the Content-Type headers of
child body parts as unparsed strings.  It seems clear if you use :anychild,
then you are asking for the mime structure to be evaluated.  I think this is
actually implied anyway when it goes on to say:

   When used inside the context of a "for_every_part" iterator, and with
   an ":anychild" tagged argument, the "header" test will examine the
   current MIME part context and all it's nested MIME body parts,
   returning true if any of them satisfies the test.


   :param  parses the header looking for MIME parameters in the header.
      The supplied string-list lists the names of any parameters to be
-      tested.  If any one named parameter value matches the test string
-      value, the test will return true.
+      tested.  If any one named parameter value matches any of the test
+      string values, the test will return true.

4.2. Test "address"

-   The "address" test is extended with the addition of a new ":mime"
-   tagged argument, which takes a number of other arguments.
+   The "address" test is extended with the addition of new ":mime"
+   and ":anychild" tagged arguments and their associated options.

4.3. Test "exists"

-   The "exists" test is extended with the addition of a new ":mime"
-   tagged argument, which takes one other argument.
+   The "exists" test is extended with the addition of new ":mime"
+   and ":anychild" tagged arguments.

5. Action Replace

Should we also preserve some trace fields?  I'd have thought typically
replace would be used to remove malicious content, in which case would it
not be helpful to at least have some way of knowing where the message came
from that produced the butchered message?  I'd suggest:

-  If the entire message is being replaced, a ":subject" parameter
+  If the entire message is being replaced, the optional ":subject"
parameter
   specifies a subject line to attach to the message that is generated.
   UTF-8 characters can be used in the string argument; implementations
   MUST convert the string to [RFC2047] encoded words if and only if
   non-ASCII characters are present.  Implementations MUST preserve the
   previous Subject header as an Original-Subject header.

   If the entire message is being replaced, a ":from" parameter may be
   used to specify an alternate address to use in the From field of the
   message that is generated.  The string must specify a valid [RFC2822]
   mailbox-list.  Implementations SHOULD check the syntax and generate
   an error when a syntactically invalid ":from" parameter is specified.
   Implementations MAY also impose restrictions on what addresses can be
   specified in a ":from" parameter; it is suggested that values that
   fail such a validity check simply be ignored rather than causing the
   replace action to fail.  Implementations MUST preserve the previous
   From header as an Original-From header.

+  Implementations MUST preserve all other header fields from the original
+  message with the exception of those relating to the MIME structure which
+  will need to be replaced.

Although I do note that the security section does at least indicate that
replace creates an entirely new message, so I'm sorry if we covered this
before and I just forgot.

6. Action Enclose
   If multiple "enclose" actions are executed by a script, only the text
-  specified on the last one is used when creating the enclosed message.
+  specified on the last one is used when creating the enclosed message,
+  the message in this case would not be enclosed multiple times.
   This action does not affect messages that are forwarded via a
-  "redirect" action.
+  "redirect" action, rather the unenclosed message would be what was
+  redirected.

   Specifically, the original message becomes a multipart/mixed message
   with two parts: a text/plain portion with the string argument as its
   body, and a message/rfc822 portion with the original message
   enclosed.  The Content-Type: header field becomes multipart/mixed.
-  The Subject: header is specified by the :subject argument.  Any
+  The optional Subject: header is specified by the :subject argument,
+  if not present the subject will be taken from the enclosed message.  Any
   headers specified by :headers are copied from the old message into
   the new message.  If not specified by :headers, Date: and From:
   headers should be synthesized to reflect the current date and the
   user running the Sieve action.

7. Action extract_text
   If extract_text is used outside the context of a "for_every_part"
   loop, the action will set the variable identified by varname to the
   empty string.

I suggest the above SHOULD be a compilation error, otherwise it should
return the empty string.

Cheers

Nigel




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHvkoh082334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Mar 2008 10:57:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2IHvk9F082333; Tue, 18 Mar 2008 10:57:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2IHvjqD082320 for <[e-mail]>; Tue, 18 Mar 2008 10:57:45 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 2490B28C631; Tue, 18 Mar 2008 11:00:01 -0700 (PDT)
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-mailto-07.txt 
Message-Id: <[e-mail]>
Date: Tue, 18 Mar 2008 11:00:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : Sieve Notification Mechanism: mailto
	Author(s)       : B. Leiba, M. Haardt
	Filename        : draft-ietf-sieve-notify-mailto-07.txt
	Pages           : 16
	Date            : 2008-03-18

This document describes a profile of the Sieve extension for
notifications, to allow notifications to be sent by electronic mail.

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

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HLkuMS038832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Mar 2008 14:46:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2HLkuO3038831; Mon, 17 Mar 2008 14:46:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2HLktdr038824 for <[e-mail]>; Mon, 17 Mar 2008 14:46:55 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id 0CE7A3A6E8A; Mon, 17 Mar 2008 14:49:10 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-sieve-notify-mailto (Sieve Notification  Mechanism: mailto) to Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Mon, 17 Mar 2008 14:49:11 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

- 'Sieve Notification Mechanism: mailto '
   <draft-ietf-sieve-notify-mailto-06.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 substantive comments to the
[e-mail] mailing lists by 2008-03-31. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-06.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14096&rfc_flag=0



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FNFb8M018363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Mar 2008 16:15:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2FNFb4Z018362; Sat, 15 Mar 2008 16:15:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FNFZgb018354 for <[e-mail]>; Sat, 15 Mar 2008 16:15:36 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.17.12] (72-255-64-2.client.stsn.net [72.255.64.2])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 15 Mar 2008 23:15:34 +0000
Message-ID: <[e-mail]>
Date: Sat, 15 Mar 2008 23:15:28 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: [Fwd: Last Call: draft-freed-sieve-environment (Sieve Email Filtering: Environment Extension) to Proposed Standard]
Content-Type: multipart/mixed; boundary="------------030809090809050108060304"
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>

--------------030809090809050108060304
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

FYI.


--------------030809090809050108060304
Content-Type: message/rfc822;
 name="Last Call: draft-freed-sieve-environment (Sieve Email Filtering: 	EnvironmentExtension) to Proposed Standard"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Last Call: draft-freed-sieve-environment (Sieve Email Filtering: 	EnvironmentExtension) to Proposed Standard"

Return-Path: <[e-mail]>
Received: from rufus.isode.com ([62.3.217.251])
	by canine.isode.net (Isode M-Box/14.2v0) with LMTP; Fri, 14 Mar 2008 13:51:58 +0000 (GMT)
Received: from mail.ietf.org ([64.170.98.32]) by rufus.isode.com (smtp external)
          via TCP with ESMTP id <R9qC=[e-mail]> for <[e-mail]>;
          Fri, 14 Mar 2008 13:51:58 +0000
X-SPF-Result: PASS rufus.isode.com: domain of ietf.org designates 64.170.98.32 as permitted sender
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 8C6EF28C953;
	Fri, 14 Mar 2008 06:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id rYMyAaXlQEXX; Fri, 14 Mar 2008 06:53:02 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E47D428C948;
	Fri, 14 Mar 2008 06:52:56 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 30)
	id ECC1628C8BB; Fri, 14 Mar 2008 06:52:54 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <[e-mail]> 
From: The IESG <[e-mail]>
Subject: Last Call: draft-freed-sieve-environment (Sieve Email Filtering: 
	Environment Extension) to Proposed Standard 
Message-Id: <[e-mail]>
Date: Fri, 14 Mar 2008 06:52:54 -0700 (PDT)
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: IETF Announcements <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
	<mailto:[e-mail]?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

The IESG has received a request from an individual submitter to consider 
the following document:

- 'Sieve Email Filtering: Environment Extension '
   <draft-freed-sieve-environment-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 substantive comments to the
[e-mail] mailing lists by 2008-04-11. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

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


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15895&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce

--------------030809090809050108060304--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FLnbDM006535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Mar 2008 14:49:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2FLnbfl006534; Sat, 15 Mar 2008 14:49:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FLnaJM006528 for <[e-mail]>; Sat, 15 Mar 2008 14:49:37 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 15 Mar 2008 14:49:33 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 15 Mar 2008 14:49:31 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, Philip Guenther <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Sat, 15 Mar 2008 14:46:01 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Updated Sieve environment draft posted
In-reply-to: "Your message dated Sat, 15 Mar 2008 17:42:30 -0400" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Philip Guenther <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1205617773; h=Date:	 From:Subject:MIME-version:Content-type; b=UXF1TRNsZOy6nna3aCIdc2/Ai pmoNYTAGPjNli2E/OyMRY0nakr7FLQfCsSOkNnYRIcIQ1xZ55yHoKA+ol3fTg==
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, 14 Mar 2008, Ned Freed wrote:
> ...
> >> > First of all, the specification says that any test against an unknown
> >> > item must fail unconditionally. This provides a simple way to check and
> >> > see if a given item is available:
> >> >
> >> >   if environment :matches "item" {...}
> >
> >> There's a pattern missing there.
> >
> > Right, sorry about that.
> >
> >> Regardless, the empty substring test is
> >> probably more efficient:
> >>  	if environment :contains "item" "" { ... }
> >
> > This almost always works, but not in the case where the environment
> > item has the null string as a possible return value.

> Ummm, what?  Are you saying that there exists some case where
>  	if environment :matches "item" "*" { ... }
> and
>  	if environment :contains "item" "" { ... }

> would return different results?

Sorry, my mistake, I was thinking of :is.

> If that's not what you meant, then I don't understand what you're saying.

> I strongly believe that <<:matches "*">> and <<:contains "">> MUST have
> the same result with *any* combination of test and comparator.

Certainly should be true of all tests and any comparator we've defined so far,
not entirely sure it will extend to all future comparators.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FLgbvc005901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Mar 2008 14:42:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2FLgb3T005900; Sat, 15 Mar 2008 14:42:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FLgYCH005893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 15 Mar 2008 14:42:36 -0700 (MST) (envelope-from [e-mail])
Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m2FLi0t1001349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 15 Mar 2008 14:44:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1205617440; bh=3mbx0L0iP1thsmNLBKK5rPLNahERp8sxM0aV RjY37Qc=; h=Received:Received:Date:From:X-X-Sender:To:cc:Subject: In-Reply-To:Message-ID:References:User-Agent:MIME-Version: Content-Type; b=gEJSHlDy7TIq8Vn2TzBhq4rLAccK0c2A3mybuVqNugqwd123dz jqt2MYM9P3nvwZzK01rdNXokZs3zf2Y5dP8EmrP1ZMxdaxRLIXRz78qEKTHyG09r8/i owdZ5CmkvM+RMkyhRZOOP7WeD9gCBTdSifjF3gqJJVx5FeeCLlFDlQ=
Received: from localhost.localdomain (localhost [127.0.0.1]) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id m2FLha1K030918; Sat, 15 Mar 2008 14:43:36 -0700
Received: from [10.55.44.152] ([75-171-149-156.hlrn.qwest.net [75.171.149.156]]) by spork.sendmail.com with LMTP id m2FLhWi0030906 ; Sat, 15 Mar 2008 14:43:36 -0700
Date: Sat, 15 Mar 2008 17:42:30 -0400
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Ned Freed <[e-mail]>
cc: Philip Guenther <[e-mail]>, [e-mail]
Subject: Re: Updated Sieve environment draft posted
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.00 (BSO 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
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, 14 Mar 2008, Ned Freed wrote:
...
>> > First of all, the specification says that any test against an unknown
>> > item must fail unconditionally. This provides a simple way to check and
>> > see if a given item is available:
>> >
>> >   if environment :matches "item" {...}
>
>> There's a pattern missing there.
>
> Right, sorry about that.
>
>> Regardless, the empty substring test is
>> probably more efficient:
>>  	if environment :contains "item" "" { ... }
>
> This almost always works, but not in the case where the environment
> item has the null string as a possible return value.

Ummm, what?  Are you saying that there exists some case where
 	if environment :matches "item" "*" { ... }
and
 	if environment :contains "item" "" { ... }

would return different results?

If that's not what you meant, then I don't understand what you're saying.

I strongly believe that <<:matches "*">> and <<:contains "">> MUST have 
the same result with *any* combination of test and comparator.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FLaIGo005612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Mar 2008 14:36:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2FLaIIY005611; Sat, 15 Mar 2008 14:36:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FLaGfI005603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 15 Mar 2008 14:36:17 -0700 (MST) (envelope-from [e-mail])
Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m2FLbgZB032571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 15 Mar 2008 14:37:42 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1205617062; bh=ioCum9qmzWvNg8gjxFgBoxWpPqNY7tvcw+QG sRtBPE4=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type:X-MM-Ex-RefId; b=ZMf7ajlCZz5grjPc9iXOl6p urQ6b8LQlQoTkvVWxwXOzELvyuCsv50j680rHvFYO898djctlrA9zPzB7aVAG91dJHW LpdyvClYv/B1Gp7yVH5Kdg38eO+W76ZNn5vugBixKvW3vG3dS//FeOlFpxAhb+mC2lI ZTKJdtMwEpj/SA=
Received: from [10.55.44.152] (75-171-149-156.hlrn.qwest.net [75.171.149.156]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id m2FLavf9002815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Mar 2008 14:37:10 -0700
X-DKIM: Sendmail DKIM Filter v2.2.2 fife.sendmail.com m2FLavf9002815
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1205617032; bh=ioCum9qmzWvNg8gjxFgBoxWpPqNY7tvcw+QGs RtBPE4=; h=Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:User-Agent:MIME-Version:Content-Type: X-MM-Ex-RefId; b=3lDxoVlybyHhBHhHy9INOOVVM1exSmAS+1fS35iw20sEMZJAs obEb67LoxNVE8ETQKpinIPkv6jGQkmczOvoCNA0NK6wbJY7swOlUj4HNQ7ZIjiYHLe7 2IXJn4dO+BjQVV/zTrnA3Sq49+lpy9bFFeq9X352HyLLpqqvxfz7Eiw=
Date: Sat, 15 Mar 2008 17:36:00 -0400
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: "Mark E. Mallett" <[e-mail]>
cc: IETF mta-filters list <[e-mail]>
Subject: Re: Updated Sieve environment draft posted
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.00 (BSO 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-MM-Ex-RefId: 149371::080315143711-5B8EFB90-5B315719/0-0/0-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, 15 Mar 2008, Mark E. Mallett wrote:
> Except that I made no suggestion that they be tied, and I even said that
> I liked the fact that the test(*) doesn't depend on variables.  What I
> opined was that the draft could state what the behavior would be in the
> presence of the variables extension

One barrier to implementing sieve extensions is exactly that the 
intersection of two extensions may require special handling.  While this 
is true by necessity for match-types and comparators, we should fight the 
tendency to add special cases for other combinations that aren't 
completely necessary.


> -- analogous to how it already
> states what the behavior is in the presence of the relational extension.
> Not that it require variables.

This particular special case seems unnecessary to me.  It appears to have 
been inherited or based on the similar exception for the 'envelope' test. 
IMHO, that behavior should not be propagated to 'environment'.  If you 
want to test whether an environment item returns the empty string, then 
just do exactly that!
 	if environment :is "foo" ""

My opinion is that the correct model for relational's :count is that it 
tests against "the number of distinct entities that would otherwise be 
matched against".  I.e., it's the number of different strings that could 
have been matched by <<:matches "*">>.  The count will be zero iff there 
were no entities to match against.

For environment, that would mean that the count will be zero if the item 
does not exist.  The current draft's exceptional handling of empty strings 
is a wart that does not increase the expressiveness of the test and should 
be removed.

(Stepping further up the abstraction ladder: a test command defines how to 
generate a set of zero or more strings.  The comparator and match-type 
arguments then define how that set of strings is matched against the keys. 
The :count match-type says "take the decimal representation of the 
cardinality of the set of match strings, collate (order) that against each 
key using the indicated comparator and return true if they collate in the 
direction indicated by the relational-match argument."  When we define new 
test commands, we should *ONLY* be specifying how it generates a set of 
strings to match against.)


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FIGWmg082421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Mar 2008 11:16:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2FIGWuY082420; Sat, 15 Mar 2008 11:16:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m2FIGUBU082405 for <[e-mail]>; Sat, 15 Mar 2008 11:16:31 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 37611 invoked by uid 101); 15 Mar 2008 14:16:30 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Sat, 15 Mar 2008 14:16:30 -0400
To: IETF mta-filters list <[e-mail]>
Subject: Re: Updated Sieve environment draft posted
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.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 Fri, Mar 14, 2008 at 09:37:12PM +0000, Alexey Melnikov wrote:
> I am planning to implement both environment and variables at some point. 
> But environment as written is just a couple of hours of work, while 
> variables is more like a couple of weeks of work. So I would rather not 
> tie environment to variables.

Except that I made no suggestion that they be tied, and I even said that
I liked the fact that the test(*) doesn't depend on variables.  What I
opined was that the draft could state what the behavior would be in the
presence of the variables extension -- analogous to how it already
states what the behavior is in the presence of the relational extension.
Not that it require variables.

I hadn't intended to follow up again, not having anything new to add,
but since two people commented on a perceived requirement to implement
variables according to my remarks, I figured I would.  To me, specifying
a variables namespace here adds utility and symmetry, which appeals to
me (although that's not always a complete justification for anything, I
fall on that side here), and won't require any later extension to do it,
which also appeals to me.  At any rate it's not a huge deal.

mm

(*)tho I did say "verb" - it's a bad habit of mine, like nailbiting.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FD9XTl043733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Mar 2008 06:09:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2FD9XQ4043732; Sat, 15 Mar 2008 06:09:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2FD9Vb8043724 for <[e-mail]>; Sat, 15 Mar 2008 06:09:32 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.17.12] (dhcp-110c.ietf71.ietf.org [130.129.17.12])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R9vKiQBh6Jp=@rufus.isode.com>; Sat, 15 Mar 2008 13:09:30 +0000
Message-ID: <[e-mail]>
Date: Fri, 14 Mar 2008 21:37:12 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: Mark E Mallett <[e-mail]>, [e-mail]
Subject: Re: Updated Sieve environment draft posted
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>>as it doesn't require variables, but also having the information
>>available via a variable namespace seems clean to me too since it builds
>>on language elements and concepts already out there.  But I can see some
>>of the drawbacks too: one being that it would make implementation of
>>this extension slightly harder/slower/less likely for any product that
>>also implements "variables" if this extension mandated adding a
>>variables namespace.  But only slightly.    
>>
>That's my main concern here - I want to keep this simple. I think the main
>use-case for environment is as a test.
>  
>
Agreed.
I am planning to implement both environment and variables at some point. 
But environment as written is just a couple of hours of work, while 
variables is more like a couple of weeks of work. So I would rather not 
tie environment to variables.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EDcY8S091396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 06:38:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EDcY1I091395; Fri, 14 Mar 2008 06:38:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EDcSwj091385 for <[e-mail]>; Fri, 14 Mar 2008 06:38:31 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 14 Mar 2008 06:38:19 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 14 Mar 2008 06:38:15 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Fri, 14 Mar 2008 06:34:46 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Updated Sieve environment draft posted
In-reply-to: "Your message dated Thu, 13 Mar 2008 22:18:43 -0400" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Philip Guenther <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1205501899; h=Date:	 From:Subject:MIME-version:Content-type; b=PCpTbV3Pldpf1Jqz5tWfD4g8d 6/wKi/25VKTKT+iOyTTob8GqivNU7E5AqohiWRywFbBFow0R4WO47sbc16eBw==
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, 13 Mar 2008, Ned Freed wrote:
> ...
> >> There is a "host" item listed, which is the FQDN of the local host. It
> >> seems to me that one might want to know the host-only part of that
> >> string.  One could obtain it in a round-about way by using the "domain"
> >> environment item and the "host" item; but is it worth adding
> >> "host-only" ?
> >
> > Frankly, I think the use of shortform names is a bad thing that should
> > be discouraged whenever possible. (IT uses them extensively here at Sun
> > and they cause no end of problems.) I'm therefore very reluctant to add
> > such an item.

> I agree.  Unqualified hostnames should never appear in protocols and,
> IMHO, are only useful in space-constrained interactive environments, where
> the user can obtain the full form if they have any doubt.

> ...
> > First of all, the specification says that any test against an unknown
> > item must fail unconditionally. This provides a simple way to check and
> > see if a given item is available:
> >
> >   if environment :matches "item" {...}

> There's a pattern missing there.

Right, sorry about that.

> Regardless, the empty substring test is
> probably more efficient:
>  	if environment :contains "item" "" { ... }

This almost always works, but not in the case where the environment
item has the null string as a possible return value. Of course in every
case I can think of a null value is going to signify "information not
available", and I cannot think of a use-case where a script would want
to act differently given "item not supported' versus "information not 
available".

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EBR697078164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 04:27:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EBR6qT078163; Fri, 14 Mar 2008 04:27:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout4.freenet.de (mout4.freenet.de [IPv6:2001:748:100:40::2:6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EBR3XC078153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 14 Mar 2008 04:27:05 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.19] (helo=9.mx.freenet.de) by mout4.freenet.de with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1Ja83y-0004db-9x for [e-mail]; Fri, 14 Mar 2008 12:27:02 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:52329) by 9.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1Ja83y-0004jj-8H for [e-mail]; Fri, 14 Mar 2008 12:27:02 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #13) id 1Ja83x-000215-7r for [e-mail]; Fri, 14 Mar 2008 12:27:01 +0100
Date: Fri, 14 Mar 2008 12:27:01 +0100
To: [e-mail]
Subject: Re: Proposed charter change
References: <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[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>

> 	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)

Implemented, following drafts closely.

> 	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

I would love to implement that, but I am afraid it requires substantial
design changes in Exim, which has always accepted the mail at the time
a filter runs.  It is very unlikely anybody implements that in Exim 4,
but that's a problem with Exim, not with the draft.

> 	(a) Body (draft-ietf-sieve-body-07.txt)
> 	(c) Edit header (draft-ietf-sieve-editheader-10.txt)
> 	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
>
> (2) Finalize and publish the following SIEVE extensions as proposed 
> standards:
>
> 	(a) Date/Index (draft-freed-sieve-date-index-08.txt)
> 	(b) iHave (draft-freed-sieve-ihave-01.txt)
> 	(c) Environment (draft-freed-sieve-environment-03.txt)
> 	(d) Notary (draft-freed-sieve-notary-01.txt)
> 	(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
> 	(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
> 	(g) ManageSIEVE (draft-martin-managesieve-08.txt)
> 	(h) RegEx (draft-ietf-sieve-regex-00.txt)
> 	(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
> 	(k) Include/multi-script (draft-daboo-sieve-include-05.txt)
> 	(k) Address data (draft-melnikov-sieve-external-lists-01)

None of these are implemented or and I don't plan to implement any
on my own.  We only require a minimal Sieve implementation.  SIP and
XMPP notification methods might become interesting, though, but not at
this time.

Michael



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EAG0fU070114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 03:16:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EAG0N0070113; Fri, 14 Mar 2008 03:16:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EAFxN4070106 for <[e-mail]>; Fri, 14 Mar 2008 03:15:59 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id B1B524AC80 for <[e-mail]>; Fri, 14 Mar 2008 11:15:58 +0100 (CET)
Received: from 195.30.37.9 (HELO libertango.oryx.com) by kalyani.oryx.com with esmtp id 1205489758-87171-1220; Fri, 14 Mar 2008 11:15:58 +0100
Message-Id: <[e-mail]>
Date: Fri, 14 Mar 2008 11:15:58 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Updated Sieve environment draft posted
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed writes:
>> as it doesn't require variables, but also having the information 
>> available via a variable namespace seems clean to me too since it 
>> builds on language elements and concepts already out there. But I 
>> can see some of the drawbacks too: one being that it would make 
>> implementation of this extension slightly harder/slower/less likely 
>> for any product that also implements "variables" if this extension 
>> mandated adding a variables namespace. But only slightly.
>
> That's my main concern here - I want to keep this simple. I think the 
> main use-case for environment is as a test.

Yes. I like the simplicity and brevity of the document, and I like that 
it doesn't depend on variables.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EA09e0067294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Mar 2008 03:00:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2EA09sN067293; Fri, 14 Mar 2008 03:00:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2EA03kQ067277 for <[e-mail]>; Fri, 14 Mar 2008 03:00:08 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id D1DB74AC80 for <[e-mail]>; Fri, 14 Mar 2008 11:00:01 +0100 (CET)
Received: from 195.30.37.9 (HELO libertango.oryx.com) by kalyani.oryx.com with esmtp id 1205488801-87171-1212; Fri, 14 Mar 2008 11:00:01 +0100
Message-Id: <[e-mail]>
Date: Fri, 14 Mar 2008 11:00:00 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Proposed charter change
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus Daboo writes:
> We would like to see a "show of hands" from implementers on each of=20
> the new extensions being proposed so that we can judge the interest=20
> in each.

OK. Other comments also below.

> Note that we will need document authors/editors to step up for items=20
> (3) and (4) if we are to include these.

I already have done some work on 4...

> The SIEVE email filtering language is specified in RFC 5228, together=20
> with a number of extensions.
>
> The SIEVE working group is being re-chartered to:
>
> (1) Finish work on existing in-progress Working Group documents:
>
>        (a) Body (draft-ietf-sieve-body-07.txt)

Have.

>        (b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)

Unlikely. (We'll do notify and some of its children, but I don't feel=20
good about notifying about email messages using other email messages,=20
so mailto isn't an implementation candidate yet.)

>        (c) Edit header (draft-ietf-sieve-editheader-10.txt)

Very likely.

>        (d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)

Will do.

>        (e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

Have older version, will update. (Have updated? I'd have to check.)

> (2) Finalize and publish the following SIEVE extensions as proposed=20
> standards:
>
>        (a) Date/Index (draft-freed-sieve-date-index-08.txt)

Have.

>        (b) iHave (draft-freed-sieve-ihave-01.txt)

Likely.

>        (c) Environment (draft-freed-sieve-environment-03.txt)

Very likely.

>        (d) Notary (draft-freed-sieve-notary-01.txt)

Very likely.

>        (e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)

Yes or no. We'll do Sieve in XML, but I don't know whether we'll do it=20
that way. I don't see any reason to do it differently, but if one=20
appears...

>        (f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)

Likely.

>        (g) ManageSIEVE (draft-martin-managesieve-08.txt)

Have.

>        (h) RegEx (draft-ietf-sieve-regex-00.txt)

Unlikely.

>        (j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)

Don't know.

>        (k) Include/multi-script (draft-daboo-sieve-include-05.txt)

Include is uncertain. (Our code is developing along the lines of Jutta's=20
expired multiscript document, though, so who knows.)

>        (k) Address data (draft-melnikov-sieve-external-lists-01)

Uncertain... more likely no than yes.

> Additional drafts may be added to this list, but only via a charter
> revision. There must also be demonstrable willingness in the SIEVE
> development community to actually implement a given extension before
> it can be added to this charter.

FWIW, we'll do one other extension, but I think I'll talk more about=20
that only when we have code.

> (3) Work on a "Benefits of SIEVE" guide for client and server vendors =
that:
>        (a) Describes the SIEVE protocol and its suite of extensions.
>        (b) Explains the benefits of server-side filtering in practical =
terms.
>        (c) Shows how client-side filtering can be migrated to SIEVE.

Laudable, I'm sure, but my only comment is that I know little about a=20
little and almost nothing about the rest.

> (4) Produce one or more informational RFCs containing a set of test=20
> scripts and test email messages that are to be filtered by the=20
> scripts, and the expected results of that filtering. This will serve=20
> as the basis of a interoperability test suite to help determine the=20
> suitability of moving the base specification and selected extensions=20
> to Draft status.

I did some work on that last summer, which I sent to Barry (and Alexey?=20
don't remember any more). I'd be willing to continue that on my own.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2E4FVXa028607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 21:15:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2E4FVx6028606; Thu, 13 Mar 2008 21:15:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2E4FSOR028595 for <[e-mail]>; Thu, 13 Mar 2008 21:15:31 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 13 Mar 2008 21:15:26 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 13 Mar 2008 21:15:23 -0700 (PDT)
Cc: Ned Freed <[e-mail]>, Mark E Mallett <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Thu, 13 Mar 2008 21:03:37 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Updated Sieve environment draft posted
In-reply-to: "Your message dated Thu, 13 Mar 2008 20:47:01 -0400" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Mark E Mallett <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1205468126; h=Date:	 From:Subject:MIME-version:Content-type; b=dgTBLtQyDmsO/naB3l2Bt2da6 1+gdBBS3tiZvm1KigmFVbzQsLrNnkkpyrzcOxL1nLi90u+HAV93wJzyewad3g==
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, Mar 13, 2008 at 04:30:09PM -0700, Ned Freed wrote:
> >
> > > I also think that the draft could benefit by providing for some behavior
> > > in the presence of the "variables" extension, e.g. by defining a
> > > namespace such as "env." and stating what value is returned if the item
> > > is undefined in the implementation.  I realize that one could obtain the
> > > values by using :matches, wildcarding, and variable assignments;
> > > having namespace support would be more straightforward.
> >
> > First of all, the specification says that any test against an unknown
> > item must fail unconditionally. This provides a simple way to check and
> > see if a given item is available:
> >
> >    if environment :matches "item" {...}
> >
> > This test only succeeds if "item" is defined. Since this doesn't appear
> > to be obvious I think I'll add a note about it to the text.

> Actually I think it is pretty obvious, I don't think that needs to be
> clarified.  What I was saying is that while you can indeed use
> ":matches" to get the value into a variable:

>     if environment :matches "domain" "*" { set "domain" "${0}"; }

> using a variable namespace would be more straightforward, and much more
> efficient.  e.g.:

>     set "domain" "${env.domain}";

> and that basically it would be good to have that specified here than not
> to have it at all, or than having it done separately with yet another
> capability.

It's a bit more elegant but I'm just not convinced it is worth it.

> I may be missing the point of your reply.  It occurs to me that you are
> replying to my phrase "stating what value is returned if the item is
> undefined in the implementation" -- but that is in a sentence that is
> about a possible "variables" namespace, not the "environment" verb.

Right.

>  In
> evaluating a variables namespace reference to a non-existent or
> unsupported item, say "${env.remote-host}" when remote-host isn't
> meaningful, or "${env.foobar}" when foobar isn't a real item, the
> hypothetical text that addresses the variables namespace would have to
> describe what value is returned in those situations.  As you say, the
> behavior of the "environment" action is pretty clear already.
    
Yes, that's an issue with the namespace approach.

> > I did consider using namespaces as a means of returning multiple/structured
> > values from environment tests, but I eventually decided it wasn't worth it.

> Different perspectives, I guess.  I like having the "environment" verb,

I think you mean test, not verb.

> as it doesn't require variables, but also having the information
> available via a variable namespace seems clean to me too since it builds
> on language elements and concepts already out there.  But I can see some
> of the drawbacks too: one being that it would make implementation of
> this extension slightly harder/slower/less likely for any product that
> also implements "variables" if this extension mandated adding a
> variables namespace.  But only slightly.

That's my main concern here - I want to keep this simple. I think the main
use-case for environment is as a test.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2E2JG2C017901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 19:19:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2E2JGCJ017900; Thu, 13 Mar 2008 19:19:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2E2JEvp017886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 13 Mar 2008 19:19:16 -0700 (MST) (envelope-from [e-mail])
Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m2E2KaA2031783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Mar 2008 19:20:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1205461237; bh=BQ0C8osr+6KEioZAhLJ/587StK8qhu8rmsAX 0SGj98Q=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type:X-MM-Ex-RefId; b=ZbaMGUJQqSXgLScdbKaTGnV xN7D2xoab+IVWLi0dc7DVOpRud/myiNhqek7X76NYd/W/gklkIcpbnXW8rbxgSsbheL npyCyg1j78ZUY8ArvFfxiID8o5YV2Xmok2SXdVecYxxtq1YbcT583HfJp60GaDhNhQz bhwKiBRwcSBpQc=
Received: from [10.150.133.112] (72-255-87-32.client.stsn.net [72.255.87.32]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id m2E2Jqpj026906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 19:20:10 -0700
X-DKIM: Sendmail DKIM Filter v2.2.2 spork.sendmail.com m2E2Jqpj026906
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1205461213; bh=BQ0C8osr+6KEioZAhLJ/587StK8qhu8rmsAX 0SGj98Q=; h=Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:User-Agent:MIME-Version:Content-Type: X-MM-Ex-RefId; b=NjPKtWS8/A6czAoLb6t3wlBdo7Dyg/8xLPgG5gNHKReMA1ZB4 K4i642OPxZHEb4r22q9XK09vRhhHRFnCQj2vx7KjhLxRztUIbY+E/PvgrJgzLSsCJYp o5hQbMK/bJFgoKyv7KbSFQzeyG8ipzExNdMQWjMv98JVGF2PJRkR3eY=
Date: Thu, 13 Mar 2008 22:18:43 -0400
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: Ned Freed <[e-mail]>
cc: [e-mail]
Subject: Re: Updated Sieve environment draft posted
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.00 (BSO 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-MM-Ex-RefId: 149371::080313192012-0E887B90-56DFE926/0-0/0-1
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, 13 Mar 2008, Ned Freed wrote:
...
>> There is a "host" item listed, which is the FQDN of the local host. It 
>> seems to me that one might want to know the host-only part of that 
>> string.  One could obtain it in a round-about way by using the "domain" 
>> environment item and the "host" item; but is it worth adding 
>> "host-only" ?
>
> Frankly, I think the use of shortform names is a bad thing that should 
> be discouraged whenever possible. (IT uses them extensively here at Sun 
> and they cause no end of problems.) I'm therefore very reluctant to add 
> such an item.

I agree.  Unqualified hostnames should never appear in protocols and, 
IMHO, are only useful in space-constrained interactive environments, where 
the user can obtain the full form if they have any doubt.

...
> First of all, the specification says that any test against an unknown
> item must fail unconditionally. This provides a simple way to check and
> see if a given item is available:
>
>   if environment :matches "item" {...}

There's a pattern missing there.  Regardless, the empty substring test is 
probably more efficient:
 	if environment :contains "item" "" { ... }


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2E0l3qH009311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 17:47:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2E0l3IL009310; Thu, 13 Mar 2008 17:47:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m2E0l1sV009302 for <[e-mail]>; Thu, 13 Mar 2008 17:47:02 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 84657 invoked by uid 101); 13 Mar 2008 20:47:01 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 13 Mar 2008 20:47:01 -0400
To: Ned Freed <[e-mail]>
Cc: Mark E Mallett <[e-mail]>, [e-mail]
Subject: Re: Updated Sieve environment draft posted
Message-ID: <[e-mail]>
References: <[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 Thu, Mar 13, 2008 at 04:30:09PM -0700, Ned Freed wrote:
> 
> > I also think that the draft could benefit by providing for some behavior
> > in the presence of the "variables" extension, e.g. by defining a
> > namespace such as "env." and stating what value is returned if the item
> > is undefined in the implementation.  I realize that one could obtain the
> > values by using :matches, wildcarding, and variable assignments;
> > having namespace support would be more straightforward.
> 
> First of all, the specification says that any test against an unknown
> item must fail unconditionally. This provides a simple way to check and
> see if a given item is available:
> 
>    if environment :matches "item" {...}
> 
> This test only succeeds if "item" is defined. Since this doesn't appear
> to be obvious I think I'll add a note about it to the text.

Actually I think it is pretty obvious, I don't think that needs to be
clarified.  What I was saying is that while you can indeed use
":matches" to get the value into a variable:

    if environment :matches "domain" "*" { set "domain" "${0}"; }

using a variable namespace would be more straightforward, and much more
efficient.  e.g.:

    set "domain" "${env.domain}";

and that basically it would be good to have that specified here than not
to have it at all, or than having it done separately with yet another
capability.

I may be missing the point of your reply.  It occurs to me that you are
replying to my phrase "stating what value is returned if the item is
undefined in the implementation" -- but that is in a sentence that is
about a possible "variables" namespace, not the "environment" verb.  In
evaluating a variables namespace reference to a non-existent or
unsupported item, say "${env.remote-host}" when remote-host isn't
meaningful, or "${env.foobar}" when foobar isn't a real item, the
hypothetical text that addresses the variables namespace would have to
describe what value is returned in those situations.  As you say, the
behavior of the "environment" action is pretty clear already.
    

> I did consider using namespaces as a means of returning multiple/structured
> values from environment tests, but I eventually decided it wasn't worth it.

Different perspectives, I guess.  I like having the "environment" verb,
as it doesn't require variables, but also having the information
available via a variable namespace seems clean to me too since it builds
on language elements and concepts already out there.  But I can see some
of the drawbacks too: one being that it would make implementation of
this extension slightly harder/slower/less likely for any product that
also implements "variables" if this extension mandated adding a
variables namespace.  But only slightly.

Yours,
mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DNh9h3002588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 16:43:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DNh9TP002587; Thu, 13 Mar 2008 16:43:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DNh8BG002581 for <[e-mail]>; Thu, 13 Mar 2008 16:43:09 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 13 Mar 2008 16:43:07 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 13 Mar 2008 16:43:05 -0700 (PDT)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Thu, 13 Mar 2008 16:30:09 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Updated Sieve environment draft posted
In-reply-to: "Your message dated Thu, 13 Mar 2008 12:59:07 -0400" <[e-mail]>
References: <[e-mail]> <[e-mail]>
To: Mark E Mallett <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1205451787; h=Date:	 From:Subject:MIME-version:Content-type; b=Qu7EpO33uX55tsMPRf7S2MxUj byOsK6Dyj17Vrz+tCc2w9ZsUlOImCXDK0JxRlVIya5v4zvqfWg37OFH7p4ARQ==
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, Mar 10, 2008 at 04:29:21PM -0700, Ned Freed wrote:
> >
> > I just posted an update to the environment draft; it should be in the
> > repository soon.

> Seems short and sweet.


> > In addition to adding a note about using "name."
> > prefixes to group related standard items,

> That note is actually the only thing that gave me pause.  When I read:

>    > Extensions designed for interoperable use SHOULD be defined in
>    > standards track or experimental RFCs.  Groups of standardized items
>    > MAY choose to use a common name prefix of the form "name.".

> it took me a few passes to realize that this was not recommending the
> literal prefix string "name." (perhaps relating to the "name"
> environment item) but recommending grouping related items by some prefix
> "xxx." where "xxx" is replaced by some mnemonic for the category by
> which they are related.  I dunno if that's even worth mentioning, but
> there it is, mentioned.

Fair enough. When the document is next updated I will add ", where "name" is a
string that identifies the group of related items." to the end of the last
sentence.

> A couple of other musings, again perhaps not worth mentioning, but
> while I'm here:

> There is a "host" item listed, which is the FQDN of the local host.
> It seems to me that one might want to know the host-only part of that
> string.  One could obtain it in a round-about way by using the "domain"
> environment item and the "host" item; but is it worth adding "host-only" ?

Frankly, I think the use of shortform names is a bad thing that should be
discouraged whenever possible. (IT uses them extensively here at Sun and they
cause no end of problems.) I'm therefore very reluctant to add such an item.

> I also think that the draft could benefit by providing for some behavior
> in the presence of the "variables" extension, e.g. by defining a
> namespace such as "env." and stating what value is returned if the item
> is undefined in the implementation.  I realize that one could obtain the
> values by using :matches, wildcarding, and variable assignments;
> having namespace support would be more straightforward.

First of all, the specification says that any test against an unknown
item must fail unconditionally. This provides a simple way to check and
see if a given item is available:

   if environment :matches "item" {...}

This test only succeeds if "item" is defined. Since this doesn't appear
to be obvious I think I'll add a note about it to the text.

I did consider using namespaces as a means of returning multiple/structured
values from environment tests, but I eventually decided it wasn't worth it.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DN9PV4099419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 16:09:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DN9Psk099418; Thu, 13 Mar 2008 16:09:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DN9NRE099412 for <[e-mail]>; Thu, 13 Mar 2008 16:09:24 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.21.224] (dhcp-15e0.ietf71.ietf.org [130.129.21.224])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 13 Mar 2008 23:09:22 +0000
Message-ID: <[e-mail]>
Date: Thu, 13 Mar 2008 23:09:16 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-body-08.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:

>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: Body Extension
>	Author(s)	: P. Guenther, J. Degener
>	Filename	: draft-ietf-sieve-body-08.txt
>	Pages		: 13
>	Date		: 2008-3-13
>	
>This document defines a new command for the "Sieve" email
>   filtering language that tests for the occurrence of one or more
>   strings in the body of an email message.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-08.txt
>  
>
This version addresses comments raised during the IESG review. It also 
contains some other useful clarifications. Please review asap to make 
sure that you are Ok with the changes.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DMvjlf098665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 15:57:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DMvjAx098664; Thu, 13 Mar 2008 15:57:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DMviJJ098650 for <[e-mail]>; Thu, 13 Mar 2008 15:57:45 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 5071228C2AA; Thu, 13 Mar 2008 16:00:00 -0700 (PDT)
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-body-08.txt 
Message-Id: <[e-mail]>
Date: Thu, 13 Mar 2008 16:00:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Email Filtering: Body Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-body-08.txt
	Pages		: 13
	Date		: 2008-3-13
	
This document defines a new command for the "Sieve" email
   filtering language that tests for the occurrence of one or more
   strings in the body of an email message.

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

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DIHHhI073142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 11:17:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DIHHZY073141; Thu, 13 Mar 2008 11:17:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m2DIHGAq073135 for <[e-mail]>; Thu, 13 Mar 2008 11:17:17 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 63299 invoked by uid 101); 13 Mar 2008 14:17:16 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 13 Mar 2008 14:17:16 -0400
To: SIEVE <[e-mail]>
Subject: Re: Proposed charter change
Message-ID: <[e-mail]>
References: <[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 Thu, Mar 13, 2008 at 11:00:30AM -0400, Cyrus Daboo wrote:
> 
> We would like to see a "show of hands" from implementers on each of the new 
> extensions being proposed so that we can judge the interest in each.
  ...

> 	(a) Body (draft-ietf-sieve-body-07.txt)
not yet, might implement some of it.  But enough of it doesn't match my
worldview (or perhaps my code's worldview) that implementing all of it
will be problematic.

> 	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
not yet, probably will

> 	(c) Edit header (draft-ietf-sieve-editheader-10.txt)
have implemented an older draft, need to validate against this one.
Also still have "replaceheader" and probably won't remove it.

> 	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
possibly, but again with the worldview issues (as noted on-list in past)

> 	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)
intend to, at which point I'll find out about any problems I guess.

> 	(a) Date/Index (draft-freed-sieve-date-index-08.txt)
intend to.

> 	(b) iHave (draft-freed-sieve-ihave-01.txt)
will implement, looks very nice.

> 	(c) Environment (draft-freed-sieve-environment-03.txt)
will implement.

> 	(d) Notary (draft-freed-sieve-notary-01.txt)
> 	(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
> 	(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
I confess that I haven't looked at these close enough.

> 	(g) ManageSIEVE (draft-martin-managesieve-08.txt)
is in the queue, but low priority.

> 	(h) RegEx (draft-ietf-sieve-regex-00.txt)
had not seen this one, but have implemented against
draft-murchison-sieve-regex-08.txt .  (I have also implemented the
quoteregex function, but in a different way; I'll probably add this
style as well.)  I think regex draft could benefit with some
enhancements (such as alternate regex expression methods).

hmm, no (i) ?


> 	(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
am unaware of this


> 	(k) Include/multi-script (draft-daboo-sieve-include-05.txt)
I'm not happy with the kind of include this specifies, so probably won't
implement it (and already have other include mechanism).


> 	(k) Address data (draft-melnikov-sieve-external-lists-01)
[oh, that's what happened to (i) :) ]

Will probably implement at least a subset of this - probably limited to
the opaque identifier form, as I'm not too keen on implementing
URL-following.  Unless I'm misreading the intent of that.

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DGx9mL065523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 09:59:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DGx9cc065522; Thu, 13 Mar 2008 09:59:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m2DGx8PV065515 for <[e-mail]>; Thu, 13 Mar 2008 09:59:09 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 35565 invoked by uid 101); 13 Mar 2008 12:59:08 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Thu, 13 Mar 2008 12:59:07 -0400
To: [e-mail]
Subject: Re: Updated Sieve environment draft posted
Message-ID: <[e-mail]>
References: <[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 Mon, Mar 10, 2008 at 04:29:21PM -0700, Ned Freed wrote:
> 
> I just posted an update to the environment draft; it should be in the
> repository soon.

Seems short and sweet.


> In addition to adding a note about using "name."
> prefixes to group related standard items,

That note is actually the only thing that gave me pause.  When I read:

   > Extensions designed for interoperable use SHOULD be defined in
   > standards track or experimental RFCs.  Groups of standardized items
   > MAY choose to use a common name prefix of the form "name.".

it took me a few passes to realize that this was not recommending the
literal prefix string "name." (perhaps relating to the "name"
environment item) but recommending grouping related items by some prefix
"xxx." where "xxx" is replaced by some mnemonic for the category by
which they are related.  I dunno if that's even worth mentioning, but
there it is, mentioned.

A couple of other musings, again perhaps not worth mentioning, but
while I'm here:

There is a "host" item listed, which is the FQDN of the local host.
It seems to me that one might want to know the host-only part of that
string.  One could obtain it in a round-about way by using the "domain"
environment item and the "host" item; but is it worth adding "host-only" ?

I also think that the draft could benefit by providing for some behavior
in the presence of the "variables" extension, e.g. by defining a
namespace such as "env." and stating what value is returned if the item
is undefined in the implementation.  I realize that one could obtain the
values by using :matches, wildcarding, and variable assignments;
having namespace support would be more straightforward.

That's all..

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DGqinq064994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 09:52:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DGqiWb064993; Thu, 13 Mar 2008 09:52:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DGqhE9064987 for <[e-mail]>; Thu, 13 Mar 2008 09:52:44 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.21.224] (dhcp-15e0.ietf71.ietf.org [130.129.21.224])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 13 Mar 2008 16:52:42 +0000
Message-ID: <[e-mail]>
Date: Thu, 13 Mar 2008 16:52:37 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Cyrus Daboo <[e-mail]>
CC: SIEVE <[e-mail]>
Subject: Re: Proposed charter change
References: <[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>

Speaking as an implementor:

Cyrus Daboo wrote:

> (1) Finish work on existing in-progress Working Group documents:
>
>     (a) Body (draft-ietf-sieve-body-07.txt)

Will implement.

>     (b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)

Undecided, but will consider implementing

>     (c) Edit header (draft-ietf-sieve-editheader-10.txt)

Will implement

>     (d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)

Will implement

>     (e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

Older version already implemented.

> (2) Finalize and publish the following SIEVE extensions as proposed 
> standards:
>
>     (a) Date/Index (draft-freed-sieve-date-index-08.txt)

Will implement

>     (b) iHave (draft-freed-sieve-ihave-01.txt)

This looks very interesting, but I haven't even started thinking about 
how difficult this would be to implement.

>     (c) Environment (draft-freed-sieve-environment-03.txt)

Will implement

>     (d) Notary (draft-freed-sieve-notary-01.txt)

Will implement

>     (e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)

This looks interesting, even though there is no immediate plan to implement.

>     (f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)

I haven't thought about implementing this yet.

>     (g) ManageSIEVE (draft-martin-managesieve-08.txt)

Implemented.

>     (h) RegEx (draft-ietf-sieve-regex-00.txt)

I am not sure this will be implemented, no customer requirements so far.

>     (j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)

Will implement.

>     (k) Include/multi-script (draft-daboo-sieve-include-05.txt)

I've started implementing something like multiscript and will be looking 
at include.
So this looks interesting to me.

>     (k) Address data (draft-melnikov-sieve-external-lists-01)

Will implement.

> (4) Produce one or more informational RFCs containing a set of test 
> scripts and test email messages that are to be filtered by the 
> scripts, and the expected results of that filtering. This will serve 
> as the basis of a interoperability test suite to help determine the 
> suitability of moving the base specification and selected extensions 
> to Draft status.

I will definitely participate in this effort, but I can't commit to be 
an editor.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DGGV1p061382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 09:16:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DGGVDM061381; Thu, 13 Mar 2008 09:16:31 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DGGSMm061366 for <[e-mail]>; Thu, 13 Mar 2008 09:16:31 -0700 (MST) (envelope-from [e-mail])
X-Spam-Score-scoring_explanation:
X-Spam-Score-spf_status:
X-Spam-Score-Spamcatcher1: a44ffe7655438abf9e3dd266bc77bfa9
X-Spam-Score-Summary: 2,0,0,e6b35046e0522e35,a0ea87fb493ec7f7,[e-mail],,RULES_HIT:355:379:539:540:541:542:543:567:599:601:966:982:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2196:2199:2393:2538:2559:2562:2828:3027:3352:3865:3868:3869:3870:4250:4385:5007:6119:6261,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:none,DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
X-Spam-Score-Countries:
X-Spam-Score-Charsets: iso-8859-1
X-Spam-Score: 1
Received: from nigel (nigel.rockliffe.com [10.42.44.110]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.4) with ESMTP id <[e-mail]>; Thu, 13 Mar 2008 09:16:27 -0700
Message-ID: <001201c88525$970265a0$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>
Cc: "SIEVE" <[e-mail]>
References: <[e-mail]>
Subject: Re: Proposed charter change
Date: Thu, 13 Mar 2008 16:16:25 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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>

> (1) Finish work on existing in-progress Working Group documents:
> 
> (a) Body (draft-ietf-sieve-body-07.txt)
yes
> (b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
no plan
> (c) Edit header (draft-ietf-sieve-editheader-10.txt)
yes
> (d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
yes
> (e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)
ish

> (2) Finalize and publish the following SIEVE extensions as proposed 
> standards:
> 
> (a) Date/Index (draft-freed-sieve-date-index-08.txt)
no plan
> (b) iHave (draft-freed-sieve-ihave-01.txt)
no plan
> (c) Environment (draft-freed-sieve-environment-03.txt)
no plan
> (d) Notary (draft-freed-sieve-notary-01.txt)
no plan
> (e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
no plan
> (f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
no plan
> (g) ManageSIEVE (draft-martin-managesieve-08.txt)
no plan
> (h) RegEx (draft-ietf-sieve-regex-00.txt)
ish
> (j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
no plan
> (k) Include/multi-script (draft-daboo-sieve-include-05.txt)
no plan
> (k) Address data (draft-melnikov-sieve-external-lists-01)
ish

Cheers

Nigel



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DFoFMg058906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 08:50:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DFoFnu058905; Thu, 13 Mar 2008 08:50:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DFoCRU058895 for <[e-mail]>; Thu, 13 Mar 2008 08:50:13 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 13 Mar 2008 08:50:11 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 13 Mar 2008 08:50:08 -0700 (PDT)
Cc: SIEVE <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 13 Mar 2008 08:44:43 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Proposed charter change
In-reply-to: "Your message dated Thu, 13 Mar 2008 11:00:30 -0400" <[e-mail]>
References: <[e-mail]>
To: Cyrus Daboo <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1205423410; h=Date:	 From:Subject:MIME-version:Content-type; b=ShOe5ASk031r5da+iFUtW6UAc /8I/GzYwYK4ylsHkPPfX53rvXN0lzrSdfAo3Jo534Mn5THoSaFp8mzYhftc2w==
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>

> We would like to see a "show of hands" from implementers on each of the new
> extensions being proposed so that we can judge the interest in each.

OK...

> 	(a) Body (draft-ietf-sieve-body-07.txt)

Partial implementation likely, full implementation unlikely - too expensive
computationally.

> 	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)

We already implement the old draft of this. An update to the current draft is
planned.

> 	(c) Edit header (draft-ietf-sieve-editheader-10.txt)

Already implemented.

> 	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)

Partially implemented. Full implementation likely.

> 	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

Already implemented.

> (2) Finalize and publish the following SIEVE extensions as proposed
> standards:

> 	(a) Date/Index (draft-freed-sieve-date-index-08.txt)

Already implemented.

> 	(b) iHave (draft-freed-sieve-ihave-01.txt)

Already implemented.

> 	(c) Environment (draft-freed-sieve-environment-03.txt)

Already implemented.

> 	(d) Notary (draft-freed-sieve-notary-01.txt)

Will be implemented once specification is completed.

> 	(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)

Already implemented.

> 	(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)

Unlikely to implement.

> 	(g) ManageSIEVE (draft-martin-managesieve-08.txt)

Implementation in progress.

> 	(h) RegEx (draft-ietf-sieve-regex-00.txt)

Already implemented, but will probably need i18n work.

> 	(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)

Under investigation.

> 	(k) Include/multi-script (draft-daboo-sieve-include-05.txt)

We use the multiple script approach instead and this doesn't reallly fit
our storage model. Unlikely to implement but this may change depending
on how the draft progresses.

> 	(k) Address data (draft-melnikov-sieve-external-lists-01)

Not implemented yet but next on the to-do list.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DF0Xsu051955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 08:00:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DF0Xgj051954; Thu, 13 Mar 2008 08:00:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from daboo.name (piper.mulberrymail.com [151.201.22.177] (may be forged)) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DF0Wf9051945 for <[e-mail]>; Thu, 13 Mar 2008 08:00:33 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 117F23FFE79 for <[e-mail]>; Thu, 13 Mar 2008 11:00:32 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHNhjpKurRgA for <[e-mail]>; Thu, 13 Mar 2008 11:00:31 -0400 (EDT)
Received: from dhcp-1790.ietf71.ietf.org (dhcp-1790.ietf71.ietf.org [130.129.23.144]) by daboo.name (Postfix) with ESMTP id 969853FFE6E for <[e-mail]>; Thu, 13 Mar 2008 11:00:31 -0400 (EDT)
Date: Thu, 13 Mar 2008 11:00:30 -0400
From: Cyrus Daboo <[e-mail]>
To: SIEVE <[e-mail]>
Subject: Proposed charter change
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
Below is a proposal for a new charter for the working group based on 
discussions at this weeks IETF meeting.

Please review this and comment.

We would like to see a "show of hands" from implementers on each of the new 
extensions being proposed so that we can judge the interest in each.

Note that we will need document authors/editors to step up for items (3) 
and (4) if we are to include these.

Once the WG has discussed this and decided on exactly what we will work on, 
Alexey and I will propose some milestones. I am hoping that we can complete 
all this work in 12 - 18 months. Note that some of the new drafts are 
already close to last call.

This is all subject to AD and IESG approval, of course.

---
The SIEVE email filtering language is specified in RFC 5228, together with 
a number of extensions.

The SIEVE working group is being re-chartered to:

(1) Finish work on existing in-progress Working Group documents:

	(a) Body (draft-ietf-sieve-body-07.txt)
	(b) Notify mailto (draft-ietf-sieve-notify-mailto.txt)
	(c) Edit header (draft-ietf-sieve-editheader-10.txt)
	(d) Mime loops (draft-ietf-sieve-mime-loop-04.txt)
	(e) Refuse/reject (draft-ietf-sieve-refuse-reject-06.txt)

(2) Finalize and publish the following SIEVE extensions as proposed 
standards:

	(a) Date/Index (draft-freed-sieve-date-index-08.txt)
	(b) iHave (draft-freed-sieve-ihave-01.txt)
	(c) Environment (draft-freed-sieve-environment-03.txt)
	(d) Notary (draft-freed-sieve-notary-01.txt)
	(e) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
	(f) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
	(g) ManageSIEVE (draft-martin-managesieve-08.txt)
	(h) RegEx (draft-ietf-sieve-regex-00.txt)
	(j) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
	(k) Include/multi-script (draft-daboo-sieve-include-05.txt)
	(k) Address data (draft-melnikov-sieve-external-lists-01)

Additional drafts may be added to this list, but only via a charter
revision. There must also be demonstrable willingness in the SIEVE
development community to actually implement a given extension before
it can be added to this charter.

(3) Work on a "Benefits of SIEVE" guide for client and server vendors that:
	(a) Describes the SIEVE protocol and its suite of extensions.
	(b) Explains the benefits of server-side filtering in practical terms.
	(c) Shows how client-side filtering can be migrated to SIEVE.

(4) Produce one or more informational RFCs containing a set of test scripts 
and test email messages that are to be filtered by the scripts, and the 
expected results of that filtering. This will serve as the basis of a 
interoperability test suite to help determine the suitability of moving the 
base specification and selected extensions to Draft status.


-- 
Cyrus Daboo



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DCkhga036860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Mar 2008 05:46:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2DCkhWR036859; Thu, 13 Mar 2008 05:46:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2DCkgLK036851 for <[e-mail]>; Thu, 13 Mar 2008 05:46:43 -0700 (MST) (envelope-from [e-mail])
Received: from [130.129.21.224] (dhcp-15e0.ietf71.ietf.org [130.129.21.224])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 13 Mar 2008 12:46:39 +0000
Message-ID: <[e-mail]>
Date: Wed, 12 Mar 2008 23:12:33 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: [e-mail]
Subject: Re: Updated Sieve environment draft posted
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In my capacity of a technical contributor:

Ned Freed wrote:

> I just posted an update to the environment draft; it should be in the
> repository soon. In addition to adding a note about using "name."
> prefixes to group related standard items, I also rearranged the text
> about IANA registrations a bit to make the group (hopefully) a little 
> more
> logical.

I've reviewed the recent changes (and I've reviewed earlier versions of 
the document) and I believe the document is ready for publication.

In particular, I think the current list of attributes specified in the 
document is sufficient and is reasonably described.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BMp8lo063619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2008 15:51:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2BMp8Fb063618; Tue, 11 Mar 2008 15:51:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2BMp6Df063606 for <[e-mail]>; Tue, 11 Mar 2008 15:51:07 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 11 Mar 2008 15:51:05 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 11 Mar 2008 15:51:01 -0700 (PDT)
Message-id: <[e-mail]>
Date: Tue, 11 Mar 2008 15:41:03 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Sieve date/index extension
To: [e-mail]
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1205275865; h=Date:	 From:Subject:MIME-version:Content-type; b=j1iytBwDhcxRpUwTPX/Bwn/4S GJnIEH/YQcSB8Nk7Ii4lXyLQuZPL+x+VyL3KSpKw2zTmS9Zw4IEh1ZnXG+f8g==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This draft was (briefly) discussed at yesterday's meeting, and Phillip
raised the only issue: Why the handling of a list of headers is
done the way it is.

More specifically, the text currently says:

   Both header and address allow the specification of more than one
   header field name. If more than one header field name is specified
   all the named header fields are counted in the order specified by the
   header-list.

Phillip asked why the semantics weren't instead to look for the nth field in
the order the fields appear in the header.

The main reason for this is that while i see some value in being able to
determin the relative order of fields in a header, the ability to find do a a
limited sort of ordering check while looking for a single string and not being
able to determine which field matched didn't strike me as in any way useful.
And these semantics interfere with implementations like ours that use what
amounts to a hash table to quickly find headers with a given name - as everyone
knows, hashes are great at finding things quickly but sucky at retaining
ordering information.

I frankly have no idea whether or not this optimization in our implementation
is important. But when you operate in the hundreds of messages a second realm
at million mailbox sites and a significant number of mailboxes having
very substantial sieves (hundreds of tests in a single sieve are not uncommon),
it's only sensible to take any speedup you can get.

So, absent a compelling use-case for changing the semantics, I'd really prefer
to leave this as-is.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ANViqa008870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Mar 2008 16:31:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m2ANViNe008869; Mon, 10 Mar 2008 16:31:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m2ANVfSn008859 for <[e-mail]>; Mon, 10 Mar 2008 16:31:44 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 10 Mar 2008 16:31:40 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 10 Mar 2008 16:31:34 -0700 (PDT)
Message-id: <[e-mail]>
Date: Mon, 10 Mar 2008 16:29:21 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Updated Sieve environment draft posted
To: [e-mail]
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1205191900; h=Date:	 From:Subject:MIME-version:Content-type; b=p1yLW2IU1NC4p7g7+fbBlwLTT FtafpfSuaghDQAJ3l9ktrdCl35raTUv9Jhu9JAYF3LsSzH+YjUg7puXVGvNnA==
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 just posted an update to the environment draft; it should be in the
repository soon. In addition to adding a note about using "name."
prefixes to group related standard items, I also rearranged the text
about IANA registrations a bit to make the group (hopefully) a little more
logical.

Please review and if this seems OK, it's time for last call.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m27MHxX5012315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Mar 2008 15:17:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m27MHxsi012314; Fri, 7 Mar 2008 15:17:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m27MHvhj012304 for <[e-mail]>; Fri, 7 Mar 2008 15:17:58 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 57EA64AC5E; Fri,  7 Mar 2008 23:17:54 +0100 (CET)
Received: from 195.30.37.9 (HELO libertango.oryx.com) by kalyani.oryx.com with esmtp id 1204928274-21199-294; Fri, 7 Mar 2008 23:17:54 +0100
Message-Id: <[e-mail]>
Date: Fri, 7 Mar 2008 23:17:54 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Final sanity check on draft-ietf-sieve-mime-loop-04.txt
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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 lost track of that draft. Sorry. Three comments and a bonus.

1. for_every_part jars. We don't have file_into, we don't have any_child.

I don't mind underscores per se, but I do mind heterodoxy. Using 
gluedtogethernames sometimes, using underscore_names sometimes and 
camelCaseNames sometimes makes the language unnecessarily messy. (Yes, 
I know we don't have camelCase anywhere. At least not that I've 
noticed.)

2. break has been difficult in C for decades when nested loops are used, 
do we need to repeat it? Wouldn't it be better to tie break and its 
loop explicitly, e.g. with an identifier? The identifier would be 
optional on the loop and mandatory on the break.

3. Perhaps I'm tired, but it wasn't clear to me whether if two loops are 
nested, both operate on _every_ bodypart, O(n^2) and all, or whether 
the inner only operates on children of the bodypart currently accessed 
by the outer loop. The former seems correct, but I'm not thrilled to 
have O(n^2) mandatory behaviour, and O(n^m) possible if more than two 
levels is supported.

Bonus. Philosophy. I like the way :anychild without for_every_part 
works. That makes it possible to do parallel processing instead of 
sequential. If I want to process, say, ten or a hundred thousand 
messages with a single sieve script, that becomes important. I can 
transform the test to a database lookup and the query planner will 
generally do well. This makes some clever reprocessing of an entire 
mailbox possible. "Your new sieve script would have filed <these> 
messages into <that mailbox>. Do you want to move them now?". break and 
perhaps for_every_part torpedoes such transformations. I wonder whether 
that's necessary. I wonder whether it's really the same problem as the 
O(n^m) behaviour of nested for_every_part.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m27KwABH003438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Mar 2008 13:58:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m27KwA4H003437; Fri, 7 Mar 2008 13:58:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m27Kw9pQ003428 for <[e-mail]>; Fri, 7 Mar 2008 13:58:10 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.7] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 7 Mar 2008 19:10:08 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Fri, 07 Mar 2008 19:09:16 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Final sanity check on draft-ietf-sieve-mime-loop-04.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cyrus and Tony have updated Sieve MIME loops document. Cyrus should send 
out a message (I apologize if he did already and I missed it) about 
which changes were addressed and which were not (and why).

I would like to ask all people who commented on the document earlier to 
review if their comments were addressed. If there are no comments on the 
document before March 21st, I would recommend its publication.

Regards,
Alexey,



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m252oTG2014017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 19:50:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m252oTXJ014016; Tue, 4 Mar 2008 19:50:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m252oSul014009 for <[e-mail]>; Tue, 4 Mar 2008 19:50:28 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 4 Mar 2008 18:50:26 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 04 Mar 2008 18:50:24 -0800 (PST)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Tue, 04 Mar 2008 18:18:26 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: action reject and smtp RCPT TO:
In-reply-to: "Your message dated Wed, 05 Mar 2008 00:17:13 +0100" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]> <kfU0rHTCtRBPBX/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1204685426; h=Date:	 From:Subject:MIME-version:Content-type; b=uc57z1RyvL0KD755keJq69ZEr QmPjcJ4rNF9lXdk0hvjg10QchyON+t4nqgYQsutNgHEUwLRhw/7vHDlrtrdoQ==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hello,

> >>     About the spamtest issue: it shall be evaluated after data.
> >
> > Why? What if the necessary information is already available and nothing
> > in the message body is capable of overriding it? Why would a ban on early
>  > evaluation of scripts that use spamtest make any more sense than a
>  > ban on early evaluation of scripts that use reject?

> Doing heuristic spam analysis can combine a lot of rules, some giving
> positive and other negative weight on the result. The fact that the
> envelope increases the spaminess, does not mean that the body of the
> message will not decrease it. At the end the total spaminess can be
> acceptable for the recipient, even if the envelope went above the limit.
> So to be accurate, the spamtest shall be done after DATA .

Sigh. All of this is completely obvious and completely irrelevant. For the
third time, there can be cases where the analysis done on the envelope is
sufficient and no, repeat NO, analysis of the message content is capable of
overriding. In such cases the message might as well be refused at the envelope
stage and making some arbitrary rule saying this mustn't be done is every
bit as inappropriate as the rule against doing envelope time rejects
you're arguing against (despite the fact that no such rule exists).

> In the cases when the spam software works only on the envelopes, or
> cannot decrease the spaminess due additional rules, then spamtest can be
> evaluated before DATA as well.

Which is exactly what I've been saying from the start.

> >> If I
> >> remember correctly, there was an idea to extend the envelope test to
> >> check against the sending host (apart from sender and recipient) and
> >> check using external lists if the sending host is blacklisted.

> > However, no such extension has been defined or even, aside from a passing
> > mention, discussed.

> Ned said on 8th October 2007 to look on
> draft-freed-sieve-environment-01, when it comes out, as the idea of
> remote-host and remote-ip will be presented there. Right now I see it is
> really at http://tools.ietf.org/html/draft-freed-sieve-environment-01.

Correct, but the environment extension gives you access to the necessary
information but doesn't do the whitelist/blacklist part, which necessary for
this to gain any sort of equivalency with spamtest.

I actually favor the more general approach described in the (now expired)
draft-melnikov-sieve-external-lists-01.txt, modulo a few changes I suggested
on the list some time back. This provides a generic external list access
mechanism which can be usedd for all sorts of different purposes.

However, now that you have brought up environment, its another extension that
potentially interacts with early evaluation in interesting ways. I hadn't
really thought about it before and the initial set of environment items doesn't
include anything that depends on message content (nor do any of the exxtensions
we''re planning on implementing), but it is not beyond the realm of possibility
that some environment item might be defined that could not be evaluated at RCPT
TO time.

> >>  > FWIW: My sieve interpreter does exactly what we're (not) allowing: I
> >>  > fetch the sieve script as part of verifying that the rcpt to address
> >>  > exists, and evaluate until some test fails for lack of data. I think
> >>  > the draft as it stands is fine.
> >
> >> I think this is wrong, as it does not allow combining keep and reject.
> >
> > I fail to see anything in this implementation description that would
> > create a
> > problem for combining keep and reject. And even if it did, since the draft
> > strongly recommends implementations to forbid this combination (our
> > implementation definitely does this), I fail to see the point of any of
> > this.

> If reject is done at RCPT time and there is no DATA afterwards (due the
> lack of accepting recipients), keep cannot be made. (Keep what?)

> The need of combining keep and reject was addresses in the discussion
> from 2006-07-11 as a sort of logging the process.

Yes, I recall the discussion. I still think its a totally bogus thing to do and
the draft still recommends that they be incompatible.

> >> The reject action shall be executed after RCPT TO:, if the script
> >> terminated successfully (= reached <EOF> or stop; without making
> >> header/body tests, or invoking the keep action) being executed there.
> >
> > This goes much too far - it actually recommends if not requires
> > implementations
> > implement early evaluation - and I am adamantly opposed to it.

> This is my view on Arnt's FWIW: Arnt said that reject is executed, if no
> test or actions failed before reaching "reject". I answered, that this
> approach does not allow to combine keep and reject/fileinto and
> reject/notify and reject/whatever and reject. Instead, reject shall be
> applied during early evaluation only if the script terminates
> successfully. (The other option is to make reject if no actions/tests
> failed yet).

OK, got it. Arnt has already clarified that this is in fact a nonissue for him.
It is for us as well - we don't stop evaluating at reject or anything else for
that matter besides stop or an error of some sort.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24NHHPD031999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 16:17:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m24NHH1u031998; Tue, 4 Mar 2008 16:17:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24NHFPJ031992 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 4 Mar 2008 16:17:17 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1JWgNm-0003cV-EX; Wed, 05 Mar 2008 00:17:14 +0100
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.16] (d83-181-86-228.cust.tele2.de [83.181.86.228]) (authenticated bits=0) by smtp.aegee.org (8.14.2/8.13.6) with ESMTP id m24NHEZE021539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 4 Mar 2008 23:17:15 GMT
Message-ID: <[e-mail]>
Date: Wed, 05 Mar 2008 00:17:13 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: action reject and smtp RCPT TO:
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]> <kfU0rHTCtRBPBX/[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.92.1/6125/Tue Mar  4 19:01:27 2008 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

>>     About the spamtest issue: it shall be evaluated after data.
> 
> Why? What if the necessary information is already available and nothing 
> in the message body is capable of overriding it? Why would a ban on early 
 > evaluation of scripts that use spamtest make any more sense than a
 > ban on early evaluation of scripts that use reject?

Doing heuristic spam analysis can combine a lot of rules, some giving 
positive and other negative weight on the result. The fact that the 
envelope increases the spaminess, does not mean that the body of the 
message will not decrease it. At the end the total spaminess can be 
acceptable for the recipient, even if the envelope went above the limit. 
So to be accurate, the spamtest shall be done after DATA .

In the cases when the spam software works only on the envelopes, or 
cannot decrease the spaminess due additional rules, then spamtest can be 
evaluated before DATA as well.

>> If I
>> remember correctly, there was an idea to extend the envelope test to
>> check against the sending host (apart from sender and recipient) and
>> check using external lists if the sending host is blacklisted.
> 
> However, no such extension has been defined or even, aside from a passing
> mention, discussed.

Ned said on 8th October 2007 to look on 
draft-freed-sieve-environment-01, when it comes out, as the idea of 
remote-host and remote-ip will be presented there. Right now I see it is 
really at http://tools.ietf.org/html/draft-freed-sieve-environment-01.

>>  > FWIW: My sieve interpreter does exactly what we're (not) allowing: I
>>  > fetch the sieve script as part of verifying that the rcpt to address
>>  > exists, and evaluate until some test fails for lack of data. I think
>>  > the draft as it stands is fine.
> 
>> I think this is wrong, as it does not allow combining keep and reject.
> 
> I fail to see anything in this implementation description that would 
> create a
> problem for combining keep and reject. And even if it did, since the draft
> strongly recommends implementations to forbid this combination (our
> implementation definitely does this), I fail to see the point of any of 
> this.

If reject is done at RCPT time and there is no DATA afterwards (due the 
lack of accepting recipients), keep cannot be made. (Keep what?)

The need of combining keep and reject was addresses in the discussion 
from 2006-07-11 as a sort of logging the process.

>> The reject action shall be executed after RCPT TO:, if the script
>> terminated successfully (= reached <EOF> or stop; without making
>> header/body tests, or invoking the keep action) being executed there.
> 
> This goes much too far - it actually recommends if not requires 
> implementations
> implement early evaluation - and I am adamantly opposed to it.

This is my view on Arnt's FWIW: Arnt said that reject is executed, if no 
test or actions failed before reaching "reject". I answered, that this 
approach does not allow to combine keep and reject/fileinto and 
reject/notify and reject/whatever and reject. Instead, reject shall be 
applied during early evaluation only if the script terminates 
successfully. (The other option is to make reject if no actions/tests 
failed yet).


	Greetings,
		Dilian



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24MM7UL027915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 15:22:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m24MM7vb027914; Tue, 4 Mar 2008 15:22:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m24MM3XK027904 for <[e-mail]>; Tue, 4 Mar 2008 15:22:04 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 4 Mar 2008 14:21:59 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 04 Mar 2008 14:21:53 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Arnt Gulbrandsen <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Tue, 04 Mar 2008 13:53:43 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: action reject and smtp RCPT TO:
In-reply-to: "Your message dated Mon, 03 Mar 2008 16:54:26 +0100" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]> <kfU0rHTCtRBPBX/[e-mail]> <[e-mail]> <[e-mail]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1204669318; h=Date:	 From:Subject:MIME-version:Content-type; b=Qw6/bANAQKMVpd7URnSOOoo/b UcMR9cI5CntMVEY+Rki4PV7H+EbJ1lRfShmpG58DvZsis0lcUVZJRp19iApjA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 	Hello,

> 	I think draft-ietf-sieve-refuse-reject-06 implicitly forbids sending
> 550 after RCPT. In Section 2.1 (Action ereject) the SMTP 550 way is
> shifted to Section 2.1.1 (Rejecting a message at the SMTP/LMTP protocol
> level) and Section 2.1.1 shifts the problem to Section 2.1.2 (Rejecting
> a message by sending a DSN). Or may be I am wrong?

I'm sorry, but you are quite simply wrong about this. First, just because
something isn't discussed doesn't mean it is disalllowed. And section 2.1.2 is
quite clear in stating that it applies to rejections occuring after message
data has been received. That's the only sensible interpretation the phrase "may
receive a message via SMTP" can possibly have. And the text goes on to talk
about the fact that this restriction doesn't apply to LMTP because LMTP has
per-recipient replies after DATA, which only makes sense if we're talking about
responses after message data has been transfererd.

Now, while I think the current text is already quite clear, in order
to forestall further argument I suggest changing the first paragraph
of section 2.1.2 to read:

   An implementation may need to respond to the transfer of message
   data when more than one RCPT TO has been accepted by the server,
   and at least one recipient but not all of are refusing delivery
   (whether the refusal is caused by a Sieve "ereject" action or for
   some other reason).  In this case, the server MUST accept the
   message and generate DSNs for all recipients that refused delivery.
   Note that this exception does not apply to LMTP, as LMTP is able
   to reject messages on a per-recipient basis after message data
   has been transferred.

> 	About the spamtest issue: it shall be evaluated after data.

Why? What if the necessary information is already available and nothing in the
message body is capable of overriding it? Why would a ban on early evaluation
of scripts that use spamtest make any more sense than a ban on early evalaution
of scripts that use reject?

> If I
> remember correctly, there was an idea to extend the envelope test to
> check against the sending host (apart from sender and recipient) and
> check using external lists if the sending host is blacklisted.

However, no such extension has been defined or even, aside from a passing
mention, discussed.

> Then the
> mail can be rejected according to the user's preferences and not due the
> site policy. Can we leave for now spamtest out the discussion?

Not if what we're talking about is explicit adding text discussing early
evaluation of sieve scripts. In that case I insist that the discussion
encompass the effects of early evaluation on every test and action we have
defined so far. When it comes to implementation methods we either have to
discuss a given approach thoroughly or not at all.

> 	The idea of the early evaluation in multi-recipient messages is to
> reduce the amount of generated NDRs, when some of the recipients are
> mailboxes (accept spam) and others are mailing lists (who do not want to
> discard messages from non list members, ignoring the spaminess). The
> problem with NDRs is that they might end in a spamtrap/honeypot and
> blacklist your server. With early evaluation all this is avoided...

We're all well aware of these issues.

> And
> once again: does draft-ietf-sieve-refuse-reject-06 forbid this behaviour?

No.

>  > FWIW: My sieve interpreter does exactly what we're (not) allowing: I
>  > fetch the sieve script as part of verifying that the rcpt to address
>  > exists, and evaluate until some test fails for lack of data. I think
>  > the draft as it stands is fine.

> I think this is wrong, as it does not allow combining keep and reject.

I fail to see anything in this implementation description that would create a
problem for combining keep and reject. And even if it did, since the draft
strongly recommends implementations to forbid this combination (our
implementation definitely does this), I fail to see the point of any of this.

> The reject action shall be executed after RCPT TO:, if the script
> terminated successfully (= reached <EOF> or stop; without making
> header/body tests, or invoking the keep action) being executed there.

This goes much too far - it actually recommends if not requires implementations
implement early evaluation - and I am adamantly opposed to it.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GXiqq081469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 09:33:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m24GXicX081468; Tue, 4 Mar 2008 09:33:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m24GXgJQ081460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 4 Mar 2008 09:33:44 -0700 (MST) (envelope-from [e-mail])
Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m24GYftH021453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2008 08:34:41 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1204648481; bh=q2gIx/fDuSolX+CkeXuHZONCkDKKDKK4anoH NxV3ROM=; h=Received:Received:Date:From:X-X-Sender:To:cc:Subject: In-Reply-To:Message-ID:References:User-Agent:MIME-Version: Content-Type:Content-Transfer-Encoding; b=swTklUmPTJ1DtWW2J/o77r/N smm9Y3xMai+6IFiLT6k44fxVUxiM9cG1eYRTmADjC0aVMKgcGN0gJjFJb7xbXlwB16+ VxP3DMsNkv2ba+Aan7bTwlcZS/f+u0XM1cdwvRTtAdDnSCsKGBZP9IXqeNByu2mO+Cx s2TQ+jemg9Yvo=
Received: from localhost.localdomain (localhost [127.0.0.1]) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id m24GXtn4029138; Tue, 4 Mar 2008 08:34:09 -0800
Received: from [192.168.0.2] ([adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)]) by fife.sendmail.com with LMTP id m24GY2IK029318 ; Tue, 4 Mar 2008 08:34:08 -0800
Date: Tue, 4 Mar 2008 09:33:25 -0700
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: =?KOI8-R?B?5MnM0c4g8MHMwdXaz9c=?= <[e-mail]>
cc: Philip Guenther <[e-mail]>, IETF Sieve WG <[e-mail]>
Subject: Re: action reject and smtp RCPT TO:
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]>  <[e-mail]>  <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Alpine 1.00 (BSO 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
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, 2 Mar 2008, Дилян Палаузов wrote:
>>> Does this mean, that a recipient cannot be rejected after RCPT TO: and 
>>> before DATA: in a multi recipient message?
>> 
>> Yes, that's exactly what it means.

My apologies for my unclear statement.  The above was in relation to this 
text from the draft:
    Note that if a message is arriving over SMTP and has multiple
    recipients, some of whom have accepted the message, Section 2.1.2
    defines how to reject such a message.

In light of the quote, I interpreted the "after RCPT" in your question as 
meaning "after being accepted at RCPT time".  That is, I thought you were 
asking if it was possible to perform individual rejection of recipients 
that were accepted at RCPT time.

As for your actual question: IMO, the possibility of rejecting individual 
recipients by rejecting their RCPT commands is permitted by the draft.


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23GmLqP046117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 09:48:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m23GmLwj046113; Mon, 3 Mar 2008 09:48:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23GmKIR046105 for <[e-mail]>; Mon, 3 Mar 2008 09:48:20 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 7C2184AC6D; Mon,  3 Mar 2008 17:48:19 +0100 (CET)
Received: from 195.30.37.9 (HELO libertango.oryx.com) by kalyani.oryx.com with esmtp id 1204562899-96135-1539; Mon, 3 Mar 2008 17:48:19 +0100
Message-Id: <Yo4HM9/[e-mail]>
Date: Mon, 3 Mar 2008 17:48:18 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: action reject and smtp RCPT TO:
Cc: Ned Freed <[e-mail]>, =?KOI8-R?b?5MnM0c4g8MHMwdXaz9c=?= <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]> <kfU0rHTCtRBPBX/[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=koi8-r; format=flowed
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m23GmLIR046106
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>

äÉÌÑÎ ðÁÌÁÕÚÏ× writes:
> I think this is wrong, as it does not allow combining keep and reject.

In my code, keep (even implicit keep) is a command which cannot complete 
at RCPT TO time for lack of data. So it works.

I agree with Ned that going into this level of detail in the document is 
not helpful. This is a very minor point, and spending text on it will 
help very few of the document's readers. For most readers it's just a 
weird digression, and digressions are not good.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23FsWOE041621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 08:54:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m23FsWsD041620; Mon, 3 Mar 2008 08:54:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23FsTp9041603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 3 Mar 2008 08:54:31 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1JWCzj-0005Qf-S5; Mon, 03 Mar 2008 16:54:27 +0100
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.14] (d83-181-67-131.cust.tele2.de [83.181.67.131]) (authenticated bits=0) by smtp.aegee.org (8.14.2/8.13.6) with ESMTP id m23FsV3C003595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 15:54:33 GMT
Message-ID: <[e-mail]>
Date: Mon, 03 Mar 2008 16:54:26 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: action reject and smtp RCPT TO:
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]> <kfU0rHTCtRBPBX/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.92.1/6093/Mon Mar  3 15:03:18 2008 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

	Hello,

	I think draft-ietf-sieve-refuse-reject-06 implicitly forbids sending 
550 after RCPT. In Section 2.1 (Action ereject) the SMTP 550 way is 
shifted to Section 2.1.1 (Rejecting a message at the SMTP/LMTP protocol 
level) and Section 2.1.1 shifts the problem to Section 2.1.2 (Rejecting 
a message by sending a DSN). Or may be I am wrong?

	About the spamtest issue: it shall be evaluated after data. If I 
remember correctly, there was an idea to extend the envelope test to 
check against the sending host (apart from sender and recipient) and 
check using external lists if the sending host is blacklisted. Then the 
mail can be rejected according to the user's preferences and not due the 
site policy. Can we leave for now spamtest out the discussion?

	The idea of the early evaluation in multi-recipient messages is to 
reduce the amount of generated NDRs, when some of the recipients are 
mailboxes (accept spam) and others are mailing lists (who do not want to 
discard messages from non list members, ignoring the spaminess). The 
problem with NDRs is that they might end in a spamtrap/honeypot and 
blacklist your server. With early evaluation all this is avoided... And 
once again: does draft-ietf-sieve-refuse-reject-06 forbid this behaviour?

 > FWIW: My sieve interpreter does exactly what we're (not) allowing: I
 > fetch the sieve script as part of verifying that the rcpt to address
 > exists, and evaluate until some test fails for lack of data. I think
 > the draft as it stands is fine.

I think this is wrong, as it does not allow combining keep and reject. 
The reject action shall be executed after RCPT TO:, if the script 
terminated successfully (= reached <EOF> or stop; without making 
header/body tests, or invoking the keep action) being executed there.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23EvtZA037768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 07:57:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m23EvtGd037767; Mon, 3 Mar 2008 07:57:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m23Evroc037761 for <[e-mail]>; Mon, 3 Mar 2008 07:57:54 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 3 Mar 2008 06:57:49 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 03 Mar 2008 06:57:43 -0800 (PST)
Cc: [e-mail], Ned Freed <[e-mail]>, =?KOI8-R?b?5MnM0c4g8MHMwdXaz9c=?= <[e-mail]>
Message-id: <[e-mail]>
Date: Mon, 03 Mar 2008 06:54:19 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: action reject and smtp RCPT TO:
In-reply-to: "Your message dated Mon, 03 Mar 2008 09:13:44 +0100" <kfU0rHTCtRBPBX/[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]> <kfU0rHTCtRBPBX/[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1204556269; h=Date:	 From:Subject:MIME-version:Content-type; b=pnqzVT2SyaBQ4FgNvV/cjn/YC lq2J29AoLVfMEFc0SDvhg1i6JWSM9uXJ2rjMzvXSGc6Lca0kffXEMId/1CSZw==
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>

> FWIW: My sieve interpreter does exactly what we're (not) allowing:

AFAIK nobodhy is talking about not allowing this. The question is whether or
not we should specify all of the nuances involved in supporting this mode of
operation, and if we're going to whether or not this is the right place to do
it. I remain to be convinced of the need to specify this and I'm opposed to
doing it in this document.

> I
> fetch the sieve script as part of verifying that the rcpt to address
> exists, and evaluate until some test fails for lack of data. I think
> the draft as it stands is fine.

Our implementation doesn't work this way but nevertheless allows some types of
Sieves to be evaluated at RCPT TO or even MAIL FROM time.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m238Dlsw098223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2008 01:13:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m238Dl42098222; Mon, 3 Mar 2008 01:13:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m238DkpI098214 for <[e-mail]>; Mon, 3 Mar 2008 01:13:46 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id AD2974AC50; Mon,  3 Mar 2008 09:13:44 +0100 (CET)
Received: from 195.30.37.9 (HELO libertango.oryx.com) by kalyani.oryx.com with esmtp id 1204532024-96135-1345; Mon, 3 Mar 2008 09:13:44 +0100
Message-Id: <kfU0rHTCtRBPBX/[e-mail]>
Date: Mon, 3 Mar 2008 09:13:44 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: action reject and smtp RCPT TO:
Cc: Ned Freed <[e-mail]>, =?KOI8-R?b?5MnM0c4g8MHMwdXaz9c=?= <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

FWIW: My sieve interpreter does exactly what we're (not) allowing: I 
fetch the sieve script as part of verifying that the rcpt to address 
exists, and evaluate until some test fails for lack of data. I think 
the draft as it stands is fine.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m230g0xF060097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Mar 2008 17:42:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m230g0dd060096; Sun, 2 Mar 2008 17:42:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m230fwVx060084 for <[e-mail]>; Sun, 2 Mar 2008 17:41:59 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sun, 2 Mar 2008 16:41:56 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sun, 02 Mar 2008 16:41:49 -0800 (PST)
Cc: IETF Sieve WG <[e-mail]>
Message-id: <[e-mail]>
Date: Sun, 02 Mar 2008 15:52:17 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: action reject and smtp RCPT TO:
In-reply-to: "Your message dated Sat, 01 Mar 2008 19:14:21 +0100" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1204504914; h=Date:	 From:Subject:MIME-version:Content-type; b=VY3smHcvJL8lFBTdN2swc81Kf eCZMsOGLYWQ+A1K6xwMFW2h9izgz7QD/l8qqLfx2hn5hgumbAETbdFit+wtkA==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 	Hello,

> 	I read the discussion from Juli 2007 about the reject concerns. There
> is still something that is not addressed in
> draft-ietf-sieve-refuse-reject-06 -- early evaluation of scripts.

Of course it s possible to, say, evaluate a script that only uses envelope
"from" tests at the MAIL FROM stage, or to evaluate a script that only uses
envelope tests at the RCPT TO stage, but I really have to question the utility
of an extended discussions of the issues surrounding using sieve this way. The
overwhelming majority of scripts we end up with in practice make extensive use
of header and other tests that depend on message content and henace cannot be
evaluated until after the DATA phase.

And while the reject action is almost certainly the case where early evaluation
offers the most advantage, it isn't the only test or action where early
evaluation brings up issues, some of them fairly subtle. Consider spamtest - it
is possible in many cases to compute a spam score based solely on envelope
information. But better results are usually produced if content is considered.
So how should this be handled? Should

    require ["spamtest", "reject, "relational", "comparator-i;ascii-numeric"];
    if spamtest :value "ge" :comparator "i;ascii-numeric" "3"
    {
	reject "Keep your spam";
    }

be evaluated at RCPT TO when possible, or should it have to wait until after
DATA because a better score is available then, or perhaps it should be
evaluated twice? And all this totally ignores the implementation issues with
actually using exist spam filtering software with only an envelope.

Now, has the issue of early evaluation been one described in the sieve base
specification and given due considerstion in all the other sieve documents (the
currentdate test defined in date-index is an obvious example of a place where
such considerations should be described), not only would I have no problem with
adding such a discussion to this document, I would have insisted on it. But
that's not now things are. We haven't dealt with this concept at all and IMO
trying t do so as s side note in this one extension is not a good idea.

If early evaluation is indeed of sufficient interest to warrant specification
then the way to handle it at ths point is with an additional informational
specification. But as I stated previously, I am dubious that's there's
sufficient operational utility here to bother.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m22DRPl2008120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Mar 2008 06:27:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m22DRPua008119; Sun, 2 Mar 2008 06:27:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m22DRNd4008111 for <[e-mail]>; Sun, 2 Mar 2008 06:27:24 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id D80674AC5B for <[e-mail]>; Sun,  2 Mar 2008 14:27:22 +0100 (CET)
Received: from 195.30.37.9 (HELO libertango.oryx.com) by kalyani.oryx.com with esmtp id 1204464442-96135-1165; Sun, 2 Mar 2008 14:27:22 +0100
Message-Id: <7x419vzFouK8NNfReWb/[e-mail]>
Date: Sun, 2 Mar 2008 14:27:22 +0100
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: action reject and smtp RCPT TO:
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
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>

Philip Guenther writes:
> Because doing so in SMTP is impossible without unstandardized 
> extensions. (How is the server supposed to indicate that a message is 
> being rejected for rcpt A but not rcpt B?)

MAIL FROM:<[e-mail]>
250 OK
RCPT TO:<[e-mail]>
     if envelope :all :is "from" "[e-mail]" {
         reject;
     }
550 I reject mail from [e-mail]

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21NGqw7048210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 16:16:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m21NGqmD048209; Sat, 1 Mar 2008 16:16:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21NGoDI048203 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 1 Mar 2008 16:16:51 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1JVawi-0005AB-O7; Sun, 02 Mar 2008 00:16:48 +0100
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [129.13.226.3] (vpnwwwext.rz.uni-karlsruhe.de [129.13.72.177]) (authenticated bits=0) by smtp.aegee.org (8.14.2/8.13.6) with ESMTP id m21NGnYC013935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 23:16:49 GMT
Message-ID: <[e-mail]>
Date: Sun, 02 Mar 2008 00:16:53 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Philip Guenther <[e-mail]>
CC: IETF Sieve WG <[e-mail]>
Subject: Re: action reject and smtp RCPT TO:
References: <[e-mail]>  <[e-mail]>  <[e-mail]>  <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.92.1/6074/Sat Mar  1 21:59:36 2008 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

>> Does this mean, that a recipient cannot be rejected after RCPT TO: and 
>> before DATA: in a multi recipient message?
> 
> Yes, that's exactly what it means.
> 
>> In the discussion I have not seen why this shall not be possible.
> 
> Because doing so in SMTP is impossible without unstandardized 
> extensions. (How is the server supposed to indicate that a message is 
> being rejected for rcpt A but not rcpt B?)

MAIL FROM: <[e-mail]>
250 OK
RCPT TO: <[e-mail]>
250 OK
RCPT TO: <[e-mail]>
550-You are not permitted to post to [e-mail] from
550 your [e-mail] address.
RCPT TO: <[e-mail]>
250 OK
DATA ...

Why shouldn't be a sieve script allowed to set the 550-response here?

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21Mxru2047003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 15:59:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m21MxrgR047002; Sat, 1 Mar 2008 15:59:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21MxpXg046993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sat, 1 Mar 2008 15:59:52 -0700 (MST) (envelope-from [e-mail])
Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m21N0hc1021726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 1 Mar 2008 15:00:43 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1204412443; bh=W/Ic6rp6N9Q8OzjcOw3lVDw9nD9/BU3QFbbH QwmXeHc=; h=Received:X-DKIM:DKIM-Signature:Date:From:X-X-Sender:To: cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type:Content-Transfer-Encoding:X-MM-Ex-RefId; b=txqzHg+MTXS3B5Np/0/COFQLjPaZKngvIB5Bcyhsxp/18COy+NCm7IHcZSAS+7cf8 pa7v05wb2HNBwnqseROJexGMB7SPdvoQxbyRvakdMkASwObFJpzHVS8HNRE2s/LQKI8 oxNLNkJMlkyACOJGP3cBmoEcTYgudHMawLpyCZk=
Received: from [10.55.44.152] (75-171-163-144.hlrn.qwest.net [75.171.163.144]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id m21MxOt3028421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 15:00:07 -0800
X-DKIM: Sendmail DKIM Filter v2.2.2 fife.sendmail.com m21MxOt3028421
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1204412411; bh=W/Ic6rp6N9Q8OzjcOw3lVDw9nD9/BU3QFbbHQ wmXeHc=; h=Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:User-Agent:MIME-Version:Content-Type: Content-Transfer-Encoding:X-MM-Ex-RefId; b=B6ISoCSwjF+8KXjK+QkKbdh 3q8vfrVsNUKnkYT7+rz0ve/ra+skk/i8uaV4vuXlRSwPyhBHPM90UoLr5OhfTYOIDG8 iWn4Po8bo/JYGltSGMwInB68rz3FHHcXiDL3qs0l8l3Hn0rMX5PTu/5MmnPNOnkf0WG mQUORLdKzu4cOg=
Date: Sat, 1 Mar 2008 15:58:45 -0700
From: Philip Guenther <[e-mail]>
X-X-Sender: [e-mail]
To: =?KOI8-R?B?5MnM0c4g8MHMwdXaz9c=?= <[e-mail]>
cc: IETF Sieve WG <[e-mail]>
Subject: Re: action reject and smtp RCPT TO:
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>  <[e-mail]>  <[e-mail]>  <[e-mail]> <1203006439.25161.83.camel@oslhomkje> <[e-mail]>
User-Agent: Alpine 1.00 (BSO 882 2007-12-20)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
X-MM-Ex-RefId: 149371::080301150010-5B8E6B90-7BD9E0F5/0-0/0-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Sat, 1 Mar 2008, Дилян Палаузов wrote:
...
> Does this mean, that a recipient cannot be rejected after RCPT TO: and before 
> DATA: in a multi recipient message?

Yes, that's exactly what it means.


> In the discussion I have not seen why this shall not be possible.

Because doing so in SMTP is impossible without unstandardized extensions. 
(How is the server supposed to indicate that a message is being rejected 
for rcpt A but not rcpt B?)


Philip Guenther



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21IEWZi011087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2008 11:14:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m21IEWu8011085; Sat, 1 Mar 2008 11:14:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m21IETu1011072 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 1 Mar 2008 11:14:31 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1JVWE4-0004sD-6G; Sat, 01 Mar 2008 19:14:24 +0100
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.13] (d83-181-84-29.cust.tele2.de [83.181.84.29]) (authenticated bits=0) by smtp.aegee.org (8.14.2/8.13.6) with ESMTP id m21IELRD024570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 1 Mar 2008 18:14:24 GMT
Message-ID: <[e-mail]>
Date: Sat, 01 Mar 2008 19:14:21 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: Re: action reject and smtp RCPT TO:
References: <[e-mail]>	 <[e-mail]>	 <[e-mail]>  <[e-mail]> <1203006439.25161.83.camel@oslhomkje>
In-Reply-To: <1203006439.25161.83.camel@oslhomkje>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.92.1/6064/Sat Mar  1 16:27:15 2008 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

	Hello,

	I read the discussion from Juli 2007 about the reject concerns. There 
is still something that is not addressed in 
draft-ietf-sieve-refuse-reject-06 -- early evaluation of scripts. More 
concrete I mean that a script can be executed after the RCPT TO and 
before the DATA stage, and then has a stop;.

draft-ietf-sieve-refuse-reject-06
2.1.1. Rejecting a message at the SMTP/LMTP protocol level


    Sieve implementations that are able to reject messages at the SMTP/
    LMTP level MUST do so and SHOULD use the 550 response code.  Note
    that if a message is arriving over SMTP and has multiple recipients,
    some of whom have accepted the message, Section 2.1.2 defines how to
    reject such a message.

Does this mean, that a recipient cannot be rejected after RCPT TO: and 
before DATA: in a multi recipient message? In the discussion I have not 
seen why this shall not be possible.

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


Kjetil Torgrim Homme wrote:
> On Wed, 2008-02-13 at 21:09 +0100, Дилян Палаузов wrote:
>> Hello,
>>
>> If sieve scripts are written in the form:
>>
>> if (envelope tests....) { reject; stop;}
>> some other tests and actions;
>>
>> the scripts can be applied once after the RCPT TO: command and once 
>> after the DATA command. If the first script calling is successful (stop; 
>> is reached without trying tests, that require headers or body), and the 
>> reject action is performed, then the sieve script can reject the message 
>> at the RCPT TO: level.
> 
> see the thread "Re: List of open issues with Sieve reject draft
> (draft-ietf-sieve-refuse-reject-02.txt)" from 2006-07-11.
> 
>> The application of such scripts is, e.g. for mailing lists, with scripts 
>> like
>>
>> 	if (recipient is a mailing list and sender is not allowed to post 
>> there) {reject; stop;}
>>
>> which will save the consequent NDRs, send from the mailing list 
>> software. This approach is not considered in 
>> draft-ietf-sieve-refuse-reject-06, 2.2 Action reject...However 
>> implementations MAY refuse delivery over protocol ..., if and only if 
>> all of the following conditions are true:  2. ...
> 
> I agree it would be beneficial to allow early evaluation of Sieve
> scripts, but I believe we need a separate draft to clarify how it should
> work.  it would be preferable if the refuse-reject document had some
> text to indicate the possibility.
>