subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt

[Dilyan Palauzov <[e-mail]>]

	Hello,
	To what I understood, the issue with method: and subject: was not cleared yet. Let me share what I think:

'subject:" for me the purpose of sieve-notify is to define a general framework for sending notifications, in the most general way a message can be defined. It is true that some notify-gateways support subjects, and others don't, but a subject is a property of a general message. Look on the discussion as an object-oriented programmer: the base class/interface is notify, derived by notify-voip-phone, notify-xmpp, notify-mailto. Suppose notify-voip-phone puts a message in the voice box of the user and displays text on the device's display (voip phones do have ascii display). 

	If we want a common name in all derived classes, the name shall be defined already in the interface. Then notify-xmpp can ignore this tag, in the same way notify-voip-phone can ignore importance. But if there is a subject: to be overwritten, then notify-display-phone is supposed to use this keyword for the text to be displayed. If there is no subject: , they could use display: and even if totally correct, it is not very practical: the user will be then forced to learn the different words used to replace "subject:", except having subject and relying on the notify-extension to interpret it correctly (as will be described in the sieve-notify.. how to use subject. I guess it is already there, but have now now wish to check).
	So I am in favour of having subject: in sieve-notify.

	By the way, what do you think about adding an  "expire: date", in order to allow the mechanism to delte the notification, if it is not delivered within a certain time. E.g. I might like to get jabber message when I get a mail, but when on holiday, I don't want 100 notifications once I am back. Instead the notification might wait three days to be read and then be discarded. 

	"method:" If method: is a must to have, then it is redundant to write "method:" when this can be avoided and I am in favour of removing it. Now, the backward compatibility, there could be a transitional clause, included or not in the final document, that if "methond" is not mentioned, then the last string is considered to describe the method; if it is mentioned, then what follows it is the method. To what I understand from computer lang. grammars it is very easy to define the method "so or so" and I do not imagine very-very huge problems.


importance

abstract 
"expire:"

Aaron Stone wrote:
> On Tue, Dec 19, 2006, Michael Haardt <[e-mail]> said:
> 
>> On Mon, Dec 18, 2006 at 11:29:31PM -0000, Aaron Stone wrote:
>>> I recognize that the point of notifications is to provide "one-liner"
>>> updates, but giving different names to the subject and body fields isn't
>>> good, and then using the subject/body distinction present in xmpp vs. mail
>>> in opposite ways isn't good, either.
>>>
>>> I'm definitely bringing up more than a WGLC should. Oops.
>>>
>>> If instead we had:
>>>
>>>    Usage:  notify 
>>>            [":from" string]
>>>            [":importance" <"1" / "2" / "3">]
>>>            [":options" string-list]
>>>            [":subject" string]
>>>            [":message" string]
>>>            "method:" string 
>> Let's forget about XMPP and mailto for a second, as notify is a generic
>> framework.  The question is: Do we view abstract notification messages
>> in general to be tagged with a subject, with a few real methods not
>> offering one (like SMS), or do we view them being untagged with a few
>> real methods offering one (like mailto)?
>>
>> To me, a notification is the second.  Notes attached to the refridgerator
>> do not have a subject, neither do messages in IRC or SMS. ICQ I don't
>> know. (Comsat? Never mind. ;) We will find a bunch attributes more offered
>> by at least one real method, and that's exactly why we have ":options".
>>
>> That's why I vote against introducing ":subject".  To me, the karma of
>> a message does not include a subject. ;)
> 
> I had written (but edited out of my email) that if the methods each have
> some sort of "subject" field to specify, then it would make sense for the
> base spec to provide it. If we intend for XMPP to be our gateway out to
> IRC, SMS, ICQ, AOL, etc etc. then we'll have to discuss how to degrade
> gracefully when the user gives a subject, regardless if by :subject or by
> :option "subject=This is a Sieve Notification", and transmit the message
> across the other networks.
> 
> Before the end of WGLC on the notify base spec, I would like to know what
> issues we're leaving for ourselves in each of the method specs, so I think
> this will be a key issue to make consistent across methods.
> 
> I am also still not so happy about the keyword and syntax differences vs.
> vacation, but I can live with it.
> 
> Aaron
> 



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 kBKKfJMY012814; Wed, 20 Dec 2006 13:41:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBKKfJac012813; Wed, 20 Dec 2006 13:41:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.rz.uni-karlsruhe.de (smtp2.rz.uni-karlsruhe.de [129.13.185.218]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBKKfEPa012789 for <[e-mail]>; Wed, 20 Dec 2006 13:41:18 -0700 (MST) (envelope-from [e-mail])
Received: from [172.20.21.213] (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1Gx8FR-0001TI-JW; Wed, 20 Dec 2006 21:41:09 +0100
Message-ID: <[e-mail]>
Date: Wed, 20 Dec 2006 21:42:34 +0100
From: Dilyan Palauzov <[e-mail]>
User-Agent: Mail/News 1.5.0.8 (X11/20061119)
MIME-Version: 1.0
To: [e-mail]
Subject: subject: and method: / Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=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>

	Hello,
	To what I understood, the issue with method: and subject: was not cleared yet. Let me share what I think:

'subject:" for me the purpose of sieve-notify is to define a general framework for sending notifications, in the most general way a message can be defined. It is true that some notify-gateways support subjects, and others don't, but a subject is a property of a general message. Look on the discussion as an object-oriented programmer: the base class/interface is notify, derived by notify-voip-phone, notify-xmpp, notify-mailto. Suppose notify-voip-phone puts a message in the voice box of the user and displays text on the device's display (voip phones do have ascii display). 

	If we want a common name in all derived classes, the name shall be defined already in the interface. Then notify-xmpp can ignore this tag, in the same way notify-voip-phone can ignore importance. But if there is a subject: to be overwritten, then notify-display-phone is supposed to use this keyword for the text to be displayed. If there is no subject: , they could use display: and even if totally correct, it is not very practical: the user will be then forced to learn the different words used to replace "subject:", except having subject and relying on the notify-extension to interpret it correctly (as will be described in the sieve-notify.. how to use subject. I guess it is already there, but have now now wish to check).
	So I am in favour of having subject: in sieve-notify.

	By the way, what do you think about adding an  "expire: date", in order to allow the mechanism to delte the notification, if it is not delivered within a certain time. E.g. I might like to get jabber message when I get a mail, but when on holiday, I don't want 100 notifications once I am back. Instead the notification might wait three days to be read and then be discarded. 

	"method:" If method: is a must to have, then it is redundant to write "method:" when this can be avoided and I am in favour of removing it. Now, the backward compatibility, there could be a transitional clause, included or not in the final document, that if "methond" is not mentioned, then the last string is considered to describe the method; if it is mentioned, then what follows it is the method. To what I understand from computer lang. grammars it is very easy to define the method "so or so" and I do not imagine very-very huge problems.


importance

abstract 
"expire:"

Aaron Stone wrote:
> On Tue, Dec 19, 2006, Michael Haardt <[e-mail]> said:
> 
>> On Mon, Dec 18, 2006 at 11:29:31PM -0000, Aaron Stone wrote:
>>> I recognize that the point of notifications is to provide "one-liner"
>>> updates, but giving different names to the subject and body fields isn't
>>> good, and then using the subject/body distinction present in xmpp vs. mail
>>> in opposite ways isn't good, either.
>>>
>>> I'm definitely bringing up more than a WGLC should. Oops.
>>>
>>> If instead we had:
>>>
>>>    Usage:  notify 
>>>            [":from" string]
>>>            [":importance" <"1" / "2" / "3">]
>>>            [":options" string-list]
>>>            [":subject" string]
>>>            [":message" string]
>>>            "method:" string 
>> Let's forget about XMPP and mailto for a second, as notify is a generic
>> framework.  The question is: Do we view abstract notification messages
>> in general to be tagged with a subject, with a few real methods not
>> offering one (like SMS), or do we view them being untagged with a few
>> real methods offering one (like mailto)?
>>
>> To me, a notification is the second.  Notes attached to the refridgerator
>> do not have a subject, neither do messages in IRC or SMS. ICQ I don't
>> know. (Comsat? Never mind. ;) We will find a bunch attributes more offered
>> by at least one real method, and that's exactly why we have ":options".
>>
>> That's why I vote against introducing ":subject".  To me, the karma of
>> a message does not include a subject. ;)
> 
> I had written (but edited out of my email) that if the methods each have
> some sort of "subject" field to specify, then it would make sense for the
> base spec to provide it. If we intend for XMPP to be our gateway out to
> IRC, SMS, ICQ, AOL, etc etc. then we'll have to discuss how to degrade
> gracefully when the user gives a subject, regardless if by :subject or by
> :option "subject=This is a Sieve Notification", and transmit the message
> across the other networks.
> 
> Before the end of WGLC on the notify base spec, I would like to know what
> issues we're leaving for ourselves in each of the method specs, so I think
> this will be a key issue to make consistent across methods.
> 
> I am also still not so happy about the keyword and syntax differences vs.
> vacation, but I can live with it.
> 
> Aaron
> 



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 kBJHs2XP000741; Tue, 19 Dec 2006 10:54:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBJHs2RY000740; Tue, 19 Dec 2006 10:54:02 -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.13.5/8.13.5) with ESMTP id kBJHrwWj000733 for <[e-mail]>; Tue, 19 Dec 2006 10:54:01 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id 89CD16024E45; Tue, 19 Dec 2006 09:53:58 -0800 (PST)
Date: Tue, 19 Dec 2006 17:53:58 -0000
To: "Michael Haardt" <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]>
Cc: <[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>

On Tue, Dec 19, 2006, Michael Haardt <[e-mail]> said:

> 
> On Mon, Dec 18, 2006 at 11:29:31PM -0000, Aaron Stone wrote:
>> I recognize that the point of notifications is to provide "one-liner"
>> updates, but giving different names to the subject and body fields isn't
>> good, and then using the subject/body distinction present in xmpp vs. mail
>> in opposite ways isn't good, either.
>> 
>> I'm definitely bringing up more than a WGLC should. Oops.
>> 
>> If instead we had:
>> 
>>    Usage:  notify 
>>            [":from" string]
>>            [":importance" <"1" / "2" / "3">]
>>            [":options" string-list]
>>            [":subject" string]
>>            [":message" string]
>>            "method:" string 
> 
> Let's forget about XMPP and mailto for a second, as notify is a generic
> framework.  The question is: Do we view abstract notification messages
> in general to be tagged with a subject, with a few real methods not
> offering one (like SMS), or do we view them being untagged with a few
> real methods offering one (like mailto)?
> 
> To me, a notification is the second.  Notes attached to the refridgerator
> do not have a subject, neither do messages in IRC or SMS. ICQ I don't
> know. (Comsat? Never mind. ;) We will find a bunch attributes more offered
> by at least one real method, and that's exactly why we have ":options".
> 
> That's why I vote against introducing ":subject".  To me, the karma of
> a message does not include a subject. ;)

I had written (but edited out of my email) that if the methods each have
some sort of "subject" field to specify, then it would make sense for the
base spec to provide it. If we intend for XMPP to be our gateway out to
IRC, SMS, ICQ, AOL, etc etc. then we'll have to discuss how to degrade
gracefully when the user gives a subject, regardless if by :subject or by
:option "subject=This is a Sieve Notification", and transmit the message
across the other networks.

Before the end of WGLC on the notify base spec, I would like to know what
issues we're leaving for ourselves in each of the method specs, so I think
this will be a key issue to make consistent across methods.

I am also still not so happy about the keyword and syntax differences vs.
vacation, but I can live with it.

Aaron



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 kBJ8UhbY031816; Tue, 19 Dec 2006 01:30:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBJ8UhB2031815; Tue, 19 Dec 2006 01:30:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBJ8UeZ4031796 for <[e-mail]>; Tue, 19 Dec 2006 01:30:43 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.62) (envelope-from <[e-mail]>) id 1GwaMx-0003f9-MP for [e-mail]; Tue, 19 Dec 2006 09:30:39 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:46398) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1GwaMx-0006xN-IE for [e-mail]; Tue, 19 Dec 2006 09:30:39 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1GwaMx-0000tO-5D for [e-mail]; Tue, 19 Dec 2006 09:30:39 +0100
Date: Tue, 19 Dec 2006 09:30:39 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, Dec 18, 2006 at 11:29:31PM -0000, Aaron Stone wrote:
> I recognize that the point of notifications is to provide "one-liner"
> updates, but giving different names to the subject and body fields isn't
> good, and then using the subject/body distinction present in xmpp vs. mail
> in opposite ways isn't good, either.
> 
> I'm definitely bringing up more than a WGLC should. Oops.
> 
> If instead we had:
> 
>    Usage:  notify 
>            [":from" string]
>            [":importance" <"1" / "2" / "3">]
>            [":options" string-list]
>            [":subject" string]
>            [":message" string]
>            "method:" string 

Let's forget about XMPP and mailto for a second, as notify is a generic
framework.  The question is: Do we view abstract notification messages
in general to be tagged with a subject, with a few real methods not
offering one (like SMS), or do we view them being untagged with a few
real methods offering one (like mailto)?

To me, a notification is the second.  Notes attached to the refridgerator
do not have a subject, neither do messages in IRC or SMS. ICQ I don't
know. (Comsat? Never mind. ;) We will find a bunch attributes more offered
by at least one real method, and that's exactly why we have ":options".

That's why I vote against introducing ":subject".  To me, the karma of
a message does not include a subject. ;)

Michael



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 kBJ7JeTm023355; Tue, 19 Dec 2006 00:19:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBJ7Je22023354; Tue, 19 Dec 2006 00:19:40 -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 kBJ7Jc97023346 for <[e-mail]>; Tue, 19 Dec 2006 00:19:39 -0700 (MST) (envelope-from [e-mail])
Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1GwZGD-0003i1-JF; Tue, 19 Dec 2006 08:19:37 +0100
Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id kBJ7Je7a003503 for <[e-mail]>; Tue, 19 Dec 2006 07:19:40 GMT
Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id kBJ7JdvZ003498 for [e-mail]; Tue, 19 Dec 2006 08:19:39 +0100
X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to [e-mail] using -f
Received: from nan-y403.nan.uni-karlsruhe.de (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) by mail.aegee.org (Horde MIME library) with HTTP; Tue, 19 Dec 2006 08:19:39 +0100
Message-ID: <[e-mail]>
Date: Tue, 19 Dec 2006 08:19:39 +0100
From: Dilyan Palauzov <[e-mail]>
To: [e-mail]
Subject: Re: sieve for spamfiltering and greylisting
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-Virus-Scanned: ClamAV 0.88.7/2356/Tue Dec 19 02:19:53 2006 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBJ7Jd97023349
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,
   My idea was not to call external applications, but to provide  
unified interface where different applications read the same sieve  
script but interpret different parts of it. The aim is to minimize the  
amount of interfaces a user needs to work with in order to configure  
the way of the mail from the MTA to his mailbox.

   There are several user's preferences in spamassassin (tool saying  
for each may how high the probability is, that a specific mail is  
spam). Such an example is the whitelisting. Another option is altering  
the scores per user, that matching specific test gives, thus modifying  
the influence that a test has. rewrite_header  
(http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html#basic_message_tagging_options ) modifies the header of the message, in case it is spam. Of course this can be achieved by other means in sieve, but the latter fact is a sign that spamassassin and sieve do very similar things (conditionally rewriting headers) and therefore shall be configured from the same  
place.

   spam rewrite_header nanana, or rather spam rewrite_header subject  
nanana is supposed to prefix the subject-header with +nanana+ in the  
mails marked as spam.

   Greetings,
     Дилян

----- Message from [e-mail] ---------
     Date: Mon, 18 Dec 2006 22:35:22 +0000
     From: Alexey Melnikov <[e-mail]>
Reply-To: Alexey Melnikov <[e-mail]>
  Subject: Re: sieve for spamfiltering and greylisting
       To: Dilyan Palauzov <[e-mail]>
       Cc: [e-mail]


>
> Dilyan Palauzov wrote:
>
>>  Hello,
>>  What happens with a mail between the end MTA and the mailbox?   
>> First  (optionally) greylisting, then (optionally) spamfiltering   
>> and at the  end )optionally) sieve-filtering. All this (optional)   
>> steps could be  up to the user to be configured, hence each of them  
>>  requires different interface:
>>  - one interface for conf. the personal grey listing
>>  - one interface for configuring the personal spam settings and
>>  - managesieve for configuring the personal filters.
>>
>>  It is a bit cumbersome, as all these settings are related to the    
>> same thing (mail delivery from the users' point of view), but   
>> setting  them up requires different approaches.
>>
>>  Maybe you have discussed it already, but recently I was thinking   
>> on  uniting all this settings into one. And my idea concrete is   
>> either to  extend sieve to support settings for external programmes
>
> Hi Dilyan,
> I don't think Sieve is suitable for specifying settings for external
> programs or calling external programs in general.
> (Avoiding support for calling of external programs was one of the
> original goals behind the language).
>
>> or to define  sieve extensions per purpose
>
> This seems to be more sensible.
> In fact I can imagine a Sieve extension for accessing/managing
> greylisting database or other types of externally stored lists of
> addresses (e.g. whitelists)
>
>> (hence one extension for both configuring  spamassassin and dspam).  
>>  In the first case just the name of the  programme will need to be   
>> specified and it will be able to define what  will happen   
>> afterwards with the parameters (and be able to get them  from the   
>> script), e.g
>>  require "prog";
>>  prog grey-listing 10 30
>>  (meaning that the mail shall be retried not later than 30 minutes   
>>  and not earlier than the next 10 minutes, in order to pass the    
>> grey-filtering, or wise-versa - it will be up to the interpreting    
>> programme)
>>  prog spamassassin rewrite_header nanana
>>
>> or in the second case we define a keyword per purpose, the sample    
>> sieve script could look like
>>
>>  require "spam", "grey-listing"
>>  spam rewrite_header nanana
>>  grey-listing off
>
> Can you explain what is the exact meaning of "spam rewrite_header
> nanana" in your example?
>
> Regars,
> Alexey
----- End message from [e-mail] -----



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 kBINTX1v075655; Mon, 18 Dec 2006 16:29:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBINTX83075654; Mon, 18 Dec 2006 16:29:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBINTWOp075647 for <[e-mail]>; Mon, 18 Dec 2006 16:29:32 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id DBDA26024E45; Mon, 18 Dec 2006 15:29:31 -0800 (PST)
Date: Mon, 18 Dec 2006 23:29:31 -0000
To: "Alexey Melnikov" <[e-mail]>, "Michael Haardt" <[e-mail]>
Subject: Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]>
Cc: <[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>

On Mon, Dec 18, 2006, Alexey Melnikov <[e-mail]> said:

> Michael Haardt wrote:
> 
>>>Optional tagged arguments can appear in any order, but they must appear 
>>>before positional arguments.
>>>So if we switch to make the method argument positional, the usage 
>>>statement needs to be modified to become:
>>>
>>>   Usage:  notify 
>>>           [":from" string]
>>>           [":importance" <"1" / "2" / "3">]
>>>           [":options" string-list]
>>>           [":message" string]
>>>           string    
>>>
>>
>>If you write it as
>>
>>  <method: string>
>>
>>it looks much better.
>>
> I agree.
> 
>>But should this start a lengthy discussion
>>in the group, then never mind.
>>  
>>
> I would like to hear at least two other opinions in favor of keeping or 
> changing the current behavior.

I apologize for not being on top of this 1-2 months ago. This is so much
different than Vacation as to cause unreasonable confusion on the part of
end-users writing their own scripts. It is also different in xmpp vs.
mail.

>From draft-ietf-sieve-notify-mailto-01:

   o  The "Subject:" field of the notification message contains the
      value defined by the :message notify tag, as described in
      [Notify].  If there is no :message tag, the subject is retained
      from the triggering message.  Note that Sieve [Variables] can be
      used to advantage here, as shown in the example in Section 3.

Presumably the body would be [MAY be?] empty. 

>From draft-ietf-sieve-notify-xmpp-02:

   o  The XMPP <message/> stanza MAY include a <subject/> child element
      whose value is some configurable text indicating that the message
      is a Sieve notification.

I recognize that the point of notifications is to provide "one-liner"
updates, but giving different names to the subject and body fields isn't
good, and then using the subject/body distinction present in xmpp vs. mail
in opposite ways isn't good, either.

I'm definitely bringing up more than a WGLC should. Oops.

If instead we had:

   Usage:  notify 
           [":from" string]
           [":importance" <"1" / "2" / "3">]
           [":options" string-list]
           [":subject" string]
           [":message" string]
           "method:" string 

Basically that breaks every extant implementation, doesn't it.

Aaron



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 kBIMaARc070434; Mon, 18 Dec 2006 15:36:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBIMaALW070433; Mon, 18 Dec 2006 15:36: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.13.5/8.13.5) with ESMTP id kBIMa9ZB070426 for <[e-mail]>; Mon, 18 Dec 2006 15:36:09 -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]>; Mon, 18 Dec 2006 22:36:07 +0000
Message-ID: <[e-mail]>
Date: Mon, 18 Dec 2006 22:35:22 +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: Dilyan Palauzov <[e-mail]>
CC: [e-mail]
Subject: Re: sieve for spamfiltering and greylisting
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="UTF-8"; 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>

Dilyan Palauzov wrote:

>   Hello,
>   What happens with a mail between the end MTA and the mailbox? First  
> (optionally) greylisting, then (optionally) spamfiltering and at the  
> end )optionally) sieve-filtering. All this (optional) steps could be  
> up to the user to be configured, hence each of them requires 
> different  interface:
>   - one interface for conf. the personal grey listing
>   - one interface for configuring the personal spam settings and
>   - managesieve for configuring the personal filters.
>
>   It is a bit cumbersome, as all these settings are related to the  
> same thing (mail delivery from the users' point of view), but setting  
> them up requires different approaches.
>
>   Maybe you have discussed it already, but recently I was thinking on  
> uniting all this settings into one. And my idea concrete is either to  
> extend sieve to support settings for external programmes

Hi Dilyan,
I don't think Sieve is suitable for specifying settings for external 
programs or calling external programs in general.
(Avoiding support for calling of external programs was one of the 
original goals behind the language).

> or to define  sieve extensions per purpose

This seems to be more sensible.
In fact I can imagine a Sieve extension for accessing/managing 
greylisting database or other types of externally stored lists of 
addresses (e.g. whitelists)

> (hence one extension for both configuring  spamassassin and dspam). In 
> the first case just the name of the  programme will need to be 
> specified and it will be able to define what  will happen afterwards 
> with the parameters (and be able to get them  from the script), e.g
>   require "prog";
>   prog grey-listing 10 30
>   (meaning that the mail shall be retried not later than 30 minutes  
> and not earlier than the next 10 minutes, in order to pass the  
> grey-filtering, or wise-versa - it will be up to the interpreting  
> programme)
>   prog spamassassin rewrite_header nanana
>
> or in the second case we define a keyword per purpose, the sample  
> sieve script could look like
>
>   require "spam", "grey-listing"
>   spam rewrite_header nanana
>   grey-listing off

Can you explain what is the exact meaning of "spam rewrite_header 
nanana" in your example?

Regars,
Alexey



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 kBILvCSj066359; Mon, 18 Dec 2006 14:57:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBILvCmH066358; Mon, 18 Dec 2006 14:57:12 -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.13.5/8.13.5) with ESMTP id kBILvBoW066334 for <[e-mail]>; Mon, 18 Dec 2006 14:57:12 -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]>; Mon, 18 Dec 2006 21:57:10 +0000
Message-ID: <[e-mail]>
Date: Mon, 18 Dec 2006 21:56:27 +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: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>>Optional tagged arguments can appear in any order, but they must appear 
>>before positional arguments.
>>So if we switch to make the method argument positional, the usage 
>>statement needs to be modified to become:
>>
>>   Usage:  notify 
>>           [":from" string]
>>           [":importance" <"1" / "2" / "3">]
>>           [":options" string-list]
>>           [":message" string]
>>           string    
>>
>
>If you write it as
>
>  <method: string>
>
>it looks much better.
>
I agree.

>But should this start a lengthy discussion
>in the group, then never mind.
>  
>
I would like to hear at least two other opinions in favor of keeping or 
changing the current behavior.



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 kBIGWTr5025130; Mon, 18 Dec 2006 09:32:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBIGWTHD025129; Mon, 18 Dec 2006 09: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 rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBIGWS0T025115 for <[e-mail]>; Mon, 18 Dec 2006 09:32:29 -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]>; Mon, 18 Dec 2006 16:32:28 +0000
Message-ID: <[e-mail]>
Date: Mon, 18 Dec 2006 16:32:03 +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: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
References: <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <1166321279.25106.35.camel@localhost> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

>> Was it discussed at some point that perhaps the arguments should be
>> similar to vacation, with :subject (rather than :message, here)
>
> I don't remember any suggestion to use :subject.
> (There was a suggestion to add :from. This change was done).

:message appears in earlier versions of the draft, which predates me 
taking over the editing.

I need to hear more voices speaking in favor of the change before 
replacing :message with :subject.



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 kBIGRZQc024783; Mon, 18 Dec 2006 09:27:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBIGRZBj024782; Mon, 18 Dec 2006 09:27:35 -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.13.5/8.13.5) with ESMTP id kBIGRXmr024773 for <[e-mail]>; Mon, 18 Dec 2006 09:27:34 -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]>; Mon, 18 Dec 2006 16:27:31 +0000
Message-ID: <[e-mail]>
Date: Mon, 18 Dec 2006 16:26: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: Aaron Stone <[e-mail]>
CC: Michael Haardt <[e-mail]>, [e-mail]
Subject: Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
References: <[e-mail]>	 <[e-mail]> <[e-mail]>	 <[e-mail]> <1166321279.25106.35.camel@localhost>
In-Reply-To: <1166321279.25106.35.camel@localhost>
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>

Aaron Stone wrote:

>On Thu, 2006-12-14 at 20:25 +0000, Alexey Melnikov wrote:
>  
>
>>Michael Haardt wrote:
>>    
>>
>
>  
>
>>>3.1.  Notify Action Syntax and Semantics
>>>
>>>  Usage:  notify ":method" string
>>>          [":from" string]
>>>          [":importance" <"1" / "2" / "3">]
>>>          [":options" string-list]
>>>          [":message" string]
>>> 
>>>
>>>Ok, so the method is required now. Good! But why a tagged argument
>>>instead of a positional argument? I don't mind it being one way or
>>>another, I am just curious.  Do we have required tagged arguments
>>>anywhere else?
>>>      
>>>
>>I just didn't want to remove the tag everywhere in the document, as it 
>>might introduce editorial errors.
>>If people have a strong desire to remove the tag, I can remove it.
>>    
>>
>
>Was it discussed at some point that perhaps the arguments should be
>similar to vacation, with :subject (rather than :message, here)
>
I don't remember any suggestion to use :subject.
(There was a suggestion to add :from. This change was done).

>and the message itself as the only positional argument?
>
This was suggested before, but this wouldn't work, as the argument is 
optional and a positional argument can't be optional.

>Were there arguments
>against something like that? If one reason was that the method argument
>had been the only positional argument, tagging it clears up that issue
>and makes room for the message to be the final untagged argument.
>  
>



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 kBH27jP1092788; Sat, 16 Dec 2006 19:07:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBH27jBd092787; Sat, 16 Dec 2006 19:07: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.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBH27iZ2092777 for <[e-mail]>; Sat, 16 Dec 2006 19:07:44 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.164] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 713056024E45; Sat, 16 Dec 2006 18:07:43 -0800 (PST)
Subject: Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Michael Haardt <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Sat, 16 Dec 2006 18:07:59 -0800
Message-Id: <1166321279.25106.35.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.2.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2006-12-14 at 20:25 +0000, Alexey Melnikov wrote:
> Michael Haardt wrote:

> >3.1.  Notify Action Syntax and Semantics
> >
> >   Usage:  notify ":method" string
> >           [":from" string]
> >           [":importance" <"1" / "2" / "3">]
> >           [":options" string-list]
> >           [":message" string]
> >  
> >
> >Ok, so the method is required now. Good! But why a tagged argument
> >instead of a positional argument? I don't mind it being one way or
> >another, I am just curious.  Do we have required tagged arguments
> >anywhere else?
> >
> I just didn't want to remove the tag everywhere in the document, as it 
> might introduce editorial errors.
> If people have a strong desire to remove the tag, I can remove it.

Was it discussed at some point that perhaps the arguments should be
similar to vacation, with :subject (rather than :message, here) and the
message itself as the only positional argument? Were there arguments
against something like that? If one reason was that the method argument
had been the only positional argument, tagging it clears up that issue
and makes room for the message to be the final untagged argument.

Aaron



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 kBFEqEVR093574; Fri, 15 Dec 2006 07:52:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBFEqE1h093573; Fri, 15 Dec 2006 07:52:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBFEqDZP093557 for <[e-mail]>; Fri, 15 Dec 2006 07:52:13 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.55.147] (helo=mx4.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.62) (envelope-from <[e-mail]>) id 1GvEPz-0003SP-Ug for [e-mail]; Fri, 15 Dec 2006 15:52:11 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:51969) by mx4.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1GvEPz-0007Vt-Lg for [e-mail]; Fri, 15 Dec 2006 15:52:11 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1GvEPz-0001pq-83 for [e-mail]; Fri, 15 Dec 2006 15:52:11 +0100
Date: Fri, 15 Dec 2006 15:52:11 +0100
To: [e-mail]
Subject: Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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>

> Optional tagged arguments can appear in any order, but they must appear 
> before positional arguments.
> So if we switch to make the method argument positional, the usage 
> statement needs to be modified to become:
>
>    Usage:  notify 
>            [":from" string]
>            [":importance" <"1" / "2" / "3">]
>            [":options" string-list]
>            [":message" string]
>            string

If you write it as

  <method: string>

it looks much better.  But should this start a lengthy discussion
in the group, then never mind.

> How about:
>
>    If the notification method is capable of transmitting a timestamp outside
>    the textual message, it SHOULD include the timestamp.
> ?
>
> But I am also thinking that implementations may include the timestamp in 
> the textual message, if one is not specified. So maybe "outside the 
> textual message" should be dropped.

I suggest to keep the SHOULD on timestamps as message properties, and
not say anything else.  SMS, for example, do not have timestamps really.
At least I don't see the timestamp of delivery to the SMSC, but of
delivery to the cell phone.  People will be of different opinion on
preferring a timestamp inside the SMS text.  I can't even agree upon
recommending to include one.

> I think the security consideration is generally applicable to a wide 
> range of notification mechanisms, but the second quoted sentence can be 
> changed to start with "For example, ..."?

As long as we don't agree on how to resolve the issue for mailto,
I suggest to avoid it as example.  If you need an example of loops,
consider mails triggering SMS that cause phone calls, which when
being absent cause mails.

Michael



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 kBEKQCjd071280; Thu, 14 Dec 2006 13:26:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEKQCut071279; Thu, 14 Dec 2006 13:26:12 -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.13.5/8.13.5) with ESMTP id kBEKQAm2071272 for <[e-mail]>; Thu, 14 Dec 2006 13:26:11 -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]>; Thu, 14 Dec 2006 20:26:09 +0000
Message-ID: <[e-mail]>
Date: Thu, 14 Dec 2006 20:25:59 +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: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>Sorry for not responding earlier on this, but the end of the year is
>always a real busy time.  I did not review the draft in depth _this time_,
>but wanted to make at least a few comments on reading it quickly:
>
Michael,
Thanks for the review!

>
>Abtract
>
>   This document does not specify the notification
>   method but is expected that using existing instant messaging  
>
I think the word "it" is missing before "is expected".

I've also deleted Zephyr and replaced Jabber with XMPP.

>   infrastructure such as Zephyr, Jabber, or SMS messages will be
>   popular.
>
>This sentence sounds wrong to me, but I am not a native speaker.
>
>3.1.  Notify Action Syntax and Semantics
>
>   Usage:  notify ":method" string
>           [":from" string]
>           [":importance" <"1" / "2" / "3">]
>           [":options" string-list]
>           [":message" string]
>  
>
>Ok, so the method is required now. Good! But why a tagged argument
>instead of a positional argument? I don't mind it being one way or
>another, I am just curious.  Do we have required tagged arguments
>anywhere else?
>
I just didn't want to remove the tag everywhere in the document, as it 
might introduce editorial errors.
If people have a strong desire to remove the tag, I can remove it.

Optional tagged arguments can appear in any order, but they must appear 
before positional arguments.
So if we switch to make the method argument positional, the usage 
statement needs to be modified to become:

   Usage:  notify 
           [":from" string]
           [":importance" <"1" / "2" / "3">]
           [":options" string-list]
           [":message" string]
           string

>3.5.  Notify tag ":options"
>
>   Each string in the options string list has the following syntax:
>   "<optionname>=<value>" [[Alexey 3: Should we say something about
>   implementation prefix for implementation specific options?  Something
>   like "x-Vendor-zzz".  If we don't say it now, it might be too late to
>   say it later.]]
>
>Each method will specify used options, and adding anything, no matter
>how it is named, is not going to be portable.  To me, dividing the name
>space makes sense if having a registry for it, but I consider that to
>be overkill for option strings.  We don't have a registry for envelope
>key strings either, and I don't think we need one.
>
Yes, I don't think we are going to have very many envelope key strings.

Unless I hear some objections, I will take my comment out before 
requesting publication of the document.

>
>3.8.  Requirements on notification methods specifications
>
>   It is RECOMMENDED that a timestamp be included in the notification.
>
>To me, that is not a requirement on the method. How about putting that
>in section 3.6? Or do I get something completely wrong here and you
>talk about a property of notification messages, not their message?
>  
>
Mostly the latter.

>If so, I suggest:
>
>   If the notification method allows to transmit a timestamp outside
>   the textual message, it is RECOMMENDED to include it.
>  
>
How about:

   If the notification method is capable of transmitting a timestamp outside
   the textual message, it SHOULD include the timestamp.
?

But I am also thinking that implementations may include the timestamp in 
the textual message, if one is not specified. So maybe "outside the 
textual message" should be dropped.

>7.  Security Considerations
>
>   Notifications can result in loops and bounces.  In particular, a
>   notification to an email address will not contain necessary Received
>   header fields that might be otherwise used to prevent mail loops.
>   All notification methods must take care to provide mechanisms for
>   avoiding notification loops.
>
>Did we decide on that yet? I vote to leave issues specific to "mailto"
>out of this spec.
>  
>
I think the security consideration is generally applicable to a wide 
range of notification mechanisms, but the second quoted sentence can be 
changed to start with "For example, ..."?

>All in all, the draft is fine with me.  Despite my comments, I don't
>object the last call as it is.
>  
>
Great :-).



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 kBEEPB9i028417; Thu, 14 Dec 2006 07:25:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBEEPB7X028416; Thu, 14 Dec 2006 07:25:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBEEPALA028408 for <[e-mail]>; Thu, 14 Dec 2006 07:25:10 -0700 (MST) (envelope-from [e-mail])
Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.62) (envelope-from <[e-mail]>) id 1GurWG-0000oL-W5 for [e-mail]; Thu, 14 Dec 2006 15:25:09 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]:52759) by mx3.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.62 #12) id 1GurWG-0006WZ-M9 for [e-mail]; Thu, 14 Dec 2006 15:25:08 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.62 #12) id 1GurWF-00013o-PG for [e-mail]; Thu, 14 Dec 2006 15:25:07 +0100
Date: Thu, 14 Dec 2006 15:25:07 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: Working Group Last Call on draft-ietf-sieve-notify-05.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sorry for not responding earlier on this, but the end of the year is
always a real busy time.  I did not review the draft in depth _this time_,
but wanted to make at least a few comments on reading it quickly:

Abtract

   This document does not specify the notification
   method but is expected that using existing instant messaging
   infrastructure such as Zephyr, Jabber, or SMS messages will be
   popular.

This sentence sounds wrong to me, but I am not a native speaker.

3.1.  Notify Action Syntax and Semantics

   Usage:  notify ":method" string
           [":from" string]
           [":importance" <"1" / "2" / "3">]
           [":options" string-list]
           [":message" string]

Ok, so the method is required now. Good! But why a tagged argument
instead of a positional argument? I don't mind it being one way or
another, I am just curious.  Do we have required tagged arguments
anywhere else?

3.5.  Notify tag ":options"

   Each string in the options string list has the following syntax:
   "<optionname>=<value>" [[Alexey 3: Should we say something about
   implementation prefix for implementation specific options?  Something
   like "x-Vendor-zzz".  If we don't say it now, it might be too late to
   say it later.]]

Each method will specify used options, and adding anything, no matter
how it is named, is not going to be portable.  To me, dividing the name
space makes sense if having a registry for it, but I consider that to
be overkill for option strings.  We don't have a registry for envelope
key strings either, and I don't think we need one.

3.8.  Requirements on notification methods specifications

   It is RECOMMENDED that a timestamp be included in the notification.

To me, that is not a requirement on the method. How about putting that
in section 3.6? Or do I get something completely wrong here and you
talk about a property of notification messages, not their message?
If so, I suggest:

   If the notification method allows to transmit a timestamp outside
   the textual message, it is RECOMMENDED to include it.

7.  Security Considerations

   Notifications can result in loops and bounces.  In particular, a
   notification to an email address will not contain necessary Received
   header fields that might be otherwise used to prevent mail loops.
   All notification methods must take care to provide mechanisms for
   avoiding notification loops.

Did we decide on that yet? I vote to leave issues specific to "mailto"
out of this spec.

All in all, the draft is fine with me.  Despite my comments, I don't
object the last call as it is.

Michael



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 kBDBfaj9030469; Wed, 13 Dec 2006 04:41:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDBfaeU030467; Wed, 13 Dec 2006 04:41:36 -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 ([e-mail] [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDBfYgG030450 for <[e-mail]>; Wed, 13 Dec 2006 04:41:35 -0700 (MST) (envelope-from [e-mail])
Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1GuSUP-0001em-7L; Wed, 13 Dec 2006 12:41:33 +0100
Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id kBDBfaKT019515; Wed, 13 Dec 2006 11:41:36 GMT
Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id kBDBfZMl019514; Wed, 13 Dec 2006 12:41:35 +0100
X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to [e-mail] using -f
Received: from rz-h-261.stud.uni-karlsruhe.de (rz-h-261.stud.uni-karlsruhe.de [172.21.71.123]) by mail.aegee.org (Horde MIME library) with HTTP; Wed, 13 Dec 2006 12:41:35 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Dec 2006 12:41:35 +0100
From: Dilyan Palauzov <[e-mail]>
To: [e-mail], [e-mail]
Subject: sieve for spamfiltering and greylisting
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-Virus-Scanned: ClamAV 0.88.7/2315/Mon Dec 11 09:55:24 2006 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBDBfZgG030457
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,
   What happens with a mail between the end MTA and the mailbox? First  
(optionally) greylisting, then (optionally) spamfiltering and at the  
end )optionally) sieve-filtering. All this (optional) steps could be  
up to the user to be configured, hence each of them requires different  
interface:
   - one interface for conf. the personal grey listing
   - one interface for configuring the personal spam settings and
   - managesieve for configuring the personal filters.

   It is a bit cumbersome, as all these settings are related to the  
same thing (mail delivery from the users' point of view), but setting  
them up requires different approaches.

   Maybe you have discussed it already, but recently I was thinking on  
uniting all this settings into one. And my idea concrete is either to  
extend sieve to support settings for external programmes or to define  
sieve extensions per purpose (hence one extension for both configuring  
spamassassin and dspam). In the first case just the name of the  
programme will need to be specified and it will be able to define what  
will happen afterwards with the parameters (and be able to get them  
from the script), e.g
   require "prog";
   prog grey-listing 10 30
   (meaning that the mail shall be retried not later than 30 minutes  
and not earlier than the next 10 minutes, in order to pass the  
grey-filtering, or wise-versa - it will be up to the interpreting  
programme)
   prog spamassassin rewrite_header nanana

or in the second case we define a keyword per purpose, the sample  
sieve script could look like

   require "spam", "grey-listing"
   spam rewrite_header nanana
   grey-listing off

   Where the meaning of spam rewrite_header and/or grey-listing off is  
defined by a sieve extension/capability.

  That's all, I just wanted to share the idea. Of course such an  
approach would require the management of several other applications,  
but at the same time it supposes for the future even wider support for  
sieve, both in the spam-programmes and in the tools for managing  
settings. Actually my initial idea was to extend managesieve to upload  
the settings for different applications - once for sieve, once for  
spam-settings, but later I thought it would be better to alter the  
language itself.
   Greetings,
     Dilian



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 kBDBfaUT030468; Wed, 13 Dec 2006 04:41:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBDBfaXU030466; Wed, 13 Dec 2006 04:41:36 -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 ([e-mail] [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBDBfYjR030449 for <[e-mail]>; Wed, 13 Dec 2006 04:41:35 -0700 (MST) (envelope-from [e-mail])
Received: from aegeeserv.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1GuSUP-0001em-7L; Wed, 13 Dec 2006 12:41:33 +0100
Received: from AEGEEserv.aegee.uni-karlsruhe.de (localhost [127.0.0.1]) by aegeeserv.aegee.org (8.13.8/8.13.6) with ESMTP id kBDBfaKT019515; Wed, 13 Dec 2006 11:41:36 GMT
Received: (from wwwrun@localhost) by AEGEEserv.aegee.uni-karlsruhe.de (8.13.8/8.13.6/Submit) id kBDBfZMl019514; Wed, 13 Dec 2006 12:41:35 +0100
X-Authentication-Warning: AEGEEserv.aegee.uni-karlsruhe.de: wwwrun set sender to [e-mail] using -f
Received: from rz-h-261.stud.uni-karlsruhe.de (rz-h-261.stud.uni-karlsruhe.de [172.21.71.123]) by mail.aegee.org (Horde MIME library) with HTTP; Wed, 13 Dec 2006 12:41:35 +0100
Message-ID: <[e-mail]>
Date: Wed, 13 Dec 2006 12:41:35 +0100
From: Dilyan Palauzov <[e-mail]>
To: [e-mail], [e-mail]
Subject: sieve for spamfiltering and greylisting
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) H3 (4.1.3)
X-Virus-Scanned: ClamAV 0.88.7/2315/Mon Dec 11 09:55:24 2006 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kBDBfZjR030456
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,
   What happens with a mail between the end MTA and the mailbox? First  
(optionally) greylisting, then (optionally) spamfiltering and at the  
end )optionally) sieve-filtering. All this (optional) steps could be  
up to the user to be configured, hence each of them requires different  
interface:
   - one interface for conf. the personal grey listing
   - one interface for configuring the personal spam settings and
   - managesieve for configuring the personal filters.

   It is a bit cumbersome, as all these settings are related to the  
same thing (mail delivery from the users' point of view), but setting  
them up requires different approaches.

   Maybe you have discussed it already, but recently I was thinking on  
uniting all this settings into one. And my idea concrete is either to  
extend sieve to support settings for external programmes or to define  
sieve extensions per purpose (hence one extension for both configuring  
spamassassin and dspam). In the first case just the name of the  
programme will need to be specified and it will be able to define what  
will happen afterwards with the parameters (and be able to get them  
from the script), e.g
   require "prog";
   prog grey-listing 10 30
   (meaning that the mail shall be retried not later than 30 minutes  
and not earlier than the next 10 minutes, in order to pass the  
grey-filtering, or wise-versa - it will be up to the interpreting  
programme)
   prog spamassassin rewrite_header nanana

or in the second case we define a keyword per purpose, the sample  
sieve script could look like

   require "spam", "grey-listing"
   spam rewrite_header nanana
   grey-listing off

   Where the meaning of spam rewrite_header and/or grey-listing off is  
defined by a sieve extension/capability.

  That's all, I just wanted to share the idea. Of course such an  
approach would require the management of several other applications,  
but at the same time it supposes for the future even wider support for  
sieve, both in the spam-programmes and in the tools for managing  
settings. Actually my initial idea was to extend managesieve to upload  
the settings for different applications - once for sieve, once for  
spam-settings, but later I thought it would be better to alter the  
language itself.
   Greetings,
     Dilian



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 kB93XMWN067201; Fri, 8 Dec 2006 20:33:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB93XMp2067200; Fri, 8 Dec 2006 20:33:22 -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 (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB93XKl8067192 for <[e-mail]>; Fri, 8 Dec 2006 20:33:21 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 8 Dec 2006 19:33:17 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1165635196; h=Date: 	 From:Subject:MIME-version:Content-type; b=cykR6u7SWZHwZQWjhEQMe0So2 NQB4AtGzfLCZ8U/2zf9bSccJQD3hfre/TKcfvCtlTB4q5i9tJYAP8kT9VdyiA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 08 Dec 2006 19:33:15 -0800 (PST)
Cc: Mark E Mallett <[e-mail]>, Cyrus Daboo <[e-mail]>, SIEVE <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 08 Dec 2006 19:31:06 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: WGLC: draft-ietf-sieve-editheader-07.txt
In-reply-to: "Your message dated Thu, 07 Dec 2006 15:30:27 +0000" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> But in ideal world we don't want to have partially executed scripts. The
> text in 3028bis is describing real world and is much more liberal than I
> would like it to be.

> For debugging of a Sieve script it is much better to know in which state
> the saved message is. So using the original message (before any
> partially applied header changes) seems to be the best.

I agree with this analysis. Our implementation could have handled the
attachment of header information in the event of an error either way without
too much trouble, but I think what the draft describes is the correct approach.

				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 kB7FV22H026310; Thu, 7 Dec 2006 08:31:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7FV2iw026309; Thu, 7 Dec 2006 08:31:02 -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.13.5/8.13.5) with ESMTP id kB7FV1xL026299 for <[e-mail]>; Thu, 7 Dec 2006 08:31:02 -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]>; Thu, 7 Dec 2006 15:31:00 +0000
Message-ID: <[e-mail]>
Date: Thu, 07 Dec 2006 15:30:27 +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: "Mark E. Mallett" <[e-mail]>
CC: Cyrus Daboo <[e-mail]>, SIEVE <[e-mail]>
Subject: Re: WGLC: draft-ietf-sieve-editheader-07.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mark E. Mallett wrote:

>>5. Interaction with Other Sieve Extensions
>>    
>>
>I guess I didn't notice when the first paragraph here got added in;
>looks from the change history that it was in -05.  (If it's too late for
>this comment, so be it.)  This part:
>  
>
>>   Actions that generate [MDN], [DSN], or similar disposition
>>   messages MUST do so using the original, unmodified message header.
>>    
>>
>is the correct thing to do (even though it will give me something
>to do to fix the way my code behaves).  But:
>  
>
>>   Similarly, if an error terminates processing of the script, the
>>   original message header MUST be used when doing the implicit
>>   keep required by [SIEVE] section 2.10.6.
>>    
>>
>It looks like the reference to 2.10.6 is simply to justify the implicit
>keep, and not the behavior of keeping the original message header.
>Still, I can't help but think that that behavior is not in the spirit of
>2.10.6, which which says (among other things) that implementations may
>choose whether to iteratively parse/execute until an error, in which
>case "some actions happen, others don't."  This seems to me to be the
>opposite of justifying undoing already-executed actions when performing
>implicit keep.
>
>Of course, maybe I am reading it that way because I want to, since I
>have a hard time understanding why anybody would want this.  If
>addheader/deleteheader succeed, it seems to me that a script writer
>would expect the kept copy to have the results of the script actions
>that had succeeded.
>
But in ideal world we don't want to have partially executed scripts. The 
text in 3028bis is describing real world and is much more liberal than I 
would like it to be.

For debugging of a Sieve script it is much better to know in which state 
the saved message is. So using the original message (before any 
partially applied header changes) seems to be the best.

>  One might want the unaltered headers in order to
>debug the failing script, but that's a different thing.
>  
>



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 kB7FAu8U021873; Thu, 7 Dec 2006 08:10:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7FAucx021872; Thu, 7 Dec 2006 08:10:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7FAt0p021866 for <[e-mail]>; Thu, 7 Dec 2006 08:10:56 -0700 (MST) (envelope-from [e-mail])
Received: from [17.101.35.156] ([17.101.35.156]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kB7FAn88023839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 7 Dec 2006 10:10:52 -0500
Date: Thu, 07 Dec 2006 10:10:44 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Determinging consensus on reject
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.7b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled  version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
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,
With my chair hat on:

The debate on reject seems to have died down but we need to make progress 
on this. Here is my reading of the consensus from this discussion:

1) As per discussions during IETF meeting, there is broad consensus for 
having two commands: "reject" and "ereject".

2) As per list discussions its clear that many implementers need to 
maintain the current "reject" behavior of allowing MDNs as they are useful 
in many cases, even though they appear to be harmful wrt spam blowback.

The proposal as defined by my reading of the consensus then is as follows:

1) Current "reject" command stays as-is. Server implementations MAY (at 
their discretion) use a protocol level reject if the reject text is only 
ASCII, but MUST use MDN when it contains non-ascii.

2) A new "ereject" command is introduced. This MUST do a protocol level 
reject. The text argument MAY contain non-ASCII text which MUST be suitably 
downgraded if the protocol level reject can only handle ASCII text.

The spec should also contain guidance on the use of each. In particular: 
"script generators SHOULD ensure that a rejection action being executed as 
a result of an anti-spam or anti-virus positive test be done using the 
ereject action". Also there should be guidance on "upgrading" existing 
scripts to use ereject instead of reject when appropriate as new sieve 
implementations are rolled out. There should also be a note about the fact 
that in some environments (e.g. MUAs) a protocol level reject cannot be 
done, in which case the ereject action will not be available, and reject 
will alsways end up doing MDNs, not matter what.

-- 
Cyrus Daboo



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 kB7F8Pkq021374; Thu, 7 Dec 2006 08:08:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB7F8PFI021373; Thu, 7 Dec 2006 08:08:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB7F8OPS021367 for <[e-mail]>; Thu, 7 Dec 2006 08:08:25 -0700 (MST) (envelope-from [e-mail])
Received: from [17.101.35.156] ([17.101.35.156]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id kB7F8AsG023829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 7 Dec 2006 10:08:18 -0500
Date: Thu, 07 Dec 2006 10:08:04 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Last calls on editheader and body
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.0.7b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled  version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  piper.mulberrymail.com
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,
Just a reminder that the last calls on the editheader and body drafts end 
tomorrow. The purpose of the current last call is to verify that these 
specs are consistent with the recent changes to the 3028bis document. We 
need to get confirmation from you that this is the case so that we can move 
forward and submit these to the IESG along with the 3028bis document. So 
please send a positive or negative indictor to the list or the chairs, 
thanks.

-- 
Cyrus Daboo



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 kB78m2g2074145; Thu, 7 Dec 2006 01:48:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB78m23U074138; Thu, 7 Dec 2006 01:48:02 -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 (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB78lxjR074059 for <[e-mail]>; Thu, 7 Dec 2006 01:48:02 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.185] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 48928601890A; Thu,  7 Dec 2006 00:47:58 -0800 (PST)
Subject: Re: Future directions for the ManageSieve draft
From: Aaron Stone <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> ,            <[e-mail]> <[e-mail]> ,            <[e-mail]> <[e-mail]> ,            <[e-mail]> <[e-mail]> , <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Thu, 07 Dec 2006 00:48:07 -0800
Message-Id: <1165481287.24995.75.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.8.2.1 
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2006-12-05 at 19:07 +0000, Aaron Stone wrote:
> On Tue, Dec 5, 2006, Alexey Melnikov <[e-mail]> said:
> 
> > Aaron Stone wrote:
> > 
> >>>>The only things on my mind are how to specify scripts for IMAP actions and
> >>>>for MTA/MDA actions. Given the discussion on the recent thread about
> >>>>multiscript, there are a lot of multiscript implementations! I would
> >>>>certainly prefer to manage my multiscripts via ManageSieve.
> [snip]
> >>Is this something we might want to tackle in the base document by adding
> >>the option for arguments following script names in relevant actions?
> >>
> > I am not entirely sure what you recommend. Can you give an example?
> 
> I'll get back to you on this. I need to find some time to distill the
> recent thread about multiscript and take another look at IMAP Sieve.

Ok, here's what I'm thinking. In IMAP-SIEVE we have this section:

2.3.  New Functions Defined by IMAPSieve

2.3.1.  Changes to Manage Sieve

   [[Manage Sieve placeholder: This section is a placeholder right now,
   for changes to the Manage Sieve protocol.  We'll fill in more detail
   on the next iteration of this draft.]]

   Manage Sieve [Manage] is a protocol for managing Sieve scripts.  We
   define here an extension to that protocol to support multiple active
   scripts, each serving a different function.  The extension here will
   allow us to tell the IMAP server which script to use for which
   mailbox(es) for the conditions described in this document.  No Sieve
   script is invoked for an IMAP condition unless Manage Sieve has
   defined a script for it, and has "turned on" filtering for a
   particular mailbox or set of mailboxes.

Well, let's hack into it!

We need a few new actions:

LISTSCRIPTSEXT an extended version of LISTSCRIPTS that allows additional
atoms following the script names. The base spec only gives the ACTIVE
atom. Since it doesn't suggest that there might be other atoms, it's
entirely possible that implementations will explode if we just tossed
more atoms on the regular LISTSCRIPTS.

Atoms: ACTIVE, GLOBAL, ACT-IMAP-APPEND, ACT-IMAP-MULTIAPPEND,
ACT-IMAP-COPY, SMTP-THIS, SMTP-THAT [[since we've never had a Sieve SMTP
draft, have we?]]

Anyways, these additional atoms should correspond to the IMAP actions
that trigger a Sieve script and to the SMTP actions / delivery processes
that trigger a script in a multiscript delivery path.

SETACTIVEEXT an extended version of SETACTIVE that takes optional
arguments for the location of the script and the trigger.

e.g.:
    SETACTIVEEXT [trigger-atom] [GLOBAL] "scriptname"

and by extension:
   DELETESCRIPTEXT [GLOBAL] "scriptname"
   PUTSCRIPTEXT [GLOBAL] "scriptname"
   GETSCRIPTEXT [GLOBAL] "scriptname"

Ok, some rough ideas, but getting them out there.

Aaron



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 kB6LG11e004678; Wed, 6 Dec 2006 14:16:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6LG1b5004677; Wed, 6 Dec 2006 14:16:01 -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 (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB6LG1w1004670 for <[e-mail]>; Wed, 6 Dec 2006 14:16:01 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id 41A3160006B5; Wed,  6 Dec 2006 13:16:00 -0800 (PST)
Date: Wed, 6 Dec 2006 21:16:00 -0000
To: "Mark E. Mallett" <[e-mail]>
Subject: Re: draft-ietf-sieve-3028bis-09
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Cc: <[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>

On Wed, Dec 6, 2006, "Mark E. Mallett" <[e-mail]> said:

>> 4.2.     Action redirect
>> 
>>    Usage:   redirect <address: string>
>> 
>>    The "redirect" action is used to send the message to another user at
>>    a supplied address, as a mail forwarding feature does.  The
>>    "redirect" action makes no changes to the message body or existing
>>    headers, but it may add new headers.  The "redirect" modifies the
>>    envelope recipient.
> 
> a) 'The "redirect" action modifies' rather than 'The "redirect" modifies'.
> (or remove the quotes, i.e. 'The redirect modifies'.)
> 
> b) I know what the writer meant, but I don't think it's clear.  The
> action doesn't really modify the envelope recipient.  i.e., a subsequent
> test of 'envelope "to"' should still show the original envelope
> recipient.  The text says to me that it won't.  I think what's meant is
> that a new message is created which has a new envelope recipient.

I thought a couple of clarifying sentences were added. I've copied the
fully section from 3028bis-09 here:

4.2.     Action redirect

   Usage:   redirect <address: string>

   The "redirect" action is used to send the message to another user at
   a supplied address, as a mail forwarding feature does.  The
   "redirect" action makes no changes to the message body or existing
   headers, but it may add new headers.  The "redirect" modifies the
   envelope recipient.

   The redirect command performs an MTA-style "forward"--that is, what
   you get from a .forward file using sendmail under UNIX.  The address
   on the [SMTP] envelope is replaced with the one on the redirect
   command and the message is sent back out.  (This is not an MUA-style
   forward, which creates a new message with a different sender and
   message ID, wrapping the old message in a new one.)

>>> I still think the casual reference to sendmail should be removed, and a more explicit explanation of what it means to forward mail should be given. I believe it was Ned who replied to me a while ago that there isn't really a "Best Practices of MTA Forwarding" document in existence. Casually referencing what is becoming increasingly archaic unix software behavior isn't exactly referencing best practices IMHO.

   The envelope sender address on the outgoing message is chosen by the
   sieve implementation.  It MAY be copied from the original message.

>>> Didn't we add a few sentences here, per comment above?

   A simple script can be used for redirecting all mail:

   Example:  redirect "[e-mail]";

   Implementations SHOULD take measures to implement loop control,
   possibly including adding headers to the message or counting received
   headers.  If an implementation detects a loop, it causes an error.

Aaron



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 kB6JjrTK094839; Wed, 6 Dec 2006 12:45:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB6JjrZj094838; Wed, 6 Dec 2006 12:45:53 -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.13.5/8.13.5) with SMTP id kB6JjqAw094830 for <[e-mail]>; Wed, 6 Dec 2006 12:45:53 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 98266 invoked by uid 101); 6 Dec 2006 14:45:51 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 6 Dec 2006 14:45:51 -0500
To: IETF mta-filters list <[e-mail]>
Subject: draft-ietf-sieve-3028bis-09
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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,

I was going over 3028bis-09 last night for a reread, and had a few
observations.  I realize that it's way past last call on this, and also
that one can never completely win (since things can be found on any new
reading.)  Then again, there have been comments since the drop-dead date
(like the non-negative vs positive numbers thing), and then again again,
I have these notes and nowhere to put them (that's not a setup line).

Ignore at will..



> 2.4.2.2. Headers
 ...
>    Similarly, synactically invalid header names cause the same result as

"synactically" should be "syntactically"



> 2.8.     Blocks
> 
>    Blocks are sets of commands enclosed within curly braces and supplied
>    as the final argument to a command.  Such a command is a control
>    structure: when executed it has control over the number of times the
>    commands in the block are executed.  and how

".  and how" ?  (dangling words)


> 3.3.     Control Stop
> 
>    Usage:   stop
> 
>    The "stop" action ends all processing.  If no actions have been
>    executed, then the keep action is taken.

While that's correct, it's not really inclusive enough.  I think the
point is that the implicit keep should still be taken if it is
outstanding-- NOT just subject to whether or not any actions have been
taken.   i.e., "If the implicit keep has not been cancelled, it is
taken."



> 4.2.     Action redirect
> 
>    Usage:   redirect <address: string>
> 
>    The "redirect" action is used to send the message to another user at
>    a supplied address, as a mail forwarding feature does.  The
>    "redirect" action makes no changes to the message body or existing
>    headers, but it may add new headers.  The "redirect" modifies the
>    envelope recipient.

a) 'The "redirect" action modifies' rather than 'The "redirect" modifies'.
(or remove the quotes, i.e. 'The redirect modifies'.)

b) I know what the writer meant, but I don't think it's clear.  The
action doesn't really modify the envelope recipient.  i.e., a subsequent
test of 'envelope "to"' should still show the original envelope
recipient.  The text says to me that it won't.  I think what's meant is
that a new message is created which has a new envelope recipient.



> 4.3.     Action keep

I wonder if this oughtn't say that it cancels the implicit keep.


> 5.1.     Test address
 ...
>    Internet email addresses [IMAIL] have the somewhat awkward
>    characteristic that the local-part to the left of the at-sign is
>    considered case sensitive, and the domain-part to the right of the
>    at-sign is case insensitive.  The "address" command does not deal
>    with this itself, but provides the ADDRESS-PART argument for allowing
>    users to deal with it.

I note that this has the same issue as with the mime type test: one
can't do a test of both parts of an address separately since one can't
guarantee that the parts came from the same address.  That is, there
really isn't anything here (without, say, variables) that allows users
to deal with it, except for the case where there is only one address.
I guess I would just put a period after "itself" and remove the rest of
the sentence.


> 5.4.     Test envelope

This section does not say that it requires "envelope" capability.  It is
implied in the example, but not stated.


> 9.      Extended Example

>             # If message header does not contain my address,
>             # it's from a list.

Comment doesn't match code.  Leftover from previous edit?
(has been mentioned before)

>             # Move all other (non-company) mail to "personal"
>             # mailbox.

ditto... 



> 10.     Security Considerations

>    Implementations SHOULD take measures to prevent languages from
>    looping.

I think it means "messages" not "languages"


Yours with apologies,
-mm-



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 kB5LUpfh049483; Tue, 5 Dec 2006 14:30:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5LUp6u049482; Tue, 5 Dec 2006 14:30:51 -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.13.5/8.13.5) with SMTP id kB5LUn0I049445 for <[e-mail]>; Tue, 5 Dec 2006 14:30:50 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32743 invoked by uid 101); 5 Dec 2006 16:30:48 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 5 Dec 2006 16:30:48 -0500
To: Cyrus Daboo <[e-mail]>
Cc: SIEVE <[e-mail]>
Subject: Re: WGLC: draft-ietf-sieve-editheader-07.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>

On Wed, Nov 22, 2006 at 02:37:40PM -0500, Cyrus Daboo wrote:
> 
> Hi folks,
> In light of changes to the base spec since the previous working group last 
> call on the editheader extension, we would like to re-issue the last call 
> on draft-ietf-sieve-editheader-07.txt. Please note that we are "scoping" 
> this last call to only issues related to base spec changes. No new issues 
> will be considered.

Some comments, although it looks like none of them meet the criteria in
those last two sentences.  Take or drop on the floor as you will ..


> 4. Action deleteheader
> 
>    The field-name is mandatory and always matched as a case-insensitive
>    US-ASCII string.  If the field-name is not a valid 7-bit header
>    field name as described by the [IMAIL] "field-name" nonterminal
>    syntax element, the implementation MUST flag an error.  The

There's a dangling "The" there.



> 5. Interaction with Other Sieve Extensions

I guess I didn't notice when the first paragraph here got added in;
looks from the change history that it was in -05.  (If it's too late for
this comment, so be it.)  This part:

>    Actions that generate [MDN], [DSN], or similar disposition
>    messages MUST do so using the original, unmodified message header.

is the correct thing to do (even though it will give me something
to do to fix the way my code behaves).  But:

>    Similarly, if an error terminates processing of the script, the
>    original message header MUST be used when doing the implicit
>    keep required by [SIEVE] section 2.10.6.

It looks like the reference to 2.10.6 is simply to justify the implicit
keep, and not the behavior of keeping the original message header.
Still, I can't help but think that that behavior is not in the spirit of
2.10.6, which which says (among other things) that implementations may
choose whether to iteratively parse/execute until an error, in which
case "some actions happen, others don't."  This seems to me to be the
opposite of justifying undoing already-executed actions when performing
implicit keep.

Of course, maybe I am reading it that way because I want to, since I
have a hard time understanding why anybody would want this.  If
addheader/deleteheader succeed, it seems to me that a script writer
would expect the kept copy to have the results of the script actions
that had succeeded.  One might want the unaltered headers in order to
debug the failing script, but that's a different thing.

Yours,
mm



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 kB5Jd5Vd038226; Tue, 5 Dec 2006 12:39:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5Jd5gC038225; Tue, 5 Dec 2006 12:39:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5Jd47Y038219 for <[e-mail]>; Tue, 5 Dec 2006 12:39:04 -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 <RXXK1wB=[e-mail]>; Tue, 5 Dec 2006 19:39:03 +0000
Message-ID: <[e-mail]>
Date: Tue, 05 Dec 2006 19:38:49 +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: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: Future directions for the ManageSieve draft
References: <[e-mail]>, <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>On Tue, Dec 5, 2006, Alexey Melnikov <[e-mail]> said:
>  
>
>>Aaron Stone wrote:    
>>
>>>Indeed, there are a sufficient number of interoperable implementations
>>>right now that we probably have to treat -06 as written in stone, much
>>>like imapflags vs. imap4flags because the former was so widely deployed.
>>>      
>>>
>>There are many problems with existing clients in handling of strings 
>>(some clients expect only quoted or only literal strings in some places) 
>>and in handling of SASL authentication exchanges when "additional data" 
>>is not sent with "success indicator".
>>This concerns me. ManageSieve interoperability seems to be worse then 
>>IMAP interoperability.
>>    
>>
>
>Ok, I am not sure where to begin tackling this. Is it as simple as "make a
>chart of implementations, and test if they respond correctly to certain
>inputs?"
>
If you or somebody else would want to help with testing interop, that 
would help and would be appreciated.

>What's the usual process for wrangling a spec and implementations like this one?
>  
>
Having implementation experience helps in convincing ADs to publish a 
document, however this is not required for publishing a document as a 
Proposed Standard.
Interop report is needed when moving a document to Draft Standard. But 
we are nowhere nearly there for ManageSieve ;-).



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 kB5J7bUC034377; Tue, 5 Dec 2006 12:07:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5J7b3j034376; Tue, 5 Dec 2006 12:07:37 -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 (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5J7ahC034369 for <[e-mail]>; Tue, 5 Dec 2006 12:07:36 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id 1CDAC60006B5; Tue,  5 Dec 2006 11:07:35 -0800 (PST)
Date: Tue, 5 Dec 2006 19:07:35 -0000
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: Future directions for the ManageSieve draft
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>,            <[e-mail]> <[e-mail]>,            <[e-mail]> <[e-mail]>,            <[e-mail]> <[e-mail]>, <[e-mail]>
Cc: <[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>

On Tue, Dec 5, 2006, Alexey Melnikov <[e-mail]> said:

> Aaron Stone wrote:
> 
>>>>The only things on my mind are how to specify scripts for IMAP actions and
>>>>for MTA/MDA actions. Given the discussion on the recent thread about
>>>>multiscript, there are a lot of multiscript implementations! I would
>>>>certainly prefer to manage my multiscripts via ManageSieve.
[snip]
>>Is this something we might want to tackle in the base document by adding
>>the option for arguments following script names in relevant actions?
>>
> I am not entirely sure what you recommend. Can you give an example?

I'll get back to you on this. I need to find some time to distill the
recent thread about multiscript and take another look at IMAP Sieve.

Aaron



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 kB5IOLgO028165; Tue, 5 Dec 2006 11:24:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5IOLM1028163; Tue, 5 Dec 2006 11:24:21 -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.13.5/8.13.5) with ESMTP id kB5IOKdI028151 for <[e-mail]>; Tue, 5 Dec 2006 11:24:21 -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, 5 Dec 2006 18:24:19 +0000
Message-ID: <[e-mail]>
Date: Tue, 05 Dec 2006 18:24:10 +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: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: Future directions for the ManageSieve draft
References: <[e-mail]>, <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=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>

Aaron Stone wrote:

>On Tue, Dec 5, 2006, Alexey Melnikov <[e-mail]> said:
>  
>
>>Aaron Stone wrote:
>>    
>>
>>>The only things on my mind are how to specify scripts for IMAP actions and
>>>for MTA/MDA actions. Given the discussion on the recent thread about
>>>multiscript, there are a lot of multiscript implementations! I would
>>>certainly prefer to manage my multiscripts via ManageSieve.
>>>      
>>>
>>Sure. This might be one potential candidate.
>>    
>>
>Is this something we might want to tackle in the base document by adding
>the option for arguments following script names in relevant actions?
>  
>
I am not entirely sure what you recommend. Can you give an example?

>>>What about comparators? How are those discovered?
>>>      
>>>
>>The same way as other Sieve extensions, in the SIEVE capability:
>>"IMPLEMENTATION" "Isode M-Box SIEVED server 12.0v0"
>>"SIEVE" "fileinto reject envelope vacation imapflags notify subaddress 
>>copy comparator-i;ascii-numeric relational spamtest refuse regex"
>>"SASL" "PLAIN OTP NTLM LOGIN DIGEST-MD5 CRAM-MD5"
>>    
>>
>Right, ok, so why a new capability section for notify when we could add to
>the existing "SIEVE" block a couple of "notify-method1 notify-method2"
>entries?
>  
>
We could, but notification methods and Sieve extensions names are in 
different namespaces, so in theory, they may conflict.

>Or should we break comparators out, and have responses like:
>
>"SIEVE" "fileinto vacation subaddress envelope relational"
>"COMPARATOR" "i;ascii-numeric"
>  
>
We could, but this would be a change that breaks deployed software ;-).

>"NOTIFY" "email xmpp"
>  
>
<pedantic>"mailto xmpp"</pedantic>

>"SASL" "plain cram-md5"
>  
>



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 kB5HXLHJ022378; Tue, 5 Dec 2006 10:33:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5HXL2i022377; Tue, 5 Dec 2006 10:33:21 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5HXLAv022366 for <[e-mail]>; Tue, 5 Dec 2006 10:33:21 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id A8C5A60006B5; Tue,  5 Dec 2006 09:33:20 -0800 (PST)
Date: Tue, 5 Dec 2006 17:33:20 -0000
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: Future directions for the ManageSieve draft
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>,            <[e-mail]> <[e-mail]>,            <[e-mail]> <[e-mail]>, <[e-mail]>
Cc: <[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>

On Tue, Dec 5, 2006, Alexey Melnikov <[e-mail]> said:

> Aaron Stone wrote:

>>The only things on my mind are how to specify scripts for IMAP actions and
>>for MTA/MDA actions. Given the discussion on the recent thread about
>>multiscript, there are a lot of multiscript implementations! I would
>>certainly prefer to manage my multiscripts via ManageSieve.
>>
> Sure. This might be one potential candidate.

Is this something we might want to tackle in the base document by adding
the option for arguments following script names in relevant actions?

>>What about comparators? How are those discovered?
>>
> The same way as other Sieve extensions, in the SIEVE capability:
> "IMPLEMENTATION" "Isode M-Box SIEVED server 12.0v0"
> "SIEVE" "fileinto reject envelope vacation imapflags notify subaddress 
> copy comparator-i;ascii-numeric relational spamtest refuse regex"
> "SASL" "PLAIN OTP NTLM LOGIN DIGEST-MD5 CRAM-MD5"

Right, ok, so why a new capability section for notify when we could add to
the existing "SIEVE" block a couple of "notify-method1 notify-method2"
entries?

Or should we break comparators out, and have responses like:

"SIEVE" "fileinto vacation subaddress envelope relational"
"COMPARATOR" "i;ascii-numeric"
"NOTIFY" "email xmpp"
"SASL" "plain cram-md5"

> P.S. I was a bit brief in my comments, let me know if you need more 
> detailed explanations from me.

No worries, thanks for the uber-fast reply, too :-)

Aaron



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 kB5HNisS021410; Tue, 5 Dec 2006 10:23:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5HNi8m021409; Tue, 5 Dec 2006 10:23: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.13.5/8.13.5) with ESMTP id kB5HNgDX021397 for <[e-mail]>; Tue, 5 Dec 2006 10:23:43 -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, 5 Dec 2006 17:23:41 +0000
Message-ID: <[e-mail]>
Date: Tue, 05 Dec 2006 17:23:35 +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: Aaron Stone <[e-mail]>
CC: [e-mail]
Subject: Re: Future directions for the ManageSieve draft
References: <[e-mail]>, <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>>>What about future extensions that also need reporting to the user
>>>interface? I think it would be better to make it a generic extension
>>>reporting mechanism.
>>>      
>>>
>>All future ManageSieve extensions will have to be registered with IANA, 
>>so I don't see much point in providing generic syntax.
>>    
>>
>How many are we looking at right now?
>  
>
None at the moment.

>The only things on my mind are how to specify scripts for IMAP actions and
>for MTA/MDA actions. Given the discussion on the recent thread about
>multiscript, there are a lot of multiscript implementations! I would
>certainly prefer to manage my multiscripts via ManageSieve.
>  
>
Sure. This might be one potential candidate.

>What else is in mind? (I'm not trying to use a crystal ball to write all
>extensions into the base spec, just want to get a handle on what we're
>looking at right now.)
>  
>
>>How does this change avoid the API change you've mentioned above?
>>    
>>
>It doesn't. But it does suggest that I shouldn't have a function call
>specific to the notify extensions, but rather generic to a variety of
>extensions.
>  
>
You can still have a generic function, now that you are aware of the 
issue :-)

>What about comparators? How are those discovered?
>
The same way as other Sieve extensions, in the SIEVE capability:
"IMPLEMENTATION" "Isode M-Box SIEVED server 12.0v0"
"SIEVE" "fileinto reject envelope vacation imapflags notify subaddress 
copy comparator-i;ascii-numeric relational spamtest refuse regex"
"SASL" "PLAIN OTP NTLM LOGIN DIGEST-MD5 CRAM-MD5"

>I haven't had time to look at all the Sieve extensions to see which ones have registries,
>
In general Sieve extensions don't need to be specially registered with 
ManageSieve.
All Sieve extensions appear automatically in the "SIEVE" ManageSieve 
capability.

>but I wonder if they each need to have a ManageSieve block.
>
See above.
But even if they do, this can be done in a separate document.

>It also introduces a reference from the extension onto ManageSieve.
>
If registrations are done in a separate document, there is no need to 
have dependencies from the Sieve extension to the ManageSieve document.

>Does that hold up some of the extensions and force a document approval order for the WG?
>
In general, dependencies between document delay publication (after 
approval), until all normatively referenced documents are published.

>What about extensions with registries that are already published?
>  
>
Alexey

P.S. I was a bit brief in my comments, let me know if you need more 
detailed explanations from me.



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 kB5GwapV018504; Tue, 5 Dec 2006 09:58:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5Gwa5Q018503; Tue, 5 Dec 2006 09:58:36 -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 (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB5GwaL2018496 for <[e-mail]>; Tue, 5 Dec 2006 09:58:36 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id 954D660006B5; Tue,  5 Dec 2006 08:58:35 -0800 (PST)
Date: Tue, 5 Dec 2006 16:58:35 -0000
To: "Alexey Melnikov" <[e-mail]>
Subject: Re: Future directions for the ManageSieve draft
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>,            <[e-mail]> <[e-mail]>, <[e-mail]>
Cc: <[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>

On Tue, Dec 5, 2006, Alexey Melnikov <[e-mail]> said:

> Aaron Stone wrote:

>>Indeed, there are a sufficient number of interoperable implementations
>>right now that we probably have to treat -06 as written in stone, much
>>like imapflags vs. imap4flags because the former was so widely deployed.
>>  
> There are many problems with existing clients in handling of strings 
> (some clients expect only quoted or only literal strings in some places) 
> and in handling of SASL authentication exchanges when "additional data" 
> is not sent with "success indicator".
> This concerns me. ManageSieve interoperability seems to be worse then 
> IMAP interoperability.

Ok, I am not sure where to begin tackling this. Is it as simple as "make a
chart of implementations, and test if they respond correctly to certain
inputs?" What's the usual process for wrangling a spec and implementations
like this one?

>>I have two issues with -07, with the way that the NOTIFY extensions are
>>listed. I don't dislike the proposal, but it will necessitate an API
>>change for me,
>>
> Can you elaborate?

I have a function call to return all extensions. I'll need to add an
argument specifying which set of extensions to retrieve.

>>and it entails a normative reference on NOTIFY, doesn't it?
>>  
> By the time ManageSieve document is approved for publication, the NOTIFY 
> extensions should be already published ;-). So I think this is a non issue.

Uh, I've heard that before...

>>What about future extensions that also need reporting to the user
>>interface? I think it would be better to make it a generic extension
>>reporting mechanism.
>>
> All future ManageSieve extensions will have to be registered with IANA, 
> so I don't see much point in providing generic syntax.

How many are we looking at right now?

The only things on my mind are how to specify scripts for IMAP actions and
for MTA/MDA actions. Given the discussion on the recent thread about
multiscript, there are a lot of multiscript implementations! I would
certainly prefer to manage my multiscripts via ManageSieve.

What else is in mind? (I'm not trying to use a crystal ball to write all
extensions into the base spec, just want to get a handle on what we're
looking at right now.)

> How does this change avoid the API change you've mentioned above?

It doesn't. But it does suggest that I shouldn't have a function call
specific to the notify extensions, but rather generic to a variety of
extensions.

What about comparators? How are those discovered? I haven't had time to
look at all the Sieve extensions to see which ones have registries, but I
wonder if they each need to have a ManageSieve block. It also introduces a
reference from the extension onto ManageSieve. Does that hold up some of
the extensions and force a document approval order for the WG? What about
extensions with registries that are already published?

Aaron



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 kB5E7ZFc096975; Tue, 5 Dec 2006 07:07:35 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB5E7Zvg096974; Tue, 5 Dec 2006 07:07:35 -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.13.5/8.13.5) with ESMTP id kB5E7X6K096968 for <[e-mail]>; Tue, 5 Dec 2006 07:07:34 -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, 5 Dec 2006 14:07:11 +0000
Message-ID: <[e-mail]>
Date: Tue, 05 Dec 2006 00:17:32 +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: Aaron Stone <[e-mail]>
CC: Sebastian Hagedorn <[e-mail]>, [e-mail]
Subject: Re: Future directions for the ManageSieve draft
References: <[e-mail]>, <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Aaron Stone wrote:

>On Mon, Dec 4, 2006, Sebastian Hagedorn <[e-mail]> said:
>
>[Alexey wrote:]
>  
>
>>>I've recently submitted draft-martin-managesieve-07.txt. I would like to
>>>get some feedback from people on whether the ManageSieve document should
>>>try to document what is currently deployed, or whether it should be
>>>changed to make ManageSieve more consistent with protocols like IMAP and
>>>ACAP.
>>>
>>>Thoughts?
>>>      
>>>
>>as a user of smartsieve, easysieve, Mulberry and other tools that use 
>>ManagSieve I'd prefer the draft to document what's currently deployed.
>>    
>>
>Indeed, there are a sufficient number of interoperable implementations
>right now that we probably have to treat -06 as written in stone, much
>like imapflags vs. imap4flags because the former was so widely deployed.
>  
>
There are many problems with existing clients in handling of strings 
(some clients expect only quoted or only literal strings in some places) 
and in handling of SASL authentication exchanges when "additional data" 
is not sent with "success indicator".
This concerns me. ManageSieve interoperability seems to be worse then 
IMAP interoperability.

>I have two issues with -07, with the way that the NOTIFY extensions are
>listed. I don't dislike the proposal, but it will necessitate an API
>change for me,
>
Can you elaborate?

>and it entails a normative reference on NOTIFY, doesn't it?
>  
>
By the time ManageSieve document is approved for publication, the NOTIFY 
extensions should be already published ;-). So I think this is a non issue.

>What about future extensions that also need reporting to the user
>interface? I think it would be better to make it a generic extension
>reporting mechanism.
>
All future ManageSieve extensions will have to be registered with IANA, 
so I don't see much point in providing generic syntax.

How does this change avoid the API change you've mentioned above?

Alexey




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 kB4KwJaK076090; Mon, 4 Dec 2006 13:58:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB4KwJZ1076089; Mon, 4 Dec 2006 13:58:19 -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 (IDENT:[e-mail] [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4KwI8K076083 for <[e-mail]>; Mon, 4 Dec 2006 13:58:18 -0700 (MST) (envelope-from [e-mail])
Received: from serendipity.palo-alto.ca.us (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with SMTP id 052C86023EA8; Mon,  4 Dec 2006 12:58:14 -0800 (PST)
Date: Mon, 4 Dec 2006 20:58:14 -0000
To: "Sebastian Hagedorn" <[e-mail]>, "Alexey Melnikov" <[e-mail]>
Subject: Re: Future directions for the ManageSieve draft
From: "Aaron Stone" <[e-mail]>
X-Mailer: TWIG 2.8.2
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Cc: <[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>

On Mon, Dec 4, 2006, Sebastian Hagedorn <[e-mail]> said:

[Alexey wrote:]
>> I've recently submitted draft-martin-managesieve-07.txt. I would like to
>> get some feedback from people on whether the ManageSieve document should
>> try to document what is currently deployed, or whether it should be
>> changed to make ManageSieve more consistent with protocols like IMAP and
>> ACAP.
>>
>> Thoughts?
> 
> as a user of smartsieve, easysieve, Mulberry and other tools that use 
> ManagSieve I'd prefer the draft to document what's currently deployed.

Indeed, there are a sufficient number of interoperable implementations
right now that we probably have to treat -06 as written in stone, much
like imapflags vs. imap4flags because the former was so widely deployed.

I have two issues with -07, with the way that the NOTIFY extensions are
listed. I don't dislike the proposal, but it will necessitate an API
change for me, and it entails a normative reference on NOTIFY, doesn't it?
What about future extensions that also need reporting to the user
interface? I think it would be better to make it a generic extension
reporting mechanism. Text:

OLD: 
    NOTIFY - A space separated list of URI schema parts for supported
    notification methods. This capability MUST be specified if the
    Sieve implementation supports the "enotify" extension
    [NOTIFY].

Proposed:
    Other extensions - For each extension supported by the Sieve
    implementation that defines a registry, an additional capability
    response MUST be returned in the format:
        "ExTenSion" "registryitem1 registryitem2"

This drops the reference to NOTIFY, and gives us a generic mechanism for
future extension registries to be reported to the client.

Aaron



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 kB4IhWfJ057867; Mon, 4 Dec 2006 11:43:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB4IhWBW057866; Mon, 4 Dec 2006 11:43:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4IhUa6057860 for <[e-mail]>; Mon, 4 Dec 2006 11:43:31 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 4 Dec 2006 10:43:21 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1165257801; h=Date: 	 From:Subject:MIME-version:Content-type; b=IhNXnYMnKn/qZyOcppqcCqhh1 KuGf3ONJHeVIpHqKmrriKpxHE1nErzNM+m5zs6mU+BYVebV6UR/4hzHAhiOtA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 04 Dec 2006 10:43:06 -0800 (PST)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Mon, 04 Dec 2006 09:55:28 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Spam blowback from Sieve implementations.
In-reply-to: "Your message dated Mon, 04 Dec 2006 11:36:35 -0500" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
To: Matthew Elvey <[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>

> On 11/30/06 6:08 PM, Ned Freed wrote:
> >> Does anyone think I'm trying to keep the standard from allowing Chris to
> >> do what he wants with Sun's implementation?  If so that HAS BEEN A
> >> MISUNDERSTANDING OF WHAT I'VE PROPOSED.
> >
> > I don't think there's any misunderstanding....

> Ned, you inappropriately referred to the last published draft,

Um, since when it is inappropriate to refer to the last posted draft? We were
discussing the concern raised at the meeting _relating to what's proposed in
the current draft_ and the specifics of the consensus that was reached as to
how to move forward. I was asked to weigh in and clarify Sun's position is _in
regards to the current draft_, I did so and I believe I was very clear that
that was what I was responding to. It was never my intention to offer a direct
response to the proposal that started this thread: Given that we're saying we
cannot change reject behavior I guess I thought it was obvious that a proposal
that leaves reject unchanged is fine with us. Apparently it wasn't obvious so
let me state it explicitly: We're fine with any proposal that leaves reject
unchanged from the behavior specified in RFC 3028. And we may also be OK with
proposals that change reject in some way with optional arguments or whatever;
it depends on the details.

> which is
> NOT the same as the proposal I made in the email that started this
> thread.

And which others are now pushing to tweak in various ways. Keeping track
of all the variations and who's behind what is getting complicated, which
is why I'm trying to be very clear about what we can or cannot do, independent
of any of the ideas we're tossing around.

> See your misunderstanding?  It makes the points you made
> inapplicable.

Again, the points I was trying to make were never intended to be applicable
to the original proposal that started this thread. I should have been clearer
about that.

> On 12/1/06 3:36 PM, Lisa Dusseault wrote:
> > It's not only that.  IF Sun or any  SIEVE implementors were to start
> > using a new, different recommended behavior for REJECT on the basis of
> > a new standard, then when server software gets upgraded to one of
> > these new server implementations, users with existing SIEVE scripts
> > would suddenly start seeing new behavior.  That's not very good for
> > users.

> That's not what I proposed:  The proposal in my email that started this
> thread DOES NOT REQUIRE that the configured behavior of reject change.
> Is any part of that not clear now?

> If a server gets upgraded there's nothing in my proposal that prevents
> the upgrade script from setting the _____ as part of the upgrade, while
> new installations, on the other hand, default to the better behaviour.
> IMO, the harm to users of blowback is greater than the harm Lisa
> mentions.  Do you disagree, Lisa?

I can't speak for Lisa, but I most certainly do disagree. We don't support the
use of reject and MDNs as a means of dealing with spam and viruses (and this is
more or less enforced by our GUI) but we do support use of reject for other
purposes. So the equation "reject via MDN" -> blowback does not compute for us.
And given that's the case, why should our customers be penalized because
someone else has failed to think things through and has used reject and MDNs
inappropriately?

This is not to say that the "attractive nuisance" argument has no merit, but
rather than it is totally trumped by the need for backwards compatibility.

				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 kB4GaaH9039085; Mon, 4 Dec 2006 09:36:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB4GaaP7039084; Mon, 4 Dec 2006 09:36:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4GaZDD039077 for <[e-mail]>; Mon, 4 Dec 2006 09:36:36 -0700 (MST) (envelope-from [e-mail])
Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 7CAF24A364 for <[e-mail]>; Mon,  4 Dec 2006 11:36:35 -0500 (EST)
Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by out1.internal (MEProxy); Mon, 04 Dec 2006 11:36:35 -0500
X-Sasl-enc: JEQEkcTowQnWz2b13gLYWv521JwYUr6gSIOcB51ukDvM 1165250195
Received: from [10.59.1.49] (rrcs-24-39-120-33.nyc.biz.rr.com [24.39.120.33]) by mail.messagingengine.com (Postfix) with ESMTP id 44AD214113; Mon,  4 Dec 2006 11:36:34 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 04 Dec 2006 11:36:35 -0500
From: Matthew Elvey <[e-mail]>
User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Spam blowback from Sieve implementations.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report/>.
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>

On 11/30/06 6:08 PM, Ned Freed wrote:
>> Does anyone think I'm trying to keep the standard from allowing Chris to
>> do what he wants with Sun's implementation?  If so that HAS BEEN A
>> MISUNDERSTANDING OF WHAT I'VE PROPOSED.
>
> I don't think there's any misunderstanding....

Ned, you inappropriately referred to the last published draft, which is 
NOT the same as the proposal I made in the email that started this 
thread.  See your misunderstanding?  It makes the points you made 
inapplicable.

On 12/1/06 3:36 PM, Lisa Dusseault wrote:
> It's not only that.  IF Sun or any  SIEVE implementors were to start 
> using a new, different recommended behavior for REJECT on the basis of 
> a new standard, then when server software gets upgraded to one of 
> these new server implementations, users with existing SIEVE scripts 
> would suddenly start seeing new behavior.  That's not very good for 
> users.
That's not what I proposed:  The proposal in my email that started this 
thread DOES NOT REQUIRE that the configured behavior of reject change.  
Is any part of that not clear now?
If a server gets upgraded there's nothing in my proposal that prevents 
the upgrade script from setting the _____ as part of the upgrade, while 
new installations, on the other hand, default to the better behaviour.   
IMO, the harm to users of blowback is greater than the harm Lisa 
mentions.  Do you disagree, Lisa?







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 kB4C0Iuw001146; Mon, 4 Dec 2006 05:00:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB4C0I6U001145; Mon, 4 Dec 2006 05:00:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.rrz.uni-koeln.de (smtp-out.rrz.uni-koeln.de [134.95.19.53]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB4C0HIX001139 for <[e-mail]>; Mon, 4 Dec 2006 05:00:17 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.uni-koeln.de (lvr5.rrz.uni-koeln.de [134.95.19.103]) by smtp-out.rrz.uni-koeln.de (8.13.7/8.13.7) with ESMTP id kB4C0FiA012983; Mon, 4 Dec 2006 13:00:15 +0100
Received: from tyrion.rrz.uni-koeln.de (tyrion.rrz.uni-koeln.de [134.95.128.1]) by smtp.uni-koeln.de (8.12.11.20060308/8.12.11) with ESMTP id kB4C0Fgd001061; Mon, 4 Dec 2006 13:00:15 +0100
Date: Mon, 04 Dec 2006 13:00:15 +0100
From: Sebastian Hagedorn <[e-mail]>
To: Alexey Melnikov <[e-mail]>
cc: [e-mail]
Subject: Re: Future directions for the ManageSieve draft
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.7b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id kB4C0IIX001140
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,

--On 30. November 2006 15:57:07 +0000 Alexey Melnikov 
<[e-mail]> wrote:

> I've recently submitted draft-martin-managesieve-07.txt. I would like to
> get some feedback from people on whether the ManageSieve document should
> try to document what is currently deployed, or whether it should be
> changed to make ManageSieve more consistent with protocols like IMAP and
> ACAP.
>
> Thoughts?

as a user of smartsieve, easysieve, Mulberry and other tools that use 
ManagSieve I'd prefer the draft to document what's currently deployed.

Cheers, Sebastian
-- 
     .:.Sebastian Hagedorn - RZKR-R1 (Gebäude 52), Zimmer 18.:.
Zentrum für angewandte Informatik - Universitätsweiter Service RRZK
.:.Universität zu Köln / Cologne University - ✆ [phone].:.
                   .:.:.:.Skype: shagedorn.:.:.:.



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 kB2IWJj1078506; Sat, 2 Dec 2006 11:32:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB2IWJd7078505; Sat, 2 Dec 2006 11:32: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.13.5/8.13.5) with ESMTP id kB2IWHXf078498 for <[e-mail]>; Sat, 2 Dec 2006 11:32: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 <[e-mail]>; Sat, 2 Dec 2006 18:32:13 +0000
Message-ID: <[e-mail]>
Date: Sat, 02 Dec 2006 17:26:35 +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: Draft minutes for the Sieve WG meeting in San Diego
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>

Disclaimer: I've created the minutes from the Jabber logs, filling in 
missing pieces from my [failing] memory. I haven't listened to the audio 
recording.
So, please report anything missing or inaccurate.

=============
Thanks to Chris Newman for scribing in Jabber.

The meeting has started with chairs reviewing status of WG documents. 6 
specs are in RFC editor queue blocked on 3028bis.
IETF LC for 3028bis has completed, some comments from Eric Rescorla 
(Security Area review) were received. There is also an ongoing 
discussion on an extension for escaping arbitrary octets in Sieve scripts.

1). Is the base Sieve language Turing complete?
Eric Rescorla's review said that loops can occur in the mail system.
Does that count?

Matthew (remotely): Standards/techniques already limit loops.  Don't 
think we should pretend those don't exist.
Ned: need to mention redirect can cause mail loops, but don't want to go 
into a lot of detail about it.
Philip/Ned: Our intention of Sieve is that it is not Turing complete.  
Although it's may be possible to create something Turing complete with 
certain types of mail loops, that does not change the intention.
Agreement that the intention should be clearly stated in the 3028bis 
document.


Next topic: Sieve Reject/Refuse

Had design team (Randy, Philip, Chris and Alexey) discussion; Alexey 
summarizes outcome: there are use cases where you want to reject over 
protocol if at all possible and lose UTF-8 if necessary, and there are 
use cases where preservation of UTF-8 is paramount.  Want to go back to 
two actions: original reject which does MDNs and preserves UTF-8, the 
other is ereject which tries to reject over protocol.

Randy argued that having 2 separate actions is less confusing to users 
then having an action and a parameter that modifies the behavior.
Room consensus two go with two separate actions.

Matthew: I think having the reject work the way it currently does (as in 
RFC) is a horrible idea. Any objections to having "reject" do the new 
way (over protocol), and "oreject" do the old way?  (OldReject)
Chris doesn't want the behavior of existing reject change, due to 
deployments in certain regions, like Japan. Japanese customers use 
non-ASCII and they wouldn't like behavior change.
Chris also suggests to provide automatic migration from old reject.
Randy: concerned that users read MDNs but not DSNs or protocol rejects.  
Uncomfortable changing the behavior of the existing command.
Matthew: I still want to change the default, common behavior. That was 
the main point of the entire effort of creating the new draft.
Chris: When it comes to changing the behavior of an existing standard, 
there must be rough consensus to change behavior; absent consensus the 
published behavior should stand.

Poll: who currently implement Sieve reject (as described in RFC 3028):
 8 hands raised
Poll: how many can change there implementations to do protocol level 
refusal:
 The same 8 hands raised. However this still doesn't guaranty that there 
would be no bounce.

Chairs asked local and remote participants to hum for 3 questions:
Q1: Keep reject as MDN.
Q2: New action for protocol level rejection or MDN
Q3: (optional) Allow reject to do protocol level rejection if ASCII only 
text is supplied.

Q1: who would disagree with keeping reject as is?
(Several people hummed in agreement. Matthew disagreed in Jabber. No 
people disagreed in the room)
Room rough consensus for keeping reject action as MDN.

Q2: Any hums against adding a new action for protocol level reject?
Nobody in the room objected to adding a new action for "protocol level 
rejection or MDN".
Room rough consensus for adding the new action.

Q3: Allow implementations to do protocol level "reject" if text doesn't 
require downgrade?
(Wishy-washy in favor, no opposed. The hum was not as strong as on the 
first 2 questions)
Room rough consensus for allowing the reject action to do protocol level 
rejection (MAY do protocol level rejection).

Alexey: Matthew and I will do a new update by December.


Next topic: "MIME Loops" document. New revision got published: 
draft-ietf-sieve-mime-loop-01.txt.
Major changes: header/address/exists tests now has a new :mime parameter.
Things to be done to the document: fixed various errors in examples, 
better explanation of nesting, IANA registration for Original-* header 
fields,

Q: Should we require that implementations verify that replaced/enclosed 
parts are valid 2822/Mime?
Ned: The vacation document doesn't prescribe this for "vacation :mime".
A: Leave as a quality of implementation issue.

Chris (regarding traversing MIME structure): implementation can descend 
into parts they understand, but MUST descend into multipart/* and 
message/rfc822, and SHOULD NOT descend into text/rfc822-headers.

Chris: it would be nice to be able to parse DSN reports 
(message/delivery-status) in Sieve.
A: DSN information is located in the body of message/delivery-status, 
and thus this is not a task of the MIME loops document. A separate Sieve 
extension can be written to address this.




Next topic: Sieve notify extension

Open issues:
1) :importance - is it a transport thing (i.e. to be used to send the 
notification faster/slower), or just a flag on the notification?

Barry: can be either, depending on a mechanism

2) Mandatory to implement notification method? Will IESG require one?

The subsequent discussion lead the room to the question about why the 
notification method can be optional.

Barry: I think IBM implementation is guilty, as we had a default 
mechanism that would do different things depending on presence.

Subsequent discussion resulted in the feeling that nobody actually likes 
having a default notification method, because it can change when 
replacing one Sieve implementation with another. This will surprise users.

Consensus: make the :method parameter to notify action required

3) Can default behavior in the absence of the :message parameter be 
notification mechanism specific?

Room consensus: Yes, implementations already do that, besides the 
formatting of :message is mechanism specific anyway.

4) Restrict :priority to just three levels?

A: We've previously agreed to have 3 numeric levels, let's not change 
the decision. More levels can be added if needed.

5) IANA registry for :options needs some discussion.

Room consensus: Still no desire to do IANA registration, as there are no 
options registered so far.

6) Changing name of the extension

There were some significant changes between the current draft and the 
one deployed by Sendmail and CMU.
Ned: I think we can detect which version is used by parsing parameters 
to the Notify action
Philip: The principle for Sieve extensions is that _if_ an 
implementation accepts the 'require's that the script contains, _then_ 
the script will be executed with the expected behavior. That rule 
basically means that we can't use the same name for the revision of notify.

Room consensus to change the name of the extension.

7) The room also discussed how loop detection should be done for notify.

Philip has volunteered to work on text for loop detection for notify.
Barry wants a loop prevention mechanism that works across notification 
mechanisms in some way. He will try to work on text.

Alexey: Barry and I will do a new update by December.


Other topics:
RegEx - lack of progress.  If no more progress by this meeting, it 
should be dropped.  So we're thinking about dropping it from our charter
Aaron: What is holding up the RegEx?
Philip: RegEx needs careful thinking about how regular expressions 
interact with comparators

Chairs: When we update the milestones, we will put the RegEx as the very 
last deliverable, maybe it will get done.


Sieve Date extension
Ned: one comment was to change the part parameter from positional to 
tagged.  nobody else in favor, will drop that issue.  New draft adds one 
more test type to get back an RFC822 format.


ManageSIEVE - no update


IMAP Sieve - no update
Lemonade WG depends on it.
Barry - work on IMAP Sieve and Sieve environment.
Alexey: Ned is also looking at doing Sieve environment extension and 
ihave extension, so Barry and Ned need to coordinate.


Discussion of standards dependency and issue on taking Sieve base and 
extensions to Draft Standard.  Proposal to move 2821/2822 to Draft, 
perhaps on a variance because they're better than 821/822 which are Full 
Standards.




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 kB21VJjm002767; Fri, 1 Dec 2006 18:31:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB21VJs8002766; Fri, 1 Dec 2006 18:31:19 -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 (netblock-68-183-106-173.brandx.net [68.183.106.173] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB21VH8Y002752 for <[e-mail]>; Fri, 1 Dec 2006 18:31:18 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 1 Dec 2006 17:31:08 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1165023067; h=Date: 	 From:Subject:MIME-version:Content-type; b=fk9A7cNnFdhbAy3Q2q5S5vsOD QsC5teeNBBCy1bYzx1wqnkI2Qn89M9GKCxYV0MMQXGrJO+L5BU4fUwDeV14sQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 01 Dec 2006 17:31:05 -0800 (PST)
Cc: Aaron Stone <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Date: Fri, 01 Dec 2006 17:16:07 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Sieve include, 'global scripts' and managesieve
In-reply-to: "Your message dated Mon, 27 Nov 2006 15:38:33 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <1164577604.954.26.camel@localhost> <[e-mail]> <1164621549.16051.23.camel@localhost> <[e-mail]>
To: Kjetil Torgrim Homme <[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>

> On Mon, 2006-11-27 at 01:59 -0800, Aaron Stone wrote:
> > On Sun, 2006-11-26 at 23:07 +0100, Kjetil Torgrim Homme wrote:
> > > sounds to me like you want to use this to duplicate e-mail, for SarbOx
> > > archival purposes or whatever.  I don't think this is relevant for
> > > Sieve.  make the copy in your MTA so that the archival account is a
> > > firstclass citizen as far as Sieve is concerned.
> >
> > I'm sure some of my users have this in mind, and others have other
> > things in mind. If I provide multiscript functionality, that's one
> > feature for me to write and many purposes they can use it for.
> >
> > I do agree that the specific case of keeping a second copy of mail is
> > probably better done by an MTA hook, if possible, but I don't see any
> > reason to prevent a Sieve script from being used for this purpose. Let's
> > not hang the whole discussion on this one use case, however -- given
> > that Ned and Tony have both said that their implementations have some
> > form of multiscript, I think we can assume that it is useful enough to
> > look into some more.

> but Jutta's draft is very different, if a fileinto is taken, the next
> script will not be processed (there is no longer an implicit or explicit
> keep).

This is approximately how our implementation works. Again, the "most
specific" script that executes one or more explicit actions wins. So
if the system sieve says "fileinto spam" or "discard" but the user has
a sieve that says "keep", the keep wins. This makes various forms of
per-user, per-domain, and per-channel whitelisting and blacklisting possible.

> the draft suggests that fileinto is disallowed to solve this
> problem.  also note that a discard can not be overruled by the user.
> (I'm a bit mystified by Ned saying his system is similar to Jutta's)

This is one point where we differ. Again, system sieves need both an
overridable and a non-overrideable discard. We elected to implement a
nonstandard action "jettison" for this purpose.

> from your first message again:

> > The special considerations I can think of are that the implicit keep
> > does not cross between the postmaster script and the user's script,
> > except in the case of a reject. That is, if the postmaster does a
> > fileinto, discard, keep, redirect, whatever, this affects only the
> > "postmaster's copy" of the message. A reject should trash the message
> > and cancel the user's delivery, however.

> you seem to want to change the semantics of fileinto so that it does not
> cancel implicit keep, unless when run as the last script.  this sounds
> very complex and confusing to me, and is the reason I suggest the
> postmaster script works on a separate copy of the message.

That's only appropriate if you're using the script to implement something like
compliance archiving. I don't think sieve is necessarily an appropriate place
to implement this sort of thing because compliance archiving generally involves
saving pretty much everything, so what's the benefit of doing it in sieve? 
Nevertheless, if you want to do it you will need a non-overrideable fileinto
that doesn't cancel implicit keep at other levels.

Message capture for law enforcement purposes is another interesting case. This
differs from compliance archiving in that everyone who works for, say, a bank
is going to be aware that everything they send is saved. But when that subpeona
arrives odds are it says that whoever is supposed to be monitored cannot be
made aware of the fact that monitoring is underway.

I know of no case law covering the case where monitoring was inadvertently
revealed to be taking place (pointers appreciated if anyone knows of a case),
but I wouldn't be at all surprised that lack of due diligence in this regard
might open you up to a contempt of court charge or even obstruction of
justice.

In any case, while we do provide a means of performing a special type of
archiving action in sieve, we prefer to use other means because sieve scripts
pretty much have to be visible to all sysadmins.

				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 kB1Kb0Dq075703; Fri, 1 Dec 2006 13:37:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kB1Kb0VV075702; Fri, 1 Dec 2006 13: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 laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB1KaxL7075690 for <[e-mail]>; Fri, 1 Dec 2006 13:36:59 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 265B514227B; Fri,  1 Dec 2006 12:36:59 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00341-03; Fri, 1 Dec 2006 12:36:58 -0800 (PST)
Received: from [10.1.1.220] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A8293142272; Fri,  1 Dec 2006 12:36:58 -0800 (PST)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: multipart/alternative; boundary=Apple-Mail-3--132860659
Message-Id: <[e-mail]>
Cc: [e-mail]
From: Lisa Dusseault <[e-mail]>
Subject: Re: Spam blowback from Sieve implementations.
Date: Fri, 1 Dec 2006 12:36:56 -0800
To: Matthew Elvey <[e-mail]>
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
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>

--Apple-Mail-3--132860659
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

It's not only that.  IF Sun or any  SIEVE implementors were to start  
using a new, different recommended behavior for REJECT on the basis  
of a new standard, then when server software gets upgraded to one of  
these new server implementations, users with existing SIEVE scripts  
would suddenly start seeing new behavior.  That's not very good for  
users.

Lisa

On Nov 30, 2006, at 2:03 AM, Matthew Elvey wrote:

>
> Apropos "Sun will likely ignore the standard": There is already a  
> lot of ignoring (I would call it bending) sieve standards going on  
> in multiple implementations.
>


--Apple-Mail-3--132860659
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV>It's not only that.=A0 IF =
Sun or any=A0 SIEVE implementors were to start using a new, different =
recommended behavior for REJECT on the basis of a new standard, then =
when server software gets upgraded to one of these new server =
implementations, users with existing SIEVE scripts would suddenly start =
seeing new behavior.=A0 That's not very good for users.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Lisa</DIV><BR><DIV><DIV>On =
Nov 30, 2006, at 2:03 AM, Matthew Elvey wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">Apropos =
"Sun will likely ignore the standard": There is already a lot of =
ignoring (I would call it bending) sieve standards going on in multiple =
implementations.</FONT></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; min-height: 14px; "><BR></DIV> =
</BLOCKQUOTE></DIV><BR></BODY></HTML>=

--Apple-Mail-3--132860659--