Re: I-D ACTION:draft-ietf-sieve-3431bis-02.txt

[Alexey Melnikov <[e-mail]>]

Barry Leiba wrote:

>>Speaking as a WG member, I would prefer if you delete everything
>>after "Internet Messages Access Protocol (IMAP) servers"
>>    
>>
>
>Sure, I can do that -- but why not remove the whole paragraph?  There's
>nothing in that paragraph that needs to be there, since the Sieve base
>spec tells us what Sieve is, and this whole document is dependent on
>that one.
>  
>
That is fine as well.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGq5mX016271; Wed, 30 Nov 2005 08:52:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUGq5mI016270; Wed, 30 Nov 2005 08:52:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGq426016259 for <[e-mail]>; Wed, 30 Nov 2005 08:52:04 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.112] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 30 Nov 2005 16:52:01 +0000
Message-ID: <[e-mail]>
Date: Wed, 30 Nov 2005 16:52:01 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-3431bis-02.txt
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>

Barry Leiba wrote:

>>Speaking as a WG member, I would prefer if you delete everything
>>after "Internet Messages Access Protocol (IMAP) servers"
>>    
>>
>
>Sure, I can do that -- but why not remove the whole paragraph?  There's
>nothing in that paragraph that needs to be there, since the Sieve base
>spec tells us what Sieve is, and this whole document is dependent on
>that one.
>  
>
That is fine as well.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGYJNI014189; Wed, 30 Nov 2005 08:34:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUGYJXI014188; Wed, 30 Nov 2005 08:34:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGYIKi014179 for <[e-mail]>; Wed, 30 Nov 2005 08:34:18 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jAUGaExN004220 for <[e-mail]>; Wed, 30 Nov 2005 11:36:14 -0500
Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jAUGYCQ224388 for <[e-mail]>; Wed, 30 Nov 2005 11:34:12 -0500
Received: from mars (mars.watson.ibm.com [9.2.40.64]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jAUGYB5190376 for <[e-mail]>; Wed, 30 Nov 2005 11:34:11 -0500
Received: from saturn ([9.2.43.75]) by mars.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1133368451.97; Wed, 30 Nov 2005 11:34:11 -0400
Date: Wed, 30 Nov 2005 11:34:11 -0500
From: Barry Leiba <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-3431bis-02.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Speaking as a WG member, I would prefer if you delete everything
> after "Internet Messages Access Protocol (IMAP) servers"

Sure, I can do that -- but why not remove the whole paragraph?  There's
nothing in that paragraph that needs to be there, since the Sieve base
spec tells us what Sieve is, and this whole document is dependent on
that one.

Barry

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGCTe4011997; Wed, 30 Nov 2005 08:12:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUGCTEU011996; Wed, 30 Nov 2005 08:12:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUGCRVn011990 for <[e-mail]>; Wed, 30 Nov 2005 08:12:28 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.112] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 30 Nov 2005 16:12:14 +0000
Message-ID: <[e-mail]>
Date: Wed, 30 Nov 2005 16:12:14 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-3431bis-02.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Barry Leiba wrote:

>>While it might be fine to recap some of the attributes of Sieve in an
>>introduction, listing some of the things that are not present in Sieve
>>potentially sets the document up to contradict other Sieve documents
>>should those things eventually appear.  E.g., the phrase "it has no
>>variables" will (hopefully) be false at some point, and there has been
>>talk of loops as well.  I still think it's best to leave those sorts
>>of things unsaid here.
>>    
>>
>
>I thought about that, actually, when I was editing it, and decided to
>leave this in.  But if others agree, I'm happy to take it out.  It's
>certainly true of the base Sieve, so I'm not worried about inaccuracy.
>But it's true that there's not really a need to have a description of
>what Sieve is here.
>  
>
Speaking as a WG member, I would prefer if you delete everything after 
"Internet Messages Access Protocol (IMAP) servers" (section 2,  
paragraph 1, the last sentence):

   It is suitable for running on a mail server where users may
   not be allowed to execute arbitrary programs, such as on black box
   Internet Messages Access Protocol (IMAP) servers, as it has no
   variables, loops, nor the ability to shell out to external programs.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUG1Dxs010777; Wed, 30 Nov 2005 08:01:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAUG1Dmd010776; Wed, 30 Nov 2005 08:01:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAUG1CQo010767 for <[e-mail]>; Wed, 30 Nov 2005 08:01:12 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1EhUOK-0006tE-Iy; Wed, 30 Nov 2005 17:01:08 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EhUOH-0000rk-7B; Wed, 30 Nov 2005 17:01:05 +0100
Subject: Re: 'header' test and whitespace
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[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]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 30 Nov 2005 17:01:04 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.391, required 12, autolearn=disabled, AWL -0.39, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-11-29 at 15:15 -0800, Philip Guenther wrote:
> Kjetil Torgrim Homme <[e-mail]> writes:
> >I'm repeating it once more so Philip may take note of it :-).
> 
> Okay, okay, it's in now.

thanks!  (sorry, didn't mean to imply you weren't paying diligent
attention.)

> >also in the latest draft is this:
> >
> >   The preferred way to test whether a given header is either empty or
> >   absent is to combine an "exists" test and a "header" test:
> >
> >           anyof (header :is "Cc" "", not exists "Cc")
>
> Ick.  I agree that your version matches the "plain meaning" of the
> description better than the one currently in the doc, but it is an
> imprecise description.  Hmm.  How about:
> 
>     Testing whether a given header is either absent or doesn't contain
>     any non-whitespace characters can be done using a negated "header"
>     test:
> 	not header :matches "Cc" "?*"

this seems spurious in the spec text, IMHO, since there is no rationale
for why the text was added.  how about:

        The following test will return false when the header is absent:

        header :is "Cc" ""

        Testing whether a given header is either absent or contains
        nothing but whitespace can be done using a negated "header"
        test:
        
                not header :matches "Cc" "?*"
-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAU1kQwq015648; Tue, 29 Nov 2005 17:46:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAU1kQnZ015647; Tue, 29 Nov 2005 17:46:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id jAU1kPsY015635 for <[e-mail]>; Tue, 29 Nov 2005 17:46:25 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 72200 invoked by uid 101); 29 Nov 2005 20:46:25 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 29 Nov 2005 20:46:25 -0500
To: Philip Guenther <[e-mail]>
Cc: "Mark E. Mallett" <[e-mail]>, [e-mail]
Subject: Re: 'header' test and whitespace
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Nov 29, 2005 at 03:25:43PM -0800, Philip Guenther wrote:
> "Mark E. Mallett" <[e-mail]> writes:
> >On Tue, Nov 29, 2005 at 12:28:57PM +0100, Kjetil Torgrim Homme wrote:
> >> also in the latest draft is this:
> >> 
> >>    The preferred way to test whether a given header is either empty or
> >>    absent is to combine an "exists" test and a "header" test:
> >> 
> >>            anyof (header :is "Cc" "", not exists "Cc")
> >> 
> >> this will evaluate to true for:
> >> 
> >>   Cc: [e-mail]
> >>   Cc:
> >> 
> >> it may not be worth considering this rather degenerate case.  it seems
> >> to me Bcc is a more likely candidate for the stated test.  however, one
> >> way of stating the test correctly is:
> >> 
> >>   not (header :matches "Cc" "?*")
> >> 
> >> it's not much more convoluted, so I think it is worthwhile to change the
> >> "preferred way".
> >
> >Parentheses aside... in my implementation at least, the "header" test
> >would return true (because of the non-empty 'cc'), and be notted to
> >return false.  So this wouldn't work.
> 
> His point is that _is_ the desired behavior.  Given the two line message
> header above, you would say that the Cc: header is either missing or
> empty?  It certainly isn't missing and while one occurrence is empty, I
> would not call "the Cc: header" empty, so returning 'false' is the Right
> Thing.

Oh.. I misunderstood the remarks then (and then assUmeD too much about
the code snippet not working).  I nearly added some words about how I
wasn't absolutely sure from the textual description what the test was
looking for (in the presence of of the "degenerate" example), but I
didn't since it seemed clear enough to me -- but in the opposite of the
intended meaning, apparently.  In my sight, yes, there is a given header
field there that is empty, and thus the test should return true (to
match the narrative).  I don't really see "the Cc: header" -- I see two
"Cc: header fields" and I would indeed view one of their bodies as
empty.  It's hard to account for the way different people look at
things, especially when English is involved.


> Anyway, I've replaced the text in the I-D with this:
>     Testing whether a given header is either absent or doesn't contain
>     any non-whitespace characters can be done using a negated "header"
>     test:
>         not header :matches "Cc" "?*"

I would still come up with the same (opposite of what was intended)
interpretation of the new phrasing, although I'd probably be less sure
of it :).  There's still the ambiguity between "all" and "any" (or
"some" and "none", etc) that can lead to different interpretations.  And
I think replacing "empty" with a more complex phrase obscures the
meaning-- "empty" or "blank" should be pretty clear in the narrative.  I
would find this a little clearer:

    Testing whether there is no appearance of a non-empty field body for
    a given header name can be done using a negated header test:

although still clunky.


> ...
> >But I think you could say
> >
> >   not allof (exists "cc", header :matches "cc" "?*")
> 
> That's equivalent to what's in the -05 I-D.

Hah.  Yes, indeed.

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jATNPj0a099671; Tue, 29 Nov 2005 15:25:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jATNPj7v099670; Tue, 29 Nov 2005 15:25:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jATNPirc099664 for <[e-mail]>; Tue, 29 Nov 2005 15:25:44 -0800 (PST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jATNPh7p019291 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 29 Nov 2005 15:25:44 -0800
X-DKIM: Sendmail DKIM Filter v0.1.1 foon.sendmail.com jATNPh7p019291
DKIM-Signature: a=rsa-sha1; c=nowsp; d=sendmail.com; s=tls.dkim; t=1133306744; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:To:Cc:From:Subject:In-reply-to:References:Date:Sender: X-ok-sendmail.com; b=C3faUyk3r2hOA9UAXYDvKG6ZCAvsqg+QxF39vbM5F5QRjd 4zg8va+TBckmUfdftf/0tVEX+oh5Mff0ydY1RjJ7MeRLjB4dZvqTsEhUMPaU6ApZowE nWNdrIfx4fxAIBoK3Lp7uDf1lIlwDogxMKo0o5Qx0+E7tJMTUc4rV+8BqA=
X-DomainKeys: Sendmail DomainKeys Filter v0.3.0 foon.sendmail.com jATNPh7p019291
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:cc:from:subject:in-reply-to: references:date:sender:x-ok-sendmail.com; b=RdfCMzdeozHzHEB6MW5H2TIXCaMux2fx/h+QZBYnptKcsb41nODY3bZfOOSQp14pa 2hXM+8YmcDOO7feG+rJleEM961p7AOJ4B7K8L6l8a5Ovw+X4tcQXU3ngWJ8ZWPNnOlu 9OoIZcpHcNesoDVCSQcSuJn0RLut0uANCR7wIVo=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id jATNPh3h002927; Tue, 29 Nov 2005 15:25:43 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: 'header' test and whitespace 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Tue, 29 Nov 2005 15:25:43 -0800
X-ok-sendmail.com: Yes
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" <[e-mail]> writes:
>On Tue, Nov 29, 2005 at 12:28:57PM +0100, Kjetil Torgrim Homme wrote:
>> also in the latest draft is this:
>> 
>>    The preferred way to test whether a given header is either empty or
>>    absent is to combine an "exists" test and a "header" test:
>> 
>>            anyof (header :is "Cc" "", not exists "Cc")
>> 
>> this will evaluate to true for:
>> 
>>   Cc: [e-mail]
>>   Cc:
>> 
>> it may not be worth considering this rather degenerate case.  it seems
>> to me Bcc is a more likely candidate for the stated test.  however, one
>> way of stating the test correctly is:
>> 
>>   not (header :matches "Cc" "?*")
>> 
>> it's not much more convoluted, so I think it is worthwhile to change the
>> "preferred way".
>
>Parentheses aside... in my implementation at least, the "header" test
>would return true (because of the non-empty 'cc'), and be notted to
>return false.  So this wouldn't work.

His point is that _is_ the desired behavior.  Given the two line message
header above, you would say that the Cc: header is either missing or
empty?  It certainly isn't missing and while one occurrence is empty, I
would not call "the Cc: header" empty, so returning 'false' is the Right
Thing.

Anyway, I've replaced the text in the I-D with this:
    Testing whether a given header is either absent or doesn't contain
    any non-whitespace characters can be done using a negated "header"
    test:
        not header :matches "Cc" "?*"


...
>But I think you could say
>
>   not allof (exists "cc", header :matches "cc" "?*")

That's equivalent to what's in the -05 I-D.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jATNF80H098793; Tue, 29 Nov 2005 15:15:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jATNF8Rj098792; Tue, 29 Nov 2005 15:15:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jATNF8CD098785 for <[e-mail]>; Tue, 29 Nov 2005 15:15:08 -0800 (PST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jATNF1Wx016489 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 29 Nov 2005 15:15:02 -0800
X-DKIM: Sendmail DKIM Filter v0.1.1 foon.sendmail.com jATNF1Wx016489
DKIM-Signature: a=rsa-sha1; c=nowsp; d=sendmail.com; s=tls.dkim; t=1133306102; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:To:Cc:From:Subject:In-reply-to:References:Date:Sender: X-ok-sendmail.com; b=dQJ/v5DB1PaBNZQj4gcgAu5UT3TCVv8T8rDhmG4LXo/+2e DwrmkyfSXVAwvtkRBKIOpSMDDg0UnZSDmx3bqoO511QJUlmqjZnwSKsMdX8L5SvdmKf RFwU+okE9cgBc0OZhsfU6HwxGwJYWLIo8bIQ+nOL3KsgKral/qI7bKuTzI=
X-DomainKeys: Sendmail DomainKeys Filter v0.3.0 foon.sendmail.com jATNF1Wx016489
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:cc:from:subject:in-reply-to: references:date:sender:x-ok-sendmail.com; b=fpE4miBgVumcXXJa8cHuerAjhZ7qHEvsP6asjKAF9OsXYioSVK2o9VnlvYzH5b5Nw BEUrnvopyPs+Uw1k0OgXaXPd955D0pGCd5tzTtPMqGwbxXiiUdfl/V4pxlNvS5y2QQo hos7TbvOZwQNnZTDw9AFpDB1LziHYOxvd6a3x2I=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id jATNF1aE002112; Tue, 29 Nov 2005 15:15:01 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: 'header' test and whitespace 
In-reply-to: <[e-mail]> 
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]> 
Date: Tue, 29 Nov 2005 15:15:01 -0800
X-ok-sendmail.com: Yes
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>

Kjetil Torgrim Homme <[e-mail]> writes:
>> > for the base specification, I would like a tiny change to make this
>>> a little more apparent:
>> 
>> >    For instance, the test `header :contains ["To", "Cc"]
>> > -  ["[e-mail]", "[e-mail]"]' is true if either the
>> > +  ["[e-mail]", "[e-mail]"]' is true if either a
>> >    To header or Cc header of the input message contains either of the
>> >    email addresses "[e-mail]" or "[e-mail]".
>> 
>> Seems like a good idea to me.
>
>I'm repeating it once more so Philip may take note of it :-).

Okay, okay, it's in now.


>also in the latest draft is this:
>
>   The preferred way to test whether a given header is either empty or
>   absent is to combine an "exists" test and a "header" test:
>
>           anyof (header :is "Cc" "", not exists "Cc")
>
>this will evaluate to true for:
>
>  Cc: [e-mail]
>  Cc:
>
>it may not be worth considering this rather degenerate case.  it seems
>to me Bcc is a more likely candidate for the stated test.  however, one
>way of stating the test correctly is:
>
>  not (header :matches "Cc" "?*")
>
>it's not much more convoluted, so I think it is worthwhile to change the
>"preferred way".

Ick.  I agree that your version matches the "plain meaning" of the
description better than the one currently in the doc, but it is an
imprecise description.  Hmm.  How about:

    Testing whether a given header is either absent or doesn't contain
    any non-whitespace characters can be done using a negated "header"
    test:
	not header :matches "Cc" "?*"


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jATHNrGF054605; Tue, 29 Nov 2005 09:23:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jATHNrmP054604; Tue, 29 Nov 2005 09:23:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id jATHNps2054593 for <[e-mail]>; Tue, 29 Nov 2005 09:23:51 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 5099 invoked by uid 101); 29 Nov 2005 12:23:50 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 29 Nov 2005 12:23:50 -0500
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
Subject: Re: 'header' test and whitespace
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Nov 29, 2005 at 12:28:57PM +0100, Kjetil Torgrim Homme wrote:
> 
> also in the latest draft is this:
> 
>    The preferred way to test whether a given header is either empty or
>    absent is to combine an "exists" test and a "header" test:
> 
>            anyof (header :is "Cc" "", not exists "Cc")
> 
> this will evaluate to true for:
> 
>   Cc: [e-mail]
>   Cc:
> 
> it may not be worth considering this rather degenerate case.  it seems
> to me Bcc is a more likely candidate for the stated test.  however, one
> way of stating the test correctly is:
> 
>   not (header :matches "Cc" "?*")
> 
> it's not much more convoluted, so I think it is worthwhile to change the
> "preferred way".

Parentheses aside... in my implementation at least, the "header" test
would return true (because of the non-empty 'cc'), and be notted to
return false.  So this wouldn't work.  In order for it to work, the
interior 'header' test would have to be influenced by the 'not' somehow,
so that it rearranged the logic to be:

   header :not :matches "Cc" "?*"

which would depend on how it treated the lack of a header field at all.

But I think you could say

   not allof (exists "cc", header :matches "cc" "?*")

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jATD0nFD021907; Tue, 29 Nov 2005 05:00:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jATD0nNh021906; Tue, 29 Nov 2005 05:00:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jATD0mVo021899 for <[e-mail]>; Tue, 29 Nov 2005 05:00:48 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1Eh56C-0004CN-I4 for [e-mail]; Tue, 29 Nov 2005 14:00:44 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1Eh566-0003r3-Fp for [e-mail]; Tue, 29 Nov 2005 14:00:38 +0100
Subject: Re: 'header' test and whitespace
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 29 Nov 2005 14:00:37 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.575, required 12, autolearn=disabled, AWL -0.57, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2005-11-29 at 12:28 +0100, Kjetil Torgrim Homme wrote:
> [...] one way of stating the test correctly is:
> 
>   not (header :matches "Cc" "?*")
> 
> it's not much more convoluted, so I think it is worthwhile to change the
> "preferred way".

sorry, those parentheses are superfluous and should be left out.

  not header :matches "Cc" "?*"

-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jATBTB3c007740; Tue, 29 Nov 2005 03:29:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jATBTB7d007739; Tue, 29 Nov 2005 03:29:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jATBT9Ju007728 for <[e-mail]>; Tue, 29 Nov 2005 03:29:10 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1Eh3fW-0004by-31 for [e-mail]; Tue, 29 Nov 2005 12:29:06 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1Eh3fN-0008ML-Fq for [e-mail]; Tue, 29 Nov 2005 12:28:57 +0100
Subject: Re: 'header' test and whitespace
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 29 Nov 2005 12:28:57 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.396, required 12, autolearn=disabled, AWL -0.40, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > for the base specification, I would like a tiny change to make this
>> a little more apparent:
> 
> >    For instance, the test `header :contains ["To", "Cc"]
> > -  ["[e-mail]", "[e-mail]"]' is true if either the
> > +  ["[e-mail]", "[e-mail]"]' is true if either a
> >    To header or Cc header of the input message contains either of the
> >    email addresses "[e-mail]" or "[e-mail]".
> 
> Seems like a good idea to me.

I'm repeating it once more so Philip may take note of it :-).

also in the latest draft is this:

   The preferred way to test whether a given header is either empty or
   absent is to combine an "exists" test and a "header" test:

           anyof (header :is "Cc" "", not exists "Cc")

this will evaluate to true for:

  Cc: [e-mail]
  Cc:

it may not be worth considering this rather degenerate case.  it seems
to me Bcc is a more likely candidate for the stated test.  however, one
way of stating the test correctly is:

  not (header :matches "Cc" "?*")

it's not much more convoluted, so I think it is worthwhile to change the
"preferred way".
-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAT0fN7m040451; Mon, 28 Nov 2005 16:41:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAT0fNcc040450; Mon, 28 Nov 2005 16:41:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAT0fMLJ040440 for <[e-mail]>; Mon, 28 Nov 2005 16:41:22 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jAT0hIFo013633 for <[e-mail]>; Mon, 28 Nov 2005 19:43:18 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jAT0fGu51090 for <[e-mail]>; Mon, 28 Nov 2005 19:41:16 -0500
Received: from saturn.watson.ibm.com ([9.12.242.210]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jAT0fFK52872; Mon, 28 Nov 2005 19:41:15 -0500
Date: Mon, 28 Nov 2005 19:25:13 -0500
From: Barry Leiba <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-3431bis-02.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> While it might be fine to recap some of the attributes of Sieve in an
> introduction, listing some of the things that are not present in Sieve
> potentially sets the document up to contradict other Sieve documents
> should those things eventually appear.  E.g., the phrase "it has no
> variables" will (hopefully) be false at some point, and there has been
> talk of loops as well.  I still think it's best to leave those sorts
> of things unsaid here.

I thought about that, actually, when I was editing it, and decided to
leave this in.  But if others agree, I'm happy to take it out.  It's
certainly true of the base Sieve, so I'm not worried about inaccuracy.
But it's true that there's not really a need to have a description of
what Sieve is here.

Barry

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jASMKAmL023739; Mon, 28 Nov 2005 14:20:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jASMKAMq023738; Mon, 28 Nov 2005 14:20:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id jASMK9CY023730 for <[e-mail]>; Mon, 28 Nov 2005 14:20:09 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 9951 invoked by uid 101); 28 Nov 2005 17:20:09 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 28 Nov 2005 17:20:09 -0500
To: Alexey Melnikov <[e-mail]>
Cc: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-3431bis-02.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Nov 22, 2005 at 05:43:44PM +0000, Alexey Melnikov wrote:
> Barry Leiba wrote:
> 
> >>A New Internet-Draft is available from the on-line Internet-Drafts 
> >>directories.
> >>This draft is a work item of the Sieve Mail Filtering Language 
> >>Working Group of the IETF.
> >>
> >>    Title        : Sieve Extension: Relational Tests
> >>    Author(s)    : W. Segmuller, B. Leiba
> >>    Filename    : draft-ietf-sieve-3431bis-02.txt
> >>    Pages        : 14
> >>    Date        : 2005-11-21
> >
> >Alexey, this is ready for IETF last call now.
> 
> My recollection is that you've addressed both editorial and 
> non-editorial issues raised during WGLC. I don't think another WGLC is 
> needed.
> Any other opinions?

There is still this, which I either commented on at one point or meant
to: that the introduction states a few things that Sieve is not.  While
it might be fine to recap some of the attributes of Sieve in an
introduction, listing some of the things that are not present in Sieve
potentially sets the document up to contradict other Sieve documents
should those things eventually appear.  E.g., the phrase "it has no
variables" will (hopefully) be false at some point, and there has been
talk of loops as well.  I still think it's best to leave those sorts of
things unsaid here.

Yours,
-mm-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jASKo3HE013720; Mon, 28 Nov 2005 12:50:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jASKo3Hu013719; Mon, 28 Nov 2005 12:50:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jASKo2SO013713 for <[e-mail]>; Mon, 28 Nov 2005 12:50:03 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Egpwo-0007nw-5l; Mon, 28 Nov 2005 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-3028bis-05.txt 
Message-Id: <[e-mail]>
Date: Mon, 28 Nov 2005 15:50:02 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve: An Email Filtering Language
	Author(s)	: T. Showalter, P. Guenther
	Filename	: draft-ietf-sieve-3028bis-05.txt
	Pages		: 38
	Date		: 2005-11-28
	
This document describes a language for filtering email messages at
   time of final delivery.  It is designed to be implementable on either
   a mail client or mail server.  It is meant to be extensible, simple,
   and independent of access protocol, mail architecture, and operating
   system.  It is suitable for running on a mail server where users may
   not be allowed to execute arbitrary programs, such as on black box
   Internet Message Access Protocol (IMAP) servers, as it has no
   variables, loops, or ability to shell out to external programs.

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

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


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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-3028bis-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

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

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

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

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

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

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQIWOLv012609; Sat, 26 Nov 2005 10:32:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAQIWO9Q012608; Sat, 26 Nov 2005 10:32:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQIWNgl012602 for <[e-mail]>; Sat, 26 Nov 2005 10:32:23 -0800 (PST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 26 Nov 2005 10:32:22 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1133029941; h=Date: 	 From:Subject:MIME-version:Content-type; b=0ROHjHW28w0z+AuIOMpB4wRjb 6TRvvQJDWBJbqUkgw4GHBGcyQlu5peTcoSiGVp3rtymCOi8hMB0BshLD7Perw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 26 Nov 2005 10:32:18 -0800 (PST)
Cc: Michael Haardt <[e-mail]>, [e-mail]
To: Alexey Melnikov <[e-mail]>
Message-id: <[e-mail]>
Date: Sat, 26 Nov 2005 10:32:10 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Extension "envelope-auth"?
In-reply-to: "Your message dated Thu, 24 Nov 2005 15:23:56 +0000" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Michael Haardt wrote:

> >Hello,
> >
> >some time ago, we talked about "envelope-auth" to introduce "auth" to the
> >envelope test, which accesses the authenticated sender (AUTH parameter
> >in MAIL FROM, in case the mail system decides not to ignore it, and an
> >empty string otherwise).
> >
> >Is there a draft already or somebody working on it?
> >
> >
> If I remember correctly Ned has volunteered to author it.

Yes, that's correct.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQH1CkB004674; Sat, 26 Nov 2005 09:01:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAQH1Cnm004673; Sat, 26 Nov 2005 09:01:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQH1Bhd004667 for <[e-mail]>; Sat, 26 Nov 2005 09:01:11 -0800 (PST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Sat, 26 Nov 2005 09:01:08 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1133024468; h=MIME-version: 	 Content-transfer-encoding:Content-type:Date:From:Subject; b=XiOO+om 	gAZKQzyatmJRWIoqMsbbF40Je5bppjuwdibxQVMTgAB8uvRtjCRPVDrWvVDdhwxJKgE TK5dbxKZB2vw==
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=ISO-8859-1
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 26 Nov 2005 09:01:04 -0800 (PST)
Cc: Ned Freed <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Sat, 26 Nov 2005 08:45:35 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: 'header' test and whitespace
In-reply-to: "Your message dated Sat, 26 Nov 2005 09:08:50 +0100" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Fri, 2005-11-25 at 15:53 -0800, Ned Freed wrote:
> > > the exact method used of RFC 2047 encoding doesn't have any semantics,
> > > either.
> >
> > In the abstract, maybe. But in practice it does. For example, it happens to
> > make perfect sense for me to filter out all messages that use the koi8-r
> > charset. I receive maybe 300 such messages every day, and they are without
> > exception spam.

> that will work until the spammers are savvy enough to switch to UTF-8 to
> avoid such filtering.  the correct test would check for code points, not
> encodings.

The same can be said for every other check you can think of - eventually
the spammers will adapt. That doesn't mean it isn't useful now, and it doesn't
mean other similar tests won't be useful in the future.

This is not, and should not be, a search for the FUSSP.

> > There are also cases where language can be inferred with reasonable reliability
> > from charset, and this can be very useful in some applications. (There often
> > isn't enough text in a header to analyze to determine the langauge being used.)

> yes, although I have received messages in Norwegian using GB2312
> encoding and messages in English using KOI8-R encoding, it's a safe bet
> that the sender of these messages understand Chinese and Russian
> respectively since they've set up their e-mail program to use these
> encodings.

> > > a discussion thread might have a Subject which switches back
> > > and forth between Q and B encoding, or in the length of encoded-words
> > > and hence the number of lines.  this is very apparent for us
> > > non-USans :-)
> >
> > The encoding probably doesn't matter, especially since it sometimes changes in
> > transit. Charset changes are much rarer.

> not in this neck of the woods.  different users will prefer UTF-8, ISO
> 8859-1 and ISO 8859-15, and the Subject will switch back and forth.

That's quite true here but beside the point. I'm talking about changes in
transit, not the use of various different stuff when messages are composed.
Indeed, the reason that you see such mixtures regularly (as do I) is because
such changes _aren't_ being made by composing and transfer agents - they leave
the original source alone.

> > > so I don't think it's appropriate to make :raw be :halfraw.  the CR LF
> > > is actually a part of the raw header.
> >
> > I disagree. Folding points change all the time, they are specifically defined
> > not to have semantics, and I don't believe I've ever seen a case where I wanted
> > a test that is sensitive to CRLFs. The same cannot be said for encoded words
> > and trailing spaces.

> okay, fine.  I was thinking abut cases where you want to repeat it back
> at the sender, e.g.

>   vacation :subject text:
> Auto: I'm away from office
>  (was: ${subject} )
> .
> ;

> where the fact that the CRLFs are included in ${subject} makes it
> unnecessary to worry about folding of overlong subjects.  the vacation
> draft should perhaps be explicit in that Subject must be folded
> appropriately?

Wow, I had never even considered putting explicit folding points into a
vacation subject argument. Given that there can be substitutions and encoded
word generation and who knows what else happening it seems like a really bad
idea for a script to do this explicitly, but I suppose the vacation draft needs
to say that (a) The subjects and other headers in generated vacation responses
have to be properly folded and (b) CRLFs in subject arguments need to be
handled sensibly. In particular, the case of
<text-with-no-space><CRLF><text-with-no-space> has to be handled in a way that
doesn't cause an illegal header to be generated. I think I'll say something
like "CRLFs in :subject arguments MAY simply be removed but MUST be handled
in a fashion that prevents an illegal header field from being produced."

> > > while we're at it, what do we do about headers which can have multiple
> > > values, e.g. "Cc"?  (multiple headers is deprecated in 2822, but must be
> > > supported.)  I don't have a good suggestion.  the naive approach is to
> > > concatenate them as if they were simply separated by CR LF, but for "Cc"
> > > you would really want to include a comma in the delimiter as well.  the
> > > other option is to say that the first matching header is used.  this
> > > sits well with short-circuiting logic, but means it's impossible to
> > > capture the complete value of the header.
> >
> > Simple: You test all the values as separate fields. Sieve tests already allow for
> > a list of fields but there's an implicit list even when there's only a single
> > field name specified.

> yes, "but [this] means it's impossible to capture the complete value of
> the header", "*" will only fetch the contents of the first one.

Yep.

> perhaps
> a loop construct for the address test would be a more appropriate
> solution to that problem?

>   for.every.address ["To", "Cc"] { block }

Yes, seems reasonable. In fact I once argued that the concept of a result
generator might make sense in sieve - the Icon language uses this to great
advantage in a bunch of different ways.

> this can of course wait until we see the need.  for the base
> specification, I would like a tiny change to make this a little more
> apparent:

>    For instance, the test `header :contains ["To", "Cc"]
> -  ["[e-mail]", "[e-mail]"]' is true if either the
> +  ["[e-mail]", "[e-mail]"]' is true if either a
>    To header or Cc header of the input message contains either of the
>    email addresses "[e-mail]" or "[e-mail]".

Seems like a good idea to me.

> > > > Yes, I'm afraid so. Perhaps something like rawheader? (I believe the header
> > > > test is the only one for which :raw makes sense.)

> I'd like it for address, too.  this is the difference between
> "xn--srlandslaget-vjb.no" and "sørlandslaget.no".  okay, so this isn't
> in the spec today, but we might as well be ready for it.

Agreed, and it may be closer than you think given how the meeting at the last
IETF on i18n stuff in email went.

> > > what happens if you add a :raw argument and upload to today's
> > > implementations?  will they reject during upload?  will they ignore it
> > > during runtime?  will they bomb during runtime?
> >
> > Our implementation will return a runtime error. I believe this is the correct
> > behavior. We don't check during upload - our sieves are typically provisioned
> > via LDAP and we have no control over what tools are used to insert them into
> > the directory.
> >
> > And yes, this makes error reporting a real challenge.
> >
> > > IMHO it's okay as long as it doesn't cause a runtime error.  (Cyrus 2.2
> > > will reject upload, I haven't checked others.)
> >
> > This is just another extension, so I don't see why causing a runtime
> > error is a problem.

> right, that was my point.  if you didn't raise a runtime error, we might
> get away with not declaring it an extension.  but you do, so we don't.

OK, seems like we're in agreement then.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQ88xlK044597; Sat, 26 Nov 2005 00:08:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAQ88xrl044596; Sat, 26 Nov 2005 00:08:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQ88wUB044580 for <[e-mail]>; Sat, 26 Nov 2005 00:08:59 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1Efv79-0000Lw-7s; Sat, 26 Nov 2005 09:08:55 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1Efv75-0004A0-AM; Sat, 26 Nov 2005 09:08:51 +0100
Subject: Re: 'header' test and whitespace
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Date: Sat, 26 Nov 2005 09:08:50 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.602, required 12, autolearn=disabled, AWL -0.60, UIO_MAIL_IS_INTERNAL -5.00)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jAQ88xUB044591
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2005-11-25 at 15:53 -0800, Ned Freed wrote:
> > the exact method used of RFC 2047 encoding doesn't have any semantics,
> > either.
> 
> In the abstract, maybe. But in practice it does. For example, it happens to
> make perfect sense for me to filter out all messages that use the koi8-r 
> charset. I receive maybe 300 such messages every day, and they are without
> exception spam.

that will work until the spammers are savvy enough to switch to UTF-8 to
avoid such filtering.  the correct test would check for code points, not
encodings.

> There are also cases where language can be inferred with reasonable reliability
> from charset, and this can be very useful in some applications. (There often
> isn't enough text in a header to analyze to determine the langauge being used.)

yes, although I have received messages in Norwegian using GB2312
encoding and messages in English using KOI8-R encoding, it's a safe bet
that the sender of these messages understand Chinese and Russian
respectively since they've set up their e-mail program to use these
encodings.

> > a discussion thread might have a Subject which switches back
> > and forth between Q and B encoding, or in the length of encoded-words
> > and hence the number of lines.  this is very apparent for us
> > non-USans :-)
> 
> The encoding probably doesn't matter, especially since it sometimes changes in
> transit. Charset changes are much rarer.

not in this neck of the woods.  different users will prefer UTF-8, ISO
8859-1 and ISO 8859-15, and the Subject will switch back and forth.

> > so I don't think it's appropriate to make :raw be :halfraw.  the CR LF
> > is actually a part of the raw header.
> 
> I disagree. Folding points change all the time, they are specifically defined
> not to have semantics, and I don't believe I've ever seen a case where I wanted
> a test that is sensitive to CRLFs. The same cannot be said for encoded words
> and trailing spaces.

okay, fine.  I was thinking abut cases where you want to repeat it back
at the sender, e.g.

  vacation :subject text:
Auto: I'm away from office
 (was: ${subject} )
.
;

where the fact that the CRLFs are included in ${subject} makes it
unnecessary to worry about folding of overlong subjects.  the vacation
draft should perhaps be explicit in that Subject must be folded
appropriately?

> > while we're at it, what do we do about headers which can have multiple
> > values, e.g. "Cc"?  (multiple headers is deprecated in 2822, but must be
> > supported.)  I don't have a good suggestion.  the naive approach is to
> > concatenate them as if they were simply separated by CR LF, but for "Cc"
> > you would really want to include a comma in the delimiter as well.  the
> > other option is to say that the first matching header is used.  this
> > sits well with short-circuiting logic, but means it's impossible to
> > capture the complete value of the header.
> 
> Simple: You test all the values as separate fields. Sieve tests already allow for
> a list of fields but there's an implicit list even when there's only a single
> field name specified.

yes, "but [this] means it's impossible to capture the complete value of
the header", "*" will only fetch the contents of the first one.  perhaps
a loop construct for the address test would be a more appropriate
solution to that problem?

  for.every.address ["To", "Cc"] { block }

this can of course wait until we see the need.  for the base
specification, I would like a tiny change to make this a little more
apparent:

   For instance, the test `header :contains ["To", "Cc"]
-  ["[e-mail]", "[e-mail]"]' is true if either the
+  ["[e-mail]", "[e-mail]"]' is true if either a
   To header or Cc header of the input message contains either of the
   email addresses "[e-mail]" or "[e-mail]".

> > > Yes, I'm afraid so. Perhaps something like rawheader? (I believe the header
> > > test is the only one for which :raw makes sense.)

I'd like it for address, too.  this is the difference between
"xn--srlandslaget-vjb.no" and "sørlandslaget.no".  okay, so this isn't
in the spec today, but we might as well be ready for it.

> > what happens if you add a :raw argument and upload to today's
> > implementations?  will they reject during upload?  will they ignore it
> > during runtime?  will they bomb during runtime?
> 
> Our implementation will return a runtime error. I believe this is the correct
> behavior. We don't check during upload - our sieves are typically provisioned
> via LDAP and we have no control over what tools are used to insert them into
> the directory.
> 
> And yes, this makes error reporting a real challenge.
> 
> > IMHO it's okay as long as it doesn't cause a runtime error.  (Cyrus 2.2
> > will reject upload, I haven't checked others.)
> 
> This is just another extension, so I don't see why causing a runtime
> error is a problem.

right, that was my point.  if you didn't raise a runtime error, we might
get away with not declaring it an extension.  but you do, so we don't.

-- 
Kjetil T.





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQ0Jx3M005962; Fri, 25 Nov 2005 16:19:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAQ0Jxem005961; Fri, 25 Nov 2005 16:19:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAQ0JwiN005955 for <[e-mail]>; Fri, 25 Nov 2005 16:19:58 -0800 (PST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 25 Nov 2005 16:19:56 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1132964395; h=Date: 	 From:Subject:MIME-version:Content-type; b=h9CRyzkeKpbZzNJS/9y5ySUir 6mRy5Jn3BIitBs4wQyYbvz5r0O0ehg4vj6H+ozh6I+LRSvzlXEMzYxYVsrc+Q==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 25 Nov 2005 16:19:50 -0800 (PST)
Cc: Ned Freed <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 25 Nov 2005 15:53:28 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: 'header' test and whitespace
In-reply-to: "Your message dated Fri, 25 Nov 2005 23:56:45 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Fri, 2005-11-25 at 08:41 -0800, Ned Freed wrote:
> > Yes. I don't view this as part of the unfolding algorithm, however. But now
> > that you mention it, a better way to describe this is to do the unfolding
> > part first and then remove leading and trailing spaces. So the steps become:
> >
> > (1) Remove all CRLFs.
> >
> > (2) Remove leading and trailing spaces.
> >
> > (3) Decode RFC 2047 and convert to utf-8.

> if we're going to mention 2047, we should also mention that RFC 2231
> applies for some headers.  although it seems to me that using a
> bastardised 2047 is the deployed norm for Content-Disposition and
> friends, that's not correct according to the specifications, and being
> more explicit about it might help conformance to spec.

> > The last two steps should be skipped in :raw mode. (The first step is retained
> > because folding points aren't supposed to have any semantics and are known to
> > change unpredictably. The same cannot be said for spaces or encoded words.)

> the exact method used of RFC 2047 encoding doesn't have any semantics,
> either.

In the abstract, maybe. But in practice it does. For example, it happens to
make perfect sense for me to filter out all messages that use the koi8-r 
charset. I receive maybe 300 such messages every day, and they are without
exception spam.

There are also cases where language can be inferred with reasonable reliability
from charset, and this can be very useful in some applications. (There often
isn't enough text in a header to analyze to determine the langauge being used.)

> a discussion thread might have a Subject which switches back
> and forth between Q and B encoding, or in the length of encoded-words
> and hence the number of lines.  this is very apparent for us
> non-USans :-)

The encoding probably doesn't matter, especially since it sometimes changes in
transit. Charset changes are much rarer.

> so I don't think it's appropriate to make :raw be :halfraw.  the CR LF
> is actually a part of the raw header.

I disagree. Folding points change all the time, they are specifically defined
not to have semantics, and I don't believe I've ever seen a case where I wanted
a test that is sensitive to CRLFs. The same cannot be said for encoded words
and trailing spaces.

> while we're at it, what do we do about headers which can have multiple
> values, e.g. "Cc"?  (multiple headers is deprecated in 2822, but must be
> supported.)  I don't have a good suggestion.  the naive approach is to
> concatenate them as if they were simply separated by CR LF, but for "Cc"
> you would really want to include a comma in the delimiter as well.  the
> other option is to say that the first matching header is used.  this
> sits well with short-circuiting logic, but means it's impossible to
> capture the complete value of the header.

Simple: You test all the values as separate fields. Sieve tests already allow for
a list of fields but there's an implicit list even when there's only a single
field name specified.

> > > I am personally Ok with adding :raw to the base spec, but do we need a
> > > new capability?
> >
> > Yes, I'm afraid so. Perhaps something like rawheader? (I believe the header
> > test is the only one for which :raw makes sense.)

> what happens if you add a :raw argument and upload to today's
> implementations?  will they reject during upload?  will they ignore it
> during runtime?  will they bomb during runtime?

Our implementation will return a runtime error. I believe this is the correct
behavior. We don't check during upload - our sieves are typically provisioned
via LDAP and we have no control over what tools are used to insert them into
the directory.

And yes, this makes error reporting a real challenge.

> IMHO it's okay as long as it doesn't cause a runtime error.  (Cyrus 2.2
> will reject upload, I haven't checked others.)

This is just another extension, so I don't see why causing a runtime
error is a problem.

> the behaviour of "header" is under-specified in the current spec, and
> deployed implementations probably deviating behaviour.  the more
> detailed specs we're discussing here might make many of them obviously
> non-conforming where they were only arguably non-conforming before (i.e.
> not performing according to intent).  but is it important?  the number
> of capabilities makes life harder for both server and client
> implementors, and we should try to limit the number of them as much as
> possible.

I disagree with this as well. Additional new capabilities are nowhere as big
a problem as nailing things down in ways that break current behavior. To be
blunt, if this specification evolves to a point where our deployed sieve
scripts are incompatible with it, I'll have no choice but to stop supporting
sieve as defined by the IETF.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPNvP3b004324; Fri, 25 Nov 2005 15:57:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAPNvPbs004323; Fri, 25 Nov 2005 15:57:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPNvORR004310 for <[e-mail]>; Fri, 25 Nov 2005 15:57:25 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.50.144] (helo=mx1.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1EfnRT-0001vw-L5 for [e-mail]; Sat, 26 Nov 2005 00:57:23 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx1.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 #12) id 1EfnRT-0005p8-HN for [e-mail]; Sat, 26 Nov 2005 00:57:23 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.60-RC2 #3) id 1EfnRS-0007Zl-4A for [e-mail]; Sat, 26 Nov 2005 00:57:22 +0100
To: [e-mail]
Subject: Re: 'header' test and whitespace
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Sat, 26 Nov 2005 00:57:22 +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > > I am personally Ok with adding :raw to the base spec, but do we need a
> > > new capability?
> > 
> > Yes, I'm afraid so. Perhaps something like rawheader? (I believe the header
> > test is the only one for which :raw makes sense.)
>
> what happens if you add a :raw argument and upload to today's
> implementations?  will they reject during upload?  will they ignore it
> during runtime?  will they bomb during runtime?

Adding something completely new like that sounds like a typical extension
to me, and indeed a rawheader test may be a better way than adding a flag.

When I mentioned it, all I wanted was to make sure we don't put something
in the way of being able to create that extension.  I don't know if
anybody will ever specify it, but I feel we should be able to, should
the need arise.

> the behaviour of "header" is under-specified in the current spec, and
> deployed implementations probably deviating behaviour.  the more
> detailed specs we're discussing here might make many of them obviously
> non-conforming where they were only arguably non-conforming before (i.e.
> not performing according to intent).  but is it important?  the number
> of capabilities makes life harder for both server and client
> implementors, and we should try to limit the number of them as much as
> possible.

Current implementations probably specify conforming to RFC 3028,
and that is not going to change.  RFC 3028 gives too much freedom,
mostly not intentionally, and that's a problem.  Most implementations
probably need minor tweaks to conform to the new standard, and they
will still conform to RFC 3028.  Nobody likes changes, but everybody
asks for interoperability.  In this case, it's a small price to pay.

The number of extensions is a problem indeed, because they reduce
interoperability.  But if you required a "full" implementation on systems
that currently offer only a minimal implementation, perhaps they wouldn't
be using Sieve at all, being even less interoperable.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPMv3mE099742; Fri, 25 Nov 2005 14:57:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAPMv3fS099741; Fri, 25 Nov 2005 14:57:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPMv2Mm099729 for <[e-mail]>; Fri, 25 Nov 2005 14:57:02 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.43) id 1EfmUy-0000UF-FL; Fri, 25 Nov 2005 23:56:56 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EfmUs-0005Uj-Px; Fri, 25 Nov 2005 23:56:50 +0100
Subject: Re: 'header' test and whitespace
From: Kjetil Torgrim Homme <[e-mail]>
To: Ned Freed <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Fri, 25 Nov 2005 23:56:45 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.582, required 12, autolearn=disabled, AWL -0.58, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Fri, 2005-11-25 at 08:41 -0800, Ned Freed wrote:
> Yes. I don't view this as part of the unfolding algorithm, however. But now
> that you mention it, a better way to describe this is to do the unfolding
> part first and then remove leading and trailing spaces. So the steps become:
> 
> (1) Remove all CRLFs.
> 
> (2) Remove leading and trailing spaces.
> 
> (3) Decode RFC 2047 and convert to utf-8.

if we're going to mention 2047, we should also mention that RFC 2231
applies for some headers.  although it seems to me that using a
bastardised 2047 is the deployed norm for Content-Disposition and
friends, that's not correct according to the specifications, and being
more explicit about it might help conformance to spec.

> The last two steps should be skipped in :raw mode. (The first step is retained
> because folding points aren't supposed to have any semantics and are known to
> change unpredictably. The same cannot be said for spaces or encoded words.)

the exact method used of RFC 2047 encoding doesn't have any semantics,
either.  a discussion thread might have a Subject which switches back
and forth between Q and B encoding, or in the length of encoded-words
and hence the number of lines.  this is very apparent for us
non-USans :-)

so I don't think it's appropriate to make :raw be :halfraw.  the CR LF
is actually a part of the raw header.

while we're at it, what do we do about headers which can have multiple
values, e.g. "Cc"?  (multiple headers is deprecated in 2822, but must be
supported.)  I don't have a good suggestion.  the naive approach is to
concatenate them as if they were simply separated by CR LF, but for "Cc"
you would really want to include a comma in the delimiter as well.  the
other option is to say that the first matching header is used.  this
sits well with short-circuiting logic, but means it's impossible to
capture the complete value of the header.

> > I am personally Ok with adding :raw to the base spec, but do we need a
> > new capability?
> 
> Yes, I'm afraid so. Perhaps something like rawheader? (I believe the header
> test is the only one for which :raw makes sense.)

what happens if you add a :raw argument and upload to today's
implementations?  will they reject during upload?  will they ignore it
during runtime?  will they bomb during runtime?

IMHO it's okay as long as it doesn't cause a runtime error.  (Cyrus 2.2
will reject upload, I haven't checked others.)

the behaviour of "header" is under-specified in the current spec, and
deployed implementations probably deviating behaviour.  the more
detailed specs we're discussing here might make many of them obviously
non-conforming where they were only arguably non-conforming before (i.e.
not performing according to intent).  but is it important?  the number
of capabilities makes life harder for both server and client
implementors, and we should try to limit the number of them as much as
possible.

-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPGlsQR045914; Fri, 25 Nov 2005 08:47:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAPGls0E045912; Fri, 25 Nov 2005 08:47:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPGlqAB045899 for <[e-mail]>; Fri, 25 Nov 2005 08:47:53 -0800 (PST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 25 Nov 2005 08:47:46 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1132937266; h=Date: 	 From:Subject:MIME-version:Content-type; b=JasvYyObkrZ7JPzADC4VKKVOZ 2rUkom5+c3DeUnxcYEanr9SQbcDMUtY4uewyvXqLFEKd918A53fLwdhoji5Hg==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 25 Nov 2005 08:47:42 -0800 (PST)
Cc: Ned Freed <[e-mail]>, Barry Leiba <[e-mail]>, [e-mail]
To: Alexey Melnikov <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 25 Nov 2005 08:41:55 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: 'header' test and whitespace
In-reply-to: "Your message dated Fri, 25 Nov 2005 13:32:44 +0000" <[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]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Ned Freed wrote:

> >> I see from Alexey's minutes that I was supposed to post the text that
> >> I proposed.  I didn't remember that; sorry.  Philip started the
> >> discussion, but didn't post the text.  I gave Philip XML, and here's
> >> what I suggested:
> >
> >> <t>
> >> Because the meaning of leading and trailing whitespace characters in
> >> header
> >> fields is ambiguous, and their survival in message transport and
> >> processing
> >> is inconsistent, ALL handling of message headers in Sieve MUST normalize
> >> the header field values.  The normalization is similar to, but not
> >> the same
> >> as, unfolding (see RFC2822),
> >
> > I think the unfolding part needs to be the same as what's in RFC 2822.

> I agree.

> > and is done as follows:
> >
> >> <list style="number">
> >>    <t>
> >>      Remove leading and trailing whitespace characters from each line of
> >>      the header field (multiple lines, in the case of multi-line
> >> continuation).
> >>    </t>
> >
> This step is actually not mentioned in RFC 2822.

Yes. I don't view this as part of the unfolding algorithm, however. But now
that you mention it, a better way to describe this is to do the unfolding
part first and then remove leading and trailing spaces. So the steps become:

(1) Remove all CRLFs.

(2) Remove leading and trailing spaces.

(3) Decode RFC 2047 and convert to utf-8.

The last two steps should be skipped in :raw mode. (The first step is retained
because folding points aren't supposed to have any semantics and are known to
change unpredictably. The same cannot be said for spaces or encoded words.)

> >>    <t>
> >>      Remove the delimiting CRLF from each line.
> >>    </t>
> >>    <t>
> >>      Catenate the lines in order, inserting one ASCII space character
> >> (0x20)
> >>      between each pair.
> >
> >
> > This makes the unfolding different from what's in RFC 2822. I think
> > this is a
> > mistake. There should not be any "insert space" operation here - RFC 2822
> > section 2.2.3 simply calls for CRLFs to be removed.

> [...]

> >> Note that I didn't suggest RFC2047-decoding, but I think that's a
> >> reasonable
> >> addition to this.  Alternatively, we could specify that strings be
> >> decoded
> >> in comparisons (perhaps specified by an option like ":decode" or
> >> ":raw").
> >
> > A :raw option makes sense. I actually have no problem with adding it
> > to the
> > base specification but others may disagree.

> I am personally Ok with adding :raw to the base spec, but do we need a
> new capability?

Yes, I'm afraid so. Perhaps something like rawheader? (I believe the header
test is the only one for which :raw makes sense.)

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPE8s49023525; Fri, 25 Nov 2005 06:08:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAPE8sZb023524; Fri, 25 Nov 2005 06:08:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPE8r1J023515 for <[e-mail]>; Fri, 25 Nov 2005 06:08:53 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.124] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 25 Nov 2005 14:08:47 +0000
Message-ID: <[e-mail]>
Date: Fri, 25 Nov 2005 14:08:44 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Draft minutes from Vancouver
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>

Barry Leiba wrote:

> The minutes look good to me.

Ok, I've uploaded minutes to the ietf.org site
(<https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64>)

There is still time to correct them.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPDvboB021682; Fri, 25 Nov 2005 05:57:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAPDvbg2021681; Fri, 25 Nov 2005 05:57:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPDvaPV021674 for <[e-mail]>; Fri, 25 Nov 2005 05:57:36 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.124] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 25 Nov 2005 13:57:28 +0000
Message-ID: <[e-mail]>
Date: Fri, 25 Nov 2005 13:57:25 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Draft minutes from Vancouver
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>>8) Do we want to allow suppression of identical notifications?
>>
>>Greg: the answer might depend on whether we need to provide 
>>confidentiality. No consensus was reached, so the discussion should 
>>continue of the mailing list.
>>    
>>
>Greg: Please elaborate.  What do you mean by "confidentiality" in this
>context?
>
>Are "identical notifications" multiple executed notify actions with
>identical parameters in one script? Like:
>
>notify :method "mailto:[e-mail]";
>notify :method "mailto:[e-mail]";
>  
>
Yes (when all parameters are the same after performing variable 
expansion, if variables are also used).

>If the method is required,
>
It is not.

>and notify is a noop if none is given, then
>why the tagged argument and not a positional argument? Just curious.
>  
>
I was trying to keep backward compatibility with the deployed code.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPDXS3B017200; Fri, 25 Nov 2005 05:33:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAPDXSsW017199; Fri, 25 Nov 2005 05:33:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAPDXQmO017191 for <[e-mail]>; Fri, 25 Nov 2005 05:33:27 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.124] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 25 Nov 2005 13:32:52 +0000
Message-ID: <[e-mail]>
Date: Fri, 25 Nov 2005 13:32:44 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Ned Freed <[e-mail]>
CC: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: 'header' test and whitespace
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:

>> I see from Alexey's minutes that I was supposed to post the text that
>> I proposed.  I didn't remember that; sorry.  Philip started the
>> discussion, but didn't post the text.  I gave Philip XML, and here's
>> what I suggested:
>
>> <t>
>> Because the meaning of leading and trailing whitespace characters in 
>> header
>> fields is ambiguous, and their survival in message transport and 
>> processing
>> is inconsistent, ALL handling of message headers in Sieve MUST normalize
>> the header field values.  The normalization is similar to, but not 
>> the same
>> as, unfolding (see RFC2822),
>
> I think the unfolding part needs to be the same as what's in RFC 2822.

I agree.

> and is done as follows:
>
>> <list style="number">
>>    <t>
>>      Remove leading and trailing whitespace characters from each line of
>>      the header field (multiple lines, in the case of multi-line 
>> continuation).
>>    </t>
>
This step is actually not mentioned in RFC 2822.

>>    <t>
>>      Remove the delimiting CRLF from each line.
>>    </t>
>>    <t>
>>      Catenate the lines in order, inserting one ASCII space character 
>> (0x20)
>>      between each pair.
>
>
> This makes the unfolding different from what's in RFC 2822. I think 
> this is a
> mistake. There should not be any "insert space" operation here - RFC 2822
> section 2.2.3 simply calls for CRLFs to be removed.

[...]

>> Note that I didn't suggest RFC2047-decoding, but I think that's a 
>> reasonable
>> addition to this.  Alternatively, we could specify that strings be 
>> decoded
>> in comparisons (perhaps specified by an option like ":decode" or 
>> ":raw").
>
> A :raw option makes sense. I actually have no problem with adding it 
> to the
> base specification but others may disagree.

I am personally Ok with adding :raw to the base spec, but do we need a 
new capability?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAP2bcDF042544; Thu, 24 Nov 2005 18:37:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAP2bcO6042543; Thu, 24 Nov 2005 18:37:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by above.proper.com (8.12.11/8.12.9) with SMTP id jAP2ba4C042536 for <[e-mail]>; Thu, 24 Nov 2005 18:37:37 -0800 (PST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-11.tower-121.messagelabs.com!1132886250!6954426!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 24605 invoked from network); 25 Nov 2005 02:37:30 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-11.tower-121.messagelabs.com with SMTP; 25 Nov 2005 02:37:30 -0000
Received: from [135.70.18.44] (unknown[135.70.18.44](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20051125023729gw100lgg89e> (Authid: tony); Fri, 25 Nov 2005 02:37:29 +0000
Message-ID: <[e-mail]>
Date: Thu, 24 Nov 2005 21:37:28 -0500
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: 'header' test and whitespace
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed wrote:
> 
>> Because the meaning of leading and trailing whitespace characters
>> in header fields is ambiguous, and their survival in message
>> transport and processing is inconsistent, ALL handling of message
>> headers in Sieve MUST normalize the header field values. The
>> normalization is similar to, but not the same as, unfolding (see
>> RFC2822),
> 
> I think the unfolding part needs to be the same as what's in RFC 2822.

ditto

	Tony Hansen
	[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAP1b27G037112; Thu, 24 Nov 2005 17:37:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAP1b2GL037111; Thu, 24 Nov 2005 17:37:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAP1b0U9037100 for <[e-mail]>; Thu, 24 Nov 2005 17:37:01 -0800 (PST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 24 Nov 2005 17:36:56 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1132882615; h=Date: 	 From:Subject:MIME-version:Content-type; b=JZ1a367jcTZ6/3nHgQmAUsmlh cuMbvbD+qO9hbJr618Dc/OYYaGd5H28+PuX7UezbsOT7nBqL8EJMZlDsOR+tw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 24 Nov 2005 17:36:53 -0800 (PST)
Cc: [e-mail]
To: Barry Leiba <[e-mail]>
Message-id: <[e-mail]>
Date: Thu, 24 Nov 2005 17:30:47 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: 'header' test and whitespace
In-reply-to: "Your message dated Wed, 23 Nov 2005 22:26:25 -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]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I see from Alexey's minutes that I was supposed to post the text that
> I proposed.  I didn't remember that; sorry.  Philip started the
> discussion, but didn't post the text.  I gave Philip XML, and here's
> what I suggested:

> <t>
> Because the meaning of leading and trailing whitespace characters in header
> fields is ambiguous, and their survival in message transport and processing
> is inconsistent, ALL handling of message headers in Sieve MUST normalize
> the header field values.  The normalization is similar to, but not the same
> as, unfolding (see RFC2822),

I think the unfolding part needs to be the same as what's in RFC 2822.

 and is done as follows:
> <list style="number">
>    <t>
>      Remove leading and trailing whitespace characters from each line of
>      the header field (multiple lines, in the case of multi-line continuation).
>    </t>
>    <t>
>      Remove the delimiting CRLF from each line.
>    </t>
>    <t>
>      Catenate the lines in order, inserting one ASCII space character (0x20)
>      between each pair.

This makes the unfolding different from what's in RFC 2822. I think this is a
mistake. There should not be any "insert space" operation here - RFC 2822
section 2.2.3 simply calls for CRLFs to be removed.

>    </t>
> </list>
> </t>

> <t>
> To show how this normalization works, we use the character "~" (tilde) to
> represent the ASCII space character in the following example.
> This normalization will result in all of the following normalizing to the
> same value for the subject field, "a~b~~~c~d":
> <list style="empty">
>    <t>
>      Subject:~a~b~~~c~d
>    </t>
>    <t>
>      Subject:a~b~~~c~d~
>    </t>
>    <t>
>      Subject:a~b~~~c~
>      <vspace/>
>      ~~~~d~~
>    </t>
>    <t>
>      Subject:~~~~~a
>      <vspace/>
>      ~~~~b~~~c~~~~~
>      <vspace/>
>      ~~~~d
>    </t>
>    <t>
>      Subject:~a
>      <vspace/>
>      ~b~~~c
>      <vspace/>
>      ~d
>    </t>
> </list>
> </t>

I didn't bother going through all this.

> Note that I didn't suggest RFC2047-decoding, but I think that's a reasonable
> addition to this.  Alternatively, we could specify that strings be decoded
> in comparisons (perhaps specified by an option like ":decode" or ":raw").

A :raw option makes sense. I actually have no problem with adding it to the
base specification but others may disagree.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAOFO6L9070451; Thu, 24 Nov 2005 07:24:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAOFO6IV070450; Thu, 24 Nov 2005 07:24:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAOFO5fw070432 for <[e-mail]>; Thu, 24 Nov 2005 07:24:05 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (submission) with ESMTPA; Thu, 24 Nov 2005 15:23:57 +0000
Message-ID: <[e-mail]>
Date: Thu, 24 Nov 2005 15:23:56 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Extension "envelope-auth"?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Haardt wrote:

>Hello,
>
>some time ago, we talked about "envelope-auth" to introduce "auth" to the
>envelope test, which accesses the authenticated sender (AUTH parameter
>in MAIL FROM, in case the mail system decides not to ignore it, and an
>empty string otherwise).
>
>Is there a draft already or somebody working on it?
>  
>
If I remember correctly Ned has volunteered to author it.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAO3QX9M073816; Wed, 23 Nov 2005 19:26:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAO3QXip073815; Wed, 23 Nov 2005 19:26:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAO3QWcv073803 for <[e-mail]>; Wed, 23 Nov 2005 19:26:32 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jAO3SQiL014977 for <[e-mail]>; Wed, 23 Nov 2005 22:28:27 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jAO3QQn337938 for <[e-mail]>; Wed, 23 Nov 2005 22:26:26 -0500
Received: from [9.12.233.226] ([9.12.233.226]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jAO3QPN346350 for <[e-mail]>; Wed, 23 Nov 2005 22:26:25 -0500
Message-ID: <[e-mail]>
Date: Wed, 23 Nov 2005 22:26:25 -0500
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: 'header' test and whitespace
References: <[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>

I see from Alexey's minutes that I was supposed to post the text that
I proposed.  I didn't remember that; sorry.  Philip started the
discussion, but didn't post the text.  I gave Philip XML, and here's
what I suggested:

<t>
Because the meaning of leading and trailing whitespace characters in header
fields is ambiguous, and their survival in message transport and processing
is inconsistent, ALL handling of message headers in Sieve MUST normalize
the header field values.  The normalization is similar to, but not the same
as, unfolding (see RFC2822), and is done as follows:
<list style="number">
   <t>
     Remove leading and trailing whitespace characters from each line of
     the header field (multiple lines, in the case of multi-line continuation).
   </t>
   <t>
     Remove the delimiting CRLF from each line.
   </t>
   <t>
     Catenate the lines in order, inserting one ASCII space character (0x20)
     between each pair.
   </t>
</list>
</t>

<t>
To show how this normalization works, we use the character "~" (tilde) to
represent the ASCII space character in the following example.
This normalization will result in all of the following normalizing to the
same value for the subject field, "a~b~~~c~d":
<list style="empty">
   <t>
     Subject:~a~b~~~c~d
   </t>
   <t>
     Subject:a~b~~~c~d~
   </t>
   <t>
     Subject:a~b~~~c~
     <vspace/>
     ~~~~d~~
   </t>
   <t>
     Subject:~~~~~a
     <vspace/>
     ~~~~b~~~c~~~~~
     <vspace/>
     ~~~~d
   </t>
   <t>
     Subject:~a
     <vspace/>
     ~b~~~c
     <vspace/>
     ~d
   </t>
</list>
</t>


Note that I didn't suggest RFC2047-decoding, but I think that's a reasonable
addition to this.  Alternatively, we could specify that strings be decoded
in comparisons (perhaps specified by an option like ":decode" or ":raw").

Barry

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAO3LFFF073072; Wed, 23 Nov 2005 19:21:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAO3LFGd073070; Wed, 23 Nov 2005 19:21:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAO3LE6F073042 for <[e-mail]>; Wed, 23 Nov 2005 19:21:14 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jAO3N9LL013956 for <[e-mail]>; Wed, 23 Nov 2005 22:23:09 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jAO3L8n246892 for <[e-mail]>; Wed, 23 Nov 2005 22:21:08 -0500
Received: from [9.12.233.226] ([9.12.233.226]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jAO3L7N198386 for <[e-mail]>; Wed, 23 Nov 2005 22:21:08 -0500
Message-ID: <[e-mail]>
Date: Wed, 23 Nov 2005 22:21:07 -0500
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Draft minutes from Vancouver
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The minutes look good to me.

Barry

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAO3KcHd072890; Wed, 23 Nov 2005 19:20:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAO3KcBc072889; Wed, 23 Nov 2005 19:20:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAO3KcJk072854 for <[e-mail]>; Wed, 23 Nov 2005 19:20:38 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jAO3MWax013884 for <[e-mail]>; Wed, 23 Nov 2005 22:22:32 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jAO3KVn149380 for <[e-mail]>; Wed, 23 Nov 2005 22:20:31 -0500
Received: from [9.12.233.226] ([9.12.233.226]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jAO3KVN255542 for <[e-mail]>; Wed, 23 Nov 2005 22:20:31 -0500
Message-ID: <[e-mail]>
Date: Wed, 23 Nov 2005 22:20:31 -0500
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: 'header' test and whitespace
References: <[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>

> You lost me somewhere.  Do you mean:
> 
> Headers accessed by Sieve are always: Unfolded, stripped of heading and
> trailing white space and MIME-decoded?

I didn't lose you; you got it, yes.

> If so, that would make a raw header test/comparison impossible.

OK; I'm happy to have an explicit "leave it raw" function.  Lacking that,
I would like to see them normalized.

Barry

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jANNFsTw044165; Wed, 23 Nov 2005 15:15:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jANNFsOZ044164; Wed, 23 Nov 2005 15:15:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jANNFrYe044158 for <[e-mail]>; Wed, 23 Nov 2005 15:15:54 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1Ef3qD-000188-A4 for [e-mail]; Thu, 24 Nov 2005 00:15:53 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx0.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 #12) id 1Ef3qD-0001f2-84 for [e-mail]; Thu, 24 Nov 2005 00:15:53 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.60-RC2 #1) id 1Ef3qC-0008BR-3p for [e-mail]; Thu, 24 Nov 2005 00:15:52 +0100
Date: Thu, 24 Nov 2005 00:15:52 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Extension "envelope-auth"?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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>

Hello,

some time ago, we talked about "envelope-auth" to introduce "auth" to the
envelope test, which accesses the authenticated sender (AUTH parameter
in MAIL FROM, in case the mail system decides not to ignore it, and an
empty string otherwise).

Is there a draft already or somebody working on it?

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jANMtGg3041908; Wed, 23 Nov 2005 14:55:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jANMtGK4041907; Wed, 23 Nov 2005 14:55:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jANMtFgb041901 for <[e-mail]>; Wed, 23 Nov 2005 14:55:16 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtpa (Exim 4.53-RC2) id 1Ef3WE-0003Aw-L6 for [e-mail]; Wed, 23 Nov 2005 23:55:14 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx2.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 #12) id 1Ef3WE-0008C6-Jx for [e-mail]; Wed, 23 Nov 2005 23:55:14 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.60-RC2 #1) id 1Ef3WA-0008Ac-7S for [e-mail]; Wed, 23 Nov 2005 23:55:10 +0100
Date: Wed, 23 Nov 2005 23:55:10 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: 'header' test and whitespace
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.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 Tue, Nov 22, 2005 at 12:27:38PM -0500, Barry Leiba wrote:
> > Both UCB mail and mutt do compress whitespace at fold points for the
> > overview and show all whitespace at fold points when displaying the
> > message, including the newline.  Both surprises me, and I do not like it.
> 
> It's that inconsistency that prompts this suggestion.  Behaviour is so 
> varied
> that I'd rather see us define something predictable.

"Varied" is a nice word for what I consider a "bug".  Unfolding as
specified in RFC 2822 is easy to understand and logical to me, yet
two MUAs decide to break it in two different ways.  I agree we should
say something about it.

> That said, there's Kjetil's comment:
> 
> > so I don't think it matters much in practice.  so my conclusion is:
> > don't confuse matters even more by adding Sieve specific unfolding
> > rules.
> 
> There's definitely something to be said for us to just point to the RFC2822
> unfolding rule, and not define our own.

You have my vote for that.

> I'll be happy with whatever decision we make about the whitespace at the 
> fold
> points, but I prefer compressing it to one space there.  I will NOT be happy
> if we don't strip leading and trailing whitespace on the overall unfolded
> field value.  Moreover, I think another important point in what I suggested
> is that this stripping be done ANY TIME Sieve touches a header field value,
> NOT JUST IN COMPARISONS.  If we stick the value into a variable and then
> compare against the variable, the behaviour must be the same as if we
> compare against the header field value directly, which means that the
> leading and trailing whitespace must be stripped when the value is put into
> the variable in the first place.

You lost me somewhere.  Do you mean:

Headers accessed by Sieve are always: Unfolded, stripped of heading and
trailing white space and MIME-decoded?

If so, that would make a raw header test/comparison impossible.  I suggest
that specific tests and actions define if they do the above, and I have
no problems if variable assignments do, but a requirement in the base spec
that all operations on headers must work that way sounds limiting to me.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jANM9gj7035987; Wed, 23 Nov 2005 14:09:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jANM9giF035986; Wed, 23 Nov 2005 14:09:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jANM9fhR035977 for <[e-mail]>; Wed, 23 Nov 2005 14:09:41 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1Ef2o8-0006om-3U for [e-mail]; Wed, 23 Nov 2005 23:09:40 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 #12) id 1Ef2o8-0001o1-29 for [e-mail]; Wed, 23 Nov 2005 23:09:40 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.60-RC2 #1) id 1Ef2o6-00088q-MT for [e-mail]; Wed, 23 Nov 2005 23:09:38 +0100
To: [e-mail]
Subject: Re: Draft minutes from Vancouver
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Date: Wed, 23 Nov 2005 23:09:38 +0100
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>

> 8) Do we want to allow suppression of identical notifications?
>
> Greg: the answer might depend on whether we need to provide 
> confidentiality. No consensus was reached, so the discussion should 
> continue of the mailing list.

Greg: Please elaborate.  What do you mean by "confidentiality" in this
context?

Are "identical notifications" multiple executed notify actions with
identical parameters in one script? Like:

notify :method "mailto:[e-mail]";
notify :method "mailto:[e-mail]";

If the method is required, and notify is a noop if none is given, then
why the tagged argument and not a positional argument? Just curious.

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jANJutGv021627; Wed, 23 Nov 2005 11:56:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jANJut4j021626; Wed, 23 Nov 2005 11:56:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jANJur6F021620 for <[e-mail]>; Wed, 23 Nov 2005 11:56:54 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (submission) with ESMTPA; Wed, 23 Nov 2005 19:56:40 +0000
Message-ID: <[e-mail]>
Date: Wed, 23 Nov 2005 19:56:38 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: Draft minutes from Vancouver
MIME-version: 1.0
Content-type: text/plain; charset="KOI8-R"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi folks,
Below are the draft minutes I've produced from the Jabber logs. (Thanks 
to Tony Hansen for scribing in Jabber!) Please send any comments on 
correctness/completeness. Editorial comments are welcome as well.
=========

The meeting has started with a quick review of documents ready for IESG 
writeup (or nearly ready). The vacation extension has two minor 
outstanding issues: clarification on how hash should be constructed when 
some tagged arguments like :subject are omitted; default auto reply 
subject when the original message had no subject.

Scott Hollenbeck has asked what was the resolution on "multiple executed 
vacation actions in a script". Alexey has replied that after a long 
discussion on the mailing list there was no change in the behaviour of 
the vacation action.

 

Spamtest, imap flags, relational extensions are ready for IESG writeup.

Edit header needs to say something about stripping leading/trailing 
spaces, but it is done otherwise. Barry has mentioned that the 
relational draft got bounced by Internet Draft editor, resubmitted.

 

The body draft is waiting for resolution on comparators in the base 
document, but otherwise is done. Once comparator issues are addressed, 
the body can be revised in a couple of days.

 

IESG has raised a discuss comment on Sieve variables: ":lower" and 
":upper" were underspecified, the vague text about using comparators is 
not good enough to implement. Two ways to solve the issue:

a). just say that :lower and :upper only affect US-ASCII subset, other 
characters are not affected;

b). do stringprep like approach (full Unicode).

 

Several people are in favour of US-ASCII-only approach, which is 
perceived to be quicker and will satisfy IESG. 6 people in the room are 
in favour of US-ASCII-only approach, plus some more in jabber. No people 
objecting. Need to confirm the decision on the mailing list.

 

Alexey has expressed his desire to get resolution on comparators by the 
end of November.

 

There are several open issues with the base document:

1). ABNF for match types (done)

2). Matching uses glob characters, but is not fully specified in the 
document. Need to clarify that matching depends on substring operation 
of collation.

3). Base spec and variables: Clarify that when matching is done then 
pieces of the original value are returned in match variables, not the 
result of applying the selected comparator.

4). Stripping leading/trailing whitespaces in the relational draft - 
text needs to be moved to the base spec.

 

Short discussion about Barry's proposal to string leading/trailing 
whitespaces any time a header field is touched. No objections from 
people who've seen the new text (Alexey, Philip). Barry will send the 
text to the mailing list.

 

Philip has promised a new revision of base document by November 18th.

 

Alexey has talked about the notification draft. Received many comments, 
much more than expected :-). Separate documents will be created for 
different Sieve notification methods.

 

Alexey & Barry will co-edit the main notification document. Barry & 
Michael will co-edit SMTP notification draft. Alexey will do XMPP, but 
need a co-editor. Peter Saint-Andre has agreed to co-edit. No editor for 
SMS notifications, but Stephane might be working on the drafts.

 

Discussion about SMS has followed: what does it mean to implement SMS 
notifications, what kind of payload is used (do we need multiple 
different ones?), what kind of parameters are needed, how payload is 
generated and delivered, etc. Ray Cromwell has mentioned that there are 
a lot of requests to limit number of SMS generated per day, in order to 
limit cost. Discussion on whether URIs are the best way to specify 
notification methods and whether a generic Lemonade notification method 
should be defined. Discussion on complexity of different SMS gateways - 
different gateways need different parameters, in most cases users of 
Sieve scripts wouldn't care about such parameters. Consensus from the 
group that it is too premature to discuss details until we see a first 
revision of the SMS notification draft.

 

A detailed discussion about current issues in the base Sieve 
Notifications document has followed. Alexey has presented open issues.

1) Many people have requested to remove "denotify", it will be removed 
in the next revision, as there were no requests to keep it.

2) Comments from Jabber that "mailto" should be a mandatory to implement 
notification method, as Sieve engines already able to send mail.

3) Need a way to extract textual message body. Kjetil's suggestion will 
not work, as "body" extension explicitly prohibits setting variables on 
body test. Barry has mentioned that we need the ability to send the 
whole body as well as first starting bytes.

Alexey has asked Philip if "body" can be changed to relax the 
restriction? Philip said "no", "body" is already widely deployed. If 
body extraction is only useful for Sieve notification, we can add it to 
the Sieve notifications document. Otherwise we need a separate 
extension. Decision to bring the issue to the mailing list.

4) Can notification method parameter be optional (i.e. if not present - 
use site specific default. If no default - noop)?

Barry: keep it optional; if there is no default - "notify" action is a 
noop. No objections from the room.

5) What should happen if an unrecognized notification method is 
specified in the "notify" action? Error or ignored?

Alexey: scripts can't have "require" statements for notification 
methods, because a notification method can be specified as a variable, 
who's value can be obtained from an external service.

Do we need to add a test "if a notification method is available"?  One 
use case is when notification method is stored as an IMAP server 
annotation. Agreement to add the test.

<>Once the room has agreed to add the test for available notification 
methods, the room has reached the agreement to make an unrecognised 
notification method an error.
 

Cyrus (in Jabber) suggested to add ManageSieve protocol capability to 
advertise supported notification methods. The room agrees.

Cyrus suggested Sieve presence extension, so notification types can be 
customized based on presence and time of day. (The latter is already 
possible using Ned's time extension).

6) Add :from to the "notify" action? It is useful for all envisioned 
notification mechanisms, but it might not be generally useful. However a 
notification method is free to ignore the parameter. No objection from 
the room.

7) Ned (in Jabber) is bringing another issue: URI formats need URI 
"percent encoding" for different values, inserting variables into an URI 
will not work. He would like to avoid options, but can't see a way to do 
without them.

8) Do we want to allow suppression of identical notifications?

Greg: the answer might depend on whether we need to provide 
confidentiality. No consensus was reached, so the discussion should 
continue of the mailing list.

 

Discussion about status of refuse/reject. Most people don't know the 
difference between MDNs, DSNs and protocol-level-refusal. Would script 
writer really care? Consensus from the room that script writers wouldn't 
care, so refuse and reject can be merged into a single action 
("reject"). Confirm the decision on the mailing list.

Cyrus has pointed out that sysadmins care about protocol-level refusals 
versa DSNs, however the draft is already recommending protocol level 
refusals whenever possible.

Cyrus said that non-ascii text in the reject action can't be sent as a 
protocol level refusal. Ned added that if non-ascii text results in 
DSNs, sysadmins will disallow users to use the reject action. The draft 
needs more work in this area.

Alexey and Philip will discuss if it make sense to put the new reject 
back into the base Sieve document.

 

WG has covered the main agenda items. Barry will publish a new 
individual submission that describes how Sieve can be executed in IMAP 
store on different events, such as flag changes, message deletion, etc. 
He believes that this will require a small extension to Sieve and a 
detailed description on how this would work on IMAP side.

 

Discussion of the main documents has concluded, so the room has 
discussed other Sieve related issues.

 

<>Nobody wanted to talk about index or include extensions.
<>
Cyrus will address scoping issue and he hopes that this is going to be 
independent of the variables draft, i.e. it will be an extension to 
variables.

<>Philip has promised a new revision of the base document on November 18th.
 

Dave Cridland (in jabber) has asked about outcome of the comparator 
discussion. Philip did a quick review of the discussion that happened 
during the IMAPEXT meeting few days earlier. Match type is built on 
comparator's substring matching. <?> matches a single character as 
defined by the comparator (e.g. octet or sequence of UTF-8 octets 
corresponding to a single Unicode character).

Alexey has asked the WG and IMAPEXT chairs if the collation (comparator) 
draft should be done in the Sieve WG, as it is moving much faster than 
IMAPEXT. The answer was no, as most people are participating in both 
working groups. Chairs of both WGs should nag authors of the collation 
draft to move it forward quicker.

<>
<>Variables need to be updated to say that matching with glob characters 
returns pieces of the original string, i.e. before any comparator was 
applied. Alexey wants to send the variables document back to IESG asap.
 
Regards,
Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMHiKIT098381; Tue, 22 Nov 2005 09:44:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAMHiKRw098380; Tue, 22 Nov 2005 09:44:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMHiJYi098373 for <[e-mail]>; Tue, 22 Nov 2005 09:44:19 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.159] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Nov 2005 17:43:44 +0000
Message-ID: <[e-mail]>
Date: Tue, 22 Nov 2005 17:43:44 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-3431bis-02.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Barry Leiba wrote:

>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Sieve Mail Filtering Language 
>> Working Group of the IETF.
>>
>>     Title        : Sieve Extension: Relational Tests
>>     Author(s)    : W. Segmuller, B. Leiba
>>     Filename    : draft-ietf-sieve-3431bis-02.txt
>>     Pages        : 14
>>     Date        : 2005-11-21
>
> Alexey, this is ready for IETF last call now.

My recollection is that you've addressed both editorial and 
non-editorial issues raised during WGLC. I don't think another WGLC is 
needed.
Any other opinions?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMHRjFZ096510; Tue, 22 Nov 2005 09:27:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAMHRjos096509; Tue, 22 Nov 2005 09:27:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMHRihn096497 for <[e-mail]>; Tue, 22 Nov 2005 09:27:45 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jAMHTdED023285 for <[e-mail]>; Tue, 22 Nov 2005 12:29:39 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jAMHRcn275074 for <[e-mail]>; Tue, 22 Nov 2005 12:27:38 -0500
Received: from [9.12.233.226] ([9.12.233.226]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jAMHRcN345722 for <[e-mail]>; Tue, 22 Nov 2005 12:27:38 -0500
Message-ID: <[e-mail]>
Date: Tue, 22 Nov 2005 12:27:38 -0500
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: 'header' test and whitespace
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned says...
>> So, there are three choices:
>> 1) just compress whitespace at fold points
>> 2) compress all whitespace
>> 3) no compression
> 
> I strongly object to (1) and (2). Making the header test not respect interior
> spaces is a _really_ bad idea. Like it or not, there are communities that are
> very sensitive to spacing issues (many Japanese users seem to qualify) and
> these communites need to be able to test and see exactly what sorts of spaces
> are present in fields (and possibly modify them).

I proposed (1), and am not fond of (2); given Ned's statement and the comments
from Michael and Kjetil, I think it's clear that (2) is out.

> I have no problem with removing whitespace at the beginning of the field - in
> fact I prefer it. I think removing trailing whitespace has a chance of causing
> problems, but the benefits probably equal if not exceed the costs.

I agree.
But the same reasoning is why I suggested (1).  See Michael's comment:

 > Both UCB mail and mutt do compress whitespace at fold points for the
 > overview and show all whitespace at fold points when displaying the
 > message, including the newline.  Both surprises me, and I do not like it.

It's that inconsistency that prompts this suggestion.  Behaviour is so varied
that I'd rather see us define something predictable.

That said, there's Kjetil's comment:

 > so I don't think it matters much in practice.  so my conclusion is:
 > don't confuse matters even more by adding Sieve specific unfolding
 > rules.

There's definitely something to be said for us to just point to the RFC2822
unfolding rule, and not define our own.

I'll be happy with whatever decision we make about the whitespace at the fold
points, but I prefer compressing it to one space there.  I will NOT be happy
if we don't strip leading and trailing whitespace on the overall unfolded
field value.  Moreover, I think another important point in what I suggested
is that this stripping be done ANY TIME Sieve touches a header field value,
NOT JUST IN COMPARISONS.  If we stick the value into a variable and then
compare against the variable, the behaviour must be the same as if we
compare against the header field value directly, which means that the
leading and trailing whitespace must be stripped when the value is put into
the variable in the first place.

Barry

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMHG3EM094918; Tue, 22 Nov 2005 09:16:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAMHG3V6094917; Tue, 22 Nov 2005 09:16:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMHG2la094906 for <[e-mail]>; Tue, 22 Nov 2005 09:16:03 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jAMHHvO9020812 for <[e-mail]>; Tue, 22 Nov 2005 12:17:57 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jAMHFvn162456 for <[e-mail]>; Tue, 22 Nov 2005 12:15:57 -0500
Received: from [9.12.233.226] ([9.12.233.226]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jAMHFsN320056 for <[e-mail]>; Tue, 22 Nov 2005 12:15:56 -0500
Message-ID: <[e-mail]>
Date: Tue, 22 Nov 2005 12:15:54 -0500
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-sieve-3431bis-02.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.
> 
> 	Title		: Sieve Extension: Relational Tests
> 	Author(s)	: W. Segmuller, B. Leiba
> 	Filename	: draft-ietf-sieve-3431bis-02.txt
> 	Pages		: 14
> 	Date		: 2005-11-21

Alexey, this is ready for IETF last call now.

Barry

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMHEFBx094658; Tue, 22 Nov 2005 09:14:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAMHEE2a094656; Tue, 22 Nov 2005 09:14:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMHEC8n094646 for <[e-mail]>; Tue, 22 Nov 2005 09:14:13 -0800 (PST) (envelope-from [e-mail])
Received: from sp1n294en1.watson.ibm.com (sp1n294en1.watson.ibm.com [129.34.20.40]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id jAMHG6qi020532; Tue, 22 Nov 2005 12:16:07 -0500
Received: from sp1n294en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id jAMHE6n339262; Tue, 22 Nov 2005 12:14:06 -0500
Received: from [9.12.233.226] ([9.12.233.226]) by sp1n294en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id jAMHE5N198480; Tue, 22 Nov 2005 12:14:06 -0500
Message-ID: <[e-mail]>
Date: Tue, 22 Nov 2005 12:14:05 -0500
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Alexey Melnikov <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Missing some information for the Vancouver minutes
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 1) Add :from tagged argument to the "notify" action?
> 
> Did anybody objected to this?

I objected to the idea of general parameters, which might not apply to
specific notification mechanisms.  I prefer to have the definitions of
all parameters be in the mechanism documents.

But this is a small objection -- certainly notification text and "from"
are not unreasonable things to have as global things, and a mechanism
that doesn't need the "from" (or the text, for that matter) can ignore it.

> 2) Allow suppression of identical Sieve notifications?
> 
> Did we reach any consensus on this?

I don't recall.  I remember the discussion, but I really don't remember
where it went or what the resolution was.

Barry

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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMD3K1k057061; Tue, 22 Nov 2005 05:03:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAMD3K7u057060; Tue, 22 Nov 2005 05:03:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMD3JGM057051 for <[e-mail]>; Tue, 22 Nov 2005 05:03:19 -0800 (PST) (envelope-from [e-mail])
Received: from [194.97.55.148] (helo=mx5.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.53-RC2) id 1EeXnq-0005f0-26 for [e-mail]; Tue, 22 Nov 2005 14:03:18 +0100
Received: from nostromo.freenet-ag.de ([194.97.7.6]) by mx5.freenet.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54 #12) id 1EeXnp-0005Wk-Th for [e-mail]; Tue, 22 Nov 2005 14:03:17 +0100
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.60-RC2 #1) id 1EeXnl-0005sE-1g for [e-mail]; Tue, 22 Nov 2005 14:03:13 +0100
Date: Tue, 22 Nov 2005 14:03:13 +0100
From: Michael Haardt <[e-mail]>
To: [e-mail]
Subject: Re: 'header' test and whitespace
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>

On Mon, Nov 21, 2005 at 04:40:10PM -0800, Ned Freed wrote:
> > So, there are three choices:
> > 1) just compress whitespace at fold points
> > 2) compress all whitespace
> > 3) no compression
> 
> I strongly object to (1) and (2). Making the header test not respect interior
> spaces is a _really_ bad idea. Like it or not, there are communities that are
> very sensitive to spacing issues (many Japanese users seem to qualify) and
> these communites need to be able to test and see exactly what sorts of spaces
> are present in fields (and possibly modify them).

I think the same logic that led to the consensus of stripping trailing white
space might help:

  How does the MUA present the header?

MUAs do not compress all whitespace.  If Sieve did, comparisons would not
work as the user expects them to.  To me, that's a second reason against
(2).

Both UCB mail and mutt do compress whitespace at fold points for the
overview and show all whitespace at fold points when displaying the
message, including the newline.  Both surprises me, and I do not like it.
So much for logic. ;-)

Not looking at MIME, (1) might remove white spaces that were originally
part of the message, but happened to be at the folding position.
I dislike the thought of not seeing the original content.

As a result, I vote for (3).

Michael



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMCIxUx053042; Tue, 22 Nov 2005 04:18:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAMCIxUt053041; Tue, 22 Nov 2005 04:18:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAMCIwLv053023 for <[e-mail]>; Tue, 22 Nov 2005 04:18:58 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1EeX6q-000184-28; Tue, 22 Nov 2005 13:18:52 +0100
Received: from mattugur.ifi.uio.no ([129.240.68.168]) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EeX6k-0006w1-4H; Tue, 22 Nov 2005 13:18:46 +0100
Subject: Re: 'header' test and whitespace
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Date: Tue, 22 Nov 2005 13:18:45 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.682, required 12, autolearn=disabled, AWL -0.68, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2005-11-21 at 16:17 -0800, Philip Guenther wrote:
> So, there are three choices:
> 1) just compress whitespace at fold points
> 2) compress all whitespace
> 3) no compression

the unfold logic is too complex for most authors of e-mail software, it
seems, and a "compress whitespace" rule might make life easier for them.
however, they will probably still screw up

Subject: This RFC 2047 thingy is =?UTF-8?Q?p?=
 =?UTF-8?Q?icky?=

so I don't think it matters much in practice.  so my conclusion is:
don't confuse matters even more by adding Sieve specific unfolding
rules.

> Note that we had previously agreed that leading and trailing
> whitespace on the field value in total should be completely ignored;
> that would not be affected by the compression described above.

I don't see why we need to strip trailing whitespace, but I don't feel
strongly about it.
-- 
Kjetil T.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAM0p9s6065914; Mon, 21 Nov 2005 16:51:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAM0p9CD065913; Mon, 21 Nov 2005 16:51:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAM0p8Um065907 for <[e-mail]>; Mon, 21 Nov 2005 16:51:08 -0800 (PST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Mon, 21 Nov 2005 16:51:04 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1132620664; h=Date: 	 From:Subject:MIME-version; b=nTeUrau+2a350CUUNRpI5E3LaggErB41+6eBdC 5Bi2yaPH/tDYOKAdu3veEYa7dZlYOUDnLPmypJ8evPktOdFA==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 21 Nov 2005 16:50:59 -0800 (PST)
Cc: MTA filtering mailing list <[e-mail]>
To: Philip Guenther <[e-mail]>
Message-id: <[e-mail]>
Date: Mon, 21 Nov 2005 16:40:10 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: 'header' test and whitespace
In-reply-to: "Your message dated Mon, 21 Nov 2005 16:17:22 -0800" <[e-mail]>
MIME-version: 1.0
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> First of all, my apologies to the list for failing to get out the
> updated 3028bis I-D by last Friday as I promised.

Haven't gotten the revised vacation draft out either ;-(

> Part of the hold up has been in determining the exact wording to
> insert on a couple points.  In particular, Barry Leiba argued
> strongly in Vancouver that the 'header' test should _at_least_
> normalize to a single space all whitespace that appears at the
> beginning or end of each line of a header field value.  That is,
> the header field unfolding algorithm would not only remove the CRLF
> pair but also compress the whitespace around the CRLF into a single
> space.

> Alternatively, that same compression could be applied to *all* the
> embedded whitespace in the field value, such that the 'header' test
> would never 'see' tabs or consecutive spaces.

> So, there are three choices:
> 1) just compress whitespace at fold points
> 2) compress all whitespace
> 3) no compression

I strongly object to (1) and (2). Making the header test not respect interior
spaces is a _really_ bad idea. Like it or not, there are communities that are
very sensitive to spacing issues (many Japanese users seem to qualify) and
these communites need to be able to test and see exactly what sorts of spaces
are present in fields (and possibly modify them).

Additionally, compression down to a single space is actually insufficient in
some cases - what's needed is for spaces to be removed, not compressed. But
this can, and should, be done through an appropriately defined comparator. It
should not be a built in part of the header test.

> Note that we had previously agreed that leading and trailing
> whitespace on the field value in total should be completely ignored;
> that would not be affected by the compression described above.

I have no problem with removing whitespace at the beginning of the field - in
fact I prefer it. I think removing trailing whitespace has a chance of causing
problems, but the benefits probably equal if not exceed the costs.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAM0HNJ9062463; Mon, 21 Nov 2005 16:17:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAM0HNOJ062462; Mon, 21 Nov 2005 16:17:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAM0HNkU062456 for <[e-mail]>; Mon, 21 Nov 2005 16:17:23 -0800 (PST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAM0HMM5013624 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for <[e-mail]>; Mon, 21 Nov 2005 16:17:22 -0800
X-DKIM: Sendmail DKIM Filter v0.1.1 foon.sendmail.com jAM0HMM5013624
DKIM-Signature: a=rsa-sha1; c=nowsp; d=sendmail.com; s=tls.dkim; t=1132618643; h=X-DomainKeys:DomainKey-Signature:Received: Message-Id:To:From:Subject:Date:Sender:X-ok-sendmail.com; b=DcZOeOe 0utaIjOtEvTwE5tzsE1PGDGFRse62t+4WNPHGHkeGWswHskRVj1PK5XpmhgblAai6pe F3Osg4vyl1Lu1rPTyew2YWaCXPTHuLqzqYq8fo+8sAfaqRc7HPnH+dmVu6HWF5pWERq sg8ApeHOgUywmpJmxAxn/o4zE2WCCU=
X-DomainKeys: Sendmail DomainKeys Filter v0.3.0 foon.sendmail.com jAM0HMM5013624
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=received:message-id:to:from:subject:date:sender:x-ok-sendmail.com; b=OoHat7TezkfXi1eXCa5Gc/vHD+NubvrgP00vCMAVxNTc+Odv6Uq5nZ7ZH3J4PFfo+ HvFnLV4c7H34IAzjjqaApAhR0TjBl7wwhg8D0tYnrkusCGdjnOQ0uGiWi0Z5/Cl1g4l GzrvAKRVTHEsTxXb/aBX/mpU7AuoHALbnY0ZIyY=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id jAM0HMnl072051 for <[e-mail]>; Mon, 21 Nov 2005 16:17:22 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: MTA filtering mailing list <[e-mail]>
From: Philip Guenther <[e-mail]>
Subject: 'header' test and whitespace
Date: Mon, 21 Nov 2005 16:17:22 -0800
X-ok-sendmail.com: Yes
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>

First of all, my apologies to the list for failing to get out the
updated 3028bis I-D by last Friday as I promised.

Part of the hold up has been in determining the exact wording to
insert on a couple points.  In particular, Barry Leiba argued
strongly in Vancouver that the 'header' test should _at_least_
normalize to a single space all whitespace that appears at the
beginning or end of each line of a header field value.  That is,
the header field unfolding algorithm would not only remove the CRLF
pair but also compress the whitespace around the CRLF into a single
space.

Alternatively, that same compression could be applied to *all* the
embedded whitespace in the field value, such that the 'header' test
would never 'see' tabs or consecutive spaces.


So, there are three choices:
1) just compress whitespace at fold points
2) compress all whitespace
3) no compression


Note that we had previously agreed that leading and trailing
whitespace on the field value in total should be completely ignored;
that would not be affected by the compression described above.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jALNrUW7059658; Mon, 21 Nov 2005 15:53:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jALNrUd0059656; Mon, 21 Nov 2005 15:53:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jALNrTkU059647 for <[e-mail]>; Mon, 21 Nov 2005 15:53:29 -0800 (PST) (envelope-from [e-mail])
Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jALNrS4u027992; Mon, 21 Nov 2005 15:53:29 -0800 (PST)
Received: from we-gotmail.red.iplanet.com (gotmail-2.red.iplanet.com [192.18.73.252]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jALNrSTe013150; Mon, 21 Nov 2005 15:53:28 -0800 (PST)
Received: from [10.1.110.62] by we-gotmail.red.iplanet.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTPSA id <[e-mail]>; Mon, 21 Nov 2005 15:53:24 -0800 (PST)
Date: Mon, 21 Nov 2005 15:53:19 -0800
From: Kristin Hubner <[e-mail]>
Subject: Re: Confirming WG consensus: combine reject and refuse into a single action
In-reply-to: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Apple Mail (2.622)
Content-type: text/plain; charset=US-ASCII; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Nov 18, 2005, at 7:49 AM, Alexey Melnikov wrote:

>
> Hi folks,
> During the Vancouver IETF people in the room have agreed that Sieve 
> writers don't care about difference between MDNs, DSNs and protocol 
> level refusals. So refuse and reject actions will be combined into a 
> single action, which will generate protocol level refusals, MDNs or 
> DSNs, depending on what is appropriate. If anybody objects to this 
> decision, please speak up now.
>
> Alexey

As long as the "combined" action would have the ability to deal with
the charset issues, I don't object.

That is, I'd like to see not only an ability to specify non-US-ASCII
rejection text, but also a way to choose whether the use of
the non-US-ASCII reject text is mandatory (hence disabling SMTP
level rejection -- user prefers to use their own text rather than
get SMTP level rejection), or optional (used only when an inability
to do an SMTP level rejection for other reasons has already caused
"fall back" to the DSN or MDN approach).  That way, we could
satisfy the users who really, really want their own rejection text
used, and the users who want SMTP level rejection when possible but
when not possible want then to go ahead and use some non-US-ASCII
rejection text.

Regards,

Kristin



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jALNo3M3057656; Mon, 21 Nov 2005 15:50:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jALNo3Vh057655; Mon, 21 Nov 2005 15:50:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jALNo25P057632 for <[e-mail]>; Mon, 21 Nov 2005 15:50:02 -0800 (PST) (envelope-from [e-mail])
Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EeLQ9-00086y-UM; Mon, 21 Nov 2005 18:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-sieve-3431bis-02.txt 
Message-Id: <[e-mail]>
Date: Mon, 21 Nov 2005 18:50:01 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Sieve Extension: Relational Tests
	Author(s)	: W. Segmuller, B. Leiba
	Filename	: draft-ietf-sieve-3431bis-02.txt
	Pages		: 14
	Date		: 2005-11-21
	
This document describes the RELATIONAL extension to the Sieve mail
   filtering language defined in RFC 3028.  This extension extends
   existing conditional tests in Sieve to allow relational operators.
   In addition to testing their content, it also allows for testing of
   the number of entities in header and envelope fields.

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

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


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

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


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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-sieve-3431bis-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

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

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

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

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

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

--OtherAccess--

--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAJGkEvS061999; Sat, 19 Nov 2005 08:46:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAJGkEuB061998; Sat, 19 Nov 2005 08:46:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAJGkDQ1061991 for <[e-mail]>; Sat, 19 Nov 2005 08:46:13 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (submission) with ESMTPA; Sat, 19 Nov 2005 16:45:48 +0000
Message-ID: <[e-mail]>
Date: Fri, 18 Nov 2005 15:49:42 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Confirming WG consensus: combine reject and refuse into a single action
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>

Hi folks,
During the Vancouver IETF people in the room have agreed that Sieve 
writers don't care about difference between MDNs, DSNs and protocol 
level refusals. So refuse and reject actions will be combined into a 
single action, which will generate protocol level refusals, MDNs or 
DSNs, depending on what is appropriate. If anybody objects to this 
decision, please speak up now.

Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAJGkE3q062007; Sat, 19 Nov 2005 08:46:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAJGkEoT062006; Sat, 19 Nov 2005 08:46:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAJGkDQ2061991 for <[e-mail]>; Sat, 19 Nov 2005 08:46:14 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.0.2] ([62.3.217.253]) by rufus.isode.com  via TCP (submission) with ESMTPA; Sat, 19 Nov 2005 16:45:50 +0000
Message-ID: <[e-mail]>
Date: Fri, 18 Nov 2005 16:01:49 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Missing some information for the Vancouver minutes
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>

I've started converting Tony's jabber log into minutes and discovered 
that there is no record of some minor decisions.
In particular:

1) Add :from tagged argument to the "notify" action?

Did anybody objected to this?

2) Allow suppression of identical Sieve notifications?

Did we reach any consensus on this?

Thanks,
Alexey




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1maIM073296; Mon, 14 Nov 2005 17:48:36 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAF1majQ073295; Mon, 14 Nov 2005 17:48:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAF1mXf7073286 for <[e-mail]>; Mon, 14 Nov 2005 17:48:34 -0800 (PST) (envelope-from [e-mail])
Received: from [192.168.0.4] (cpe-72-224-88-32.nycap.res.rr.com [72.224.88.32])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 15 Nov 2005 01:48:15 +0000
Message-ID: <[e-mail]>
Date: Sat, 12 Nov 2005 21:15:52 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Resolution for IESG discuss on variable - :lower/:upper underspecified
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>

During the meeting in Vancouver the WG was offered two choices on how to 
fully describe ":lower"/":upper":
1). clarify that :lower/:upper only affect US-ASCII subset of Unicode 
characters.
2). design a solution that would deal properly with all Unicode characters.

The show of hands at the meeting suggested that people support # 1 and 
nobody supported # 2. This message is to confirm this decision on the 
mailing list.

Unless somebody can come up with a technical reason why we should do # 2 
now, I would request Kjetil to update the document to implement # 1. As 
soon as this is done the document can be sent back to IESG.

Alexey

P.S. Note that 2) can always be done as an extension at a later time.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jABLc9X7092553; Fri, 11 Nov 2005 13:38:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jABLc9xQ092552; Fri, 11 Nov 2005 13:38:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mv.mv.com (osmium.mv.net [199.125.85.152]) by above.proper.com (8.12.11/8.12.9) with SMTP id jABLc7qO092542 for <[e-mail]>; Fri, 11 Nov 2005 13:38:08 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 84199 invoked by uid 101); 11 Nov 2005 16:38:07 -0500
From: "Mark E. Mallett" <[e-mail]>
Date: Fri, 11 Nov 2005 16:38:07 -0500
To: Nigel Swinson <[e-mail]>
Cc: Tony Hansen <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-hansen-sieve-loop-01.txt]
Message-ID: <[e-mail]>
References: <[e-mail]> <003d01c5e086$a98bad30$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <003d01c5e086$a98bad30$[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi-

The first thing I'd bark at here (arf) is the periods in the command
"for.every.part" .  Not only would this cause me some minor pain in
parsing (my problem, I know), but I'm pretty sure that RFC3028 wants
commands/identifiers to contain only alphas, digits, and underscores.

On Thu, Nov 03, 2005 at 02:55:40PM -0000, Nigel Swinson wrote:


> 2 Sieve Loops
> 
> I can see that this makes perfect sense when used with replace and am glad 
> to see you've included "break" which I completely missed on my first scan. 

"break" is good.  I wonder if a "next" or "continue" would be useful as
well.  For that matter, it might be better to have a separate extension
describing some elements of looping constructs within SIEVE (without
actually defining any looping commands) that defines "break" and such.


> 3 Test "mime"
> 
> I like this test, but my earlier comments from 2004 still stand 
> (http://www.imc.org/ietf-mta-filters/mail-archive/msg01723.html).

Plus related comments at or around
   http://www.imc.org/ietf-mta-filters/mail-archive/msg01660.html



> You say:
> 
>   If used within the context of a "for.every.part" iterator, the "mime"
>   test will examine the headers associated with the current MIME part
>   context.
> 
>   If used outside the context of a "for.every.part" iterator, the
>   "mime" test will examine all MIME body parts and return true if any
>   of them satisfies the test.
> 
> While I'm glad you've provided the facility to easily look for attachments 
> of the given type without using for.every.part, this wasn't the behaviour I 
> was expecting and I think it's too quirky.  What if i find an attachment of 
> type rfc822 (think of multipart/digest), and then I'd want to recursively 
> look through all the attachments of just that attached message?  I would 
> much rather the mime test just look at the current body part context, and 
> we provide a switch which asks for the test to apply to all the child body 
> parts too where relevant.  This switch then also makes sense when used with 
> other tests like header, exists, size, address.  Something like:
> 
>    mime :recursive :type :is "image"
> 
> Or:
> 
>    mime :anybodypart :type :is "image"

I agree.  The "for*" should set the focus, and the "mime" and other
tests should work within that focus.  Outside of the "for" the focus
would be on the root part.  Making "mime" work differently in different
contexts would be inconsistent and difficult to understand (and
complicate the implementations -- the mime verb would have to know what
scope it is in, and how far outwards that scope extends).  One thing
I would like to see (as I mentioned in the thread I referenced above) is
that the recursion parameter specify that it operate *only* on the
children (i.e., not include the part that's being focused on).  This
would let the script writer test either the part in focus, or its
children, or both; the other way is less flexible.  (Personally I don't
think "both" would generally be wanted.).  So maybe ":anychild" instead
of ":recursive".




> 4 Action Replace
> 
>   When used in the context of a "for.every.part" loop, the MIME part to
>   be replaced is the "current" MIME part.  If the current MIME context
>   is a multipart MIME part, the entire multipart MIME part is replaced.
>   (Replacing a non-multipart MIME part within a "for.every.part" loop
>   context does not alter the overall message structure.)
> 
> I think I know what you are trying to get at with the bit in (), but I 
> don't actually understand what you have said.  I suggest just dropping the 
> () bit, as I don't think it's necessary.

I think he's trying to make it clear that replacing a multipart MIME
part does alter the message structure, as it wipes out one or more children
of the part being replaced.  Maybe it would be clearer by adding a sentence
before the () rather than dropping the parenthesised stuff, e.g.,
", which would alter the MIME structure of the message by eliminating all
of the children of the multipart part."

Oh and (from the draft):

   > A new sieve action command is defined to allow the MIME part to be
   > replaced by a text message.  The "replace" command causes a MIME part
   > to be removed and replaced with a text/plain part with the text
   > supplied by the command.

This could be made consistent with "vacation" by allowing ":mime" --
letting the script writer supply the entire message part as the new
replacment string (with appropriate proscriptions against things that
couldn't be used here).



> 5 Action Enclose

I find this whole section troubling :-)

I'd rather it didn't mandate a delayed execution of this action; and if
it really wants to talk about how to handle multiple "enclose" verbs I
think it would be more consistent with other Sieve actions to simply
say that duplicate actions are either an error or should be ignored.

 
>  This action does not affect messages that are
>   forwarded via a "redirect" action.
> 
> I don't like the last sentence very much at all.  It implies I need to 
> forward before I modify, which means I'll likely end up with two copies of 
> the message which sounds like an awkward issue to deal with and I'm not 
> sure it's the right behaviour anyway.  If I read a script that had a 
> replace/enclose as well as a redirect, then I'd expect that the redirected 
> message to have the replace/enclose action included.  Is it not most likely 
> we'd be using enclose/replace for security/moderation reasons, so why 
> wouldn't we want this to apply for redirected mail?

Yeah, I agree- I don't like having that amount of magic.  

Also, harping on this old views thing again..  when you are altering a
message, particularly when you get into changing/adding MIME parts,
often you want this to be only for some particular context, and it would
be nice to be able to back out some changes or revert to another view
before proceding.  e.g.:

   view_closure {
       enclose "some intro comment";
       redirect "[e-mail]";
   }

But that's still way off track.



>   Specifically, the original message becomes a multipart/mixed message
>   with two parts: a text/plain portion with the string argument as its
>   body, and a message/rfc822 portion with the original message
>   enclosed.  The Content-Type: header field becomes multipart/mixed.
>   The Subject: header is specified by the :subject argument.  Any
>   headers specified by :headers are copied from the old message into
>   the new message.
> 
> Might I suggest that we copy all the headers by default, including the 
> subject?  If we don't are we not then at risk of creating mail loops etc 
> and also breaking the threading of messages due to the altered subject 
> line/references/message-id?  That means we don't need the :headers/:subject 
> arguments at all :o)

Although perhaps here too a ":mime" option would be valuable.



Some random thoughts:

What will this do:

    for.every.part {
        if (some test here) {
	    for.every.part {
	        ...
            }
        }
    }

i.e. will the internal "for" be anchored at the focus established
by the enclosing "for" ?  I'd hope so, but this should be stated.


Also in the vein of using "replace" to weed out unwanted parts:
I wonder if the inverse would be sometimes desirable, i.e.,
replace all but the selected part.  e.g.:

    if allof (header :contains "content-type" "multipart/alternative" {
        for.every.part {
	    if header :contains "content-type" "text/plain" {
		replace :allbut "alternative part deleted.";
		break;
	    }
 	}
    }

BTW, shouldn't there be a "mime" shorthand for testing the type/subtype,
without requiring
     if allof (mime :type "multipart", mime :subtype "alternative")
?  Especially for any recursive version of "mime" (since the elements
inside of "allof" can be matching different mime parts).

mm



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAACP382042796; Thu, 10 Nov 2005 04:25:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jAACP33Q042795; Thu, 10 Nov 2005 04:25:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jAACP2XH042771 for <[e-mail]>; Thu, 10 Nov 2005 04:25:02 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from nigelhome (unverified [10.42.40.202]) by mail.rockliffe.com (Rockliffe SMTPRA 6.3.29) with ESMTP id <[e-mail]>; Thu, 10 Nov 2005 04:24:53 -0800
Message-ID: <003401c5e5f1$c382b790$f10ac050@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Tony Hansen" <[e-mail]>
Cc: <[e-mail]>, "Cyrus Daboo" <[e-mail]>
References: <[e-mail]> <003d01c5e086$a98bad30$[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-hansen-sieve-loop-01.txt]
Date: Thu, 10 Nov 2005 12:24:55 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id jAACP2XH042789
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>

> > Might I suggest that we copy all the headers by default, including the
> > subject?  If we don't are we not then at risk of creating mail loops etc
> > and also breaking the threading of messages due to the altered subject
> > line/references/message-id?  That means we don't need the
> > :headers/:subject arguments at all :o)
> 
> I started with the "copy everything" by default. But then I started
> thinking about headers such as the various domainkeys, iim and dkim
> headers, trace headers, etc. This is really a new message that's being
> created, so should reflect that. 

I think logically it's an altered version of the original message, which for delivery/loop/thread issues should be considered the same.  It's almost the same as adding some kind of X-Spam-Score header.  I would consider something like vacation to generate "new" messages, but don't believe that to be the case here.

> Besides, everything else is being
> carried along in the message/rfc822 portion.

Except loop/trace analysis isn't going to go hoking about in the attached body parts to look for these.  So it'll be fine for humans to read, but the software is going to trip up and many of the headers are designed for them to read.

I feel pretty strongly about this, but at the same time don't think I'd implement enclose, so if nobody else thinks this is a problem, then I'll just keep out your way.

Nigel



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA9MpeFX008247; Wed, 9 Nov 2005 14:51:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA9MpeHk008246; Wed, 9 Nov 2005 14:51:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.255.211]) by above.proper.com (8.12.11/8.12.9) with SMTP id jA9Mpdvg008238 for <[e-mail]>; Wed, 9 Nov 2005 14:51:39 -0800 (PST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-10.tower-120.messagelabs.com!1131576696!9478814!1
X-StarScan-Version: 5.5.9.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 26988 invoked from network); 9 Nov 2005 22:51:37 -0000
Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-10.tower-120.messagelabs.com with SMTP; 9 Nov 2005 22:51:37 -0000
Received: from [135.70.84.18] (unknown[135.70.84.18](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20051109225135gw100lggr0e> (Authid: tony); Wed, 9 Nov 2005 22:51:36 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 17:51:24 -0500
From: Tony Hansen <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nigel Swinson <[e-mail]>
CC: [e-mail], Cyrus Daboo <[e-mail]>
Subject: Re: I-D ACTION:draft-hansen-sieve-loop-01.txt]
References: <[e-mail]> <003d01c5e086$a98bad30$[e-mail]>
In-Reply-To: <003d01c5e086$a98bad30$[e-mail]>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nigel Swinson wrote:
> 
> I'm glad to see you've merged the loop/mime I-drafts (as I'd
> recommended) :o) A little surprised that you've stuck with the
> "sieve-loop" rather than the "sieve-mime" as it seems like it's
> extensions targetted at mime more than it is to looping.  

It was more an artifact of timing. It didn't get done until after the
-00 cutoff, and the path of least resistance was to keep the name.

> Along these
> lines I'd suggest:
> 
> - Sieve Extensions: MIME Bodypart Iteration, MIME Tests, Replacement and
> -                               Enclosure
> 
> + Sieve Extensions: MIME Tests, MIME Bodypart Iteration, Replacement and
> +                               Enclosure

a reasonable suggestion

> 2 Sieve Loops
> 
> I can see that this makes perfect sense when used with replace and am
> glad to see you've included "break" which I completely missed on my
> first scan. Is it worth being a little more explicit when describing the
> behaviour of other tests like header/address/size within a
> for.every.part test?  This could probably done purely by extended example.

ok

> 3 Test "mime"
> 
> I like this test, but my earlier comments from 2004 still stand
> (http://www.imc.org/ietf-mta-filters/mail-archive/msg01723.html).  I
> think a header part sepecifier like this would still be of value:
> 
>   Syntax:   header [HEADER-PART] [COMPARATOR] [MATCH-TYPE]
>             <header-names: string-list> <key-list: string-list>
> 
>    HEADER-PART: ":value" / ":parameter" <param-names: string-list>
> 
> However having a mime test specifically targetted at looking at mime
> headers won't prevent a HEADER-PART, so I guess I can't have a strong
> objection.
> 
> You say:
> 
>   If used within the context of a "for.every.part" iterator, the "mime"
>   test will examine the headers associated with the current MIME part
>   context.
> 
>   If used outside the context of a "for.every.part" iterator, the
>   "mime" test will examine all MIME body parts and return true if any
>   of them satisfies the test.
> 
> While I'm glad you've provided the facility to easily look for
> attachments of the given type without using for.every.part, this wasn't
> the behaviour I was expecting and I think it's too quirky.  What if i
> find an attachment of type rfc822 (think of multipart/digest), and then
> I'd want to recursively look through all the attachments of just that
> attached message?  I would much rather the mime test just look at the
> current body part context, and we provide a switch which asks for the
> test to apply to all the child body parts too where relevant.  This
> switch then also makes sense when used with other tests like header,
> exists, size, address.  Something like:
> 
>    mime :recursive :type :is "image"
> 
> Or:
> 
>    mime :anybodypart :type :is "image"
>    header :anybodypart :contains "Subject" "important"

Interesting suggestion. We'll think about it.

> 4 Action Replace
> 
>   When used in the context of a "for.every.part" loop, the MIME part to
>   be replaced is the "current" MIME part.  If the current MIME context
>   is a multipart MIME part, the entire multipart MIME part is replaced.
>   (Replacing a non-multipart MIME part within a "for.every.part" loop
>   context does not alter the overall message structure.)
> 
> I think I know what you are trying to get at with the bit in (), but I
> don't actually understand what you have said.  I suggest just dropping
> the () bit, as I don't think it's necessary.

I agree that it's not necessary, but I think it's still worth noting.
We'll look at the wording to make it clearer.

> I think we should say "The replace action happens immediately, and
> therefore when used inside a for.every.part loop will affect the
> iteration of that loop and all subsequent tests in this script".  Much
> in the same way as is done in the edit header extension.
> 
> 5 Action Enclose
> 
> Need an example of the :headers argument in use.
> 
>   This enclose action
>   takes precedance over all other message modifications, such as
>   "replace".  If multiple "enclose" actions are executed by a script,
>   only the text specified on the last one is used when creating the
>   enclosed message.
> 
> I find the above quite confusing.  Perhaps you could say something like
> "The enclose action MUST NOT happen immediately, but rather be delayed
> until we have finished processing the script".  If we then have replace
> happen immediately, there's no clash between enclose/replace as one
> happens immediately, and the other at the end of the script.
> 
> However enclose currently doesn't seem to allow us to enclose attached
> messages, it just wraps the entire message.  Do we want it to support
> enclosing attached rfc822 content?  Again I'm thinking of
> multipart/digest or just forwarded rfc822 content.
> 
>  This action does not affect messages that are
>   forwarded via a "redirect" action.
> 
> I don't like the last sentence very much at all.  It implies I need to
> forward before I modify, which means I'll likely end up with two copies
> of the message which sounds like an awkward issue to deal with and I'm
> not sure it's the right behaviour anyway.  If I read a script that had a
> replace/enclose as well as a redirect, then I'd expect that the
> redirected message to have the replace/enclose action included.  Is it
> not most likely we'd be using enclose/replace for security/moderation
> reasons, so why wouldn't we want this to apply for redirected mail?
> 
>   Specifically, the original message becomes a multipart/mixed message
>   with two parts: a text/plain portion with the string argument as its
>   body, and a message/rfc822 portion with the original message
>   enclosed.  The Content-Type: header field becomes multipart/mixed.
>   The Subject: header is specified by the :subject argument.  Any
>   headers specified by :headers are copied from the old message into
>   the new message.
> 
> Might I suggest that we copy all the headers by default, including the
> subject?  If we don't are we not then at risk of creating mail loops etc
> and also breaking the threading of messages due to the altered subject
> line/references/message-id?  That means we don't need the
> :headers/:subject arguments at all :o)

I started with the "copy everything" by default. But then I started
thinking about headers such as the various domainkeys, iim and dkim
headers, trace headers, etc. This is really a new message that's being
created, so should reflect that. Besides, everything else is being
carried along in the message/rfc822 portion.

Thanks for all the suggestions!

	Tony Hansen
	[e-mail]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA9HIi8S054468; Wed, 9 Nov 2005 09:18:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA9HIiJV054467; Wed, 9 Nov 2005 09:18:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA9HIhdO054461 for <[e-mail]>; Wed, 9 Nov 2005 09:18:44 -0800 (PST) (envelope-from [e-mail])
Received: from [172.16.2.116] (shiny.isode.com [62.3.217.250])  by rufus.isode.com via TCP (submission) with ESMTPA; Wed, 9 Nov 2005 17:18:41 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 Nov 2005 17:18:35 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Material for the Sieve meeting in Vancouver
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov wrote:

> Hi everybody,
> I would like to request all editors to prepare and send me slides 
> and/or short report on issues for each document they are editing.

I've uploaded the chair's presentation for the Vancouver Sieve WG 
meeting to:
https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64

Any other presentations?

Alexey



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA8HpGmj039409; Tue, 8 Nov 2005 09:51:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA8HpGNX039408; Tue, 8 Nov 2005 09:51:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA8HpFYL039391 for <[e-mail]>; Tue, 8 Nov 2005 09:51:15 -0800 (PST) (envelope-from [e-mail])
Received: from [209.52.106.166] (pp106-166.bctel.ca [209.52.106.166])  by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 8 Nov 2005 17:51:08 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Nov 2005 17:50:56 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Hansen <[e-mail]>
CC: MTA filtering mailing list <[e-mail]>
Subject: Re: Proposed agenda for the SIEVE WG meeting in Vancouver
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>

Tony Hansen wrote:

>loops/mime test?
>  
>
Yes, I've added this to my list already.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA6KtAc9075179; Sun, 6 Nov 2005 12:55:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA6KtAH4075178; Sun, 6 Nov 2005 12:55:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zeke.ecotroph.net (zeke.hxr.us [69.31.8.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA6Kt9im075157 for <[e-mail]>; Sun, 6 Nov 2005 12:55:10 -0800 (PST) (envelope-from [e-mail])
Received: from dul1shollenbl1 ([::ffff:209.52.111.221]) (AUTH: LOGIN sah, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by zeke.ecotroph.net with esmtp; Sun, 06 Nov 2005 15:54:55 -0500 id 01588068.436E6D9F.00003E1C
From: "Scott Hollenbeck" <[e-mail]>
To: [e-mail]
Subject: Last Call Ended: draft-ietf-sieve-vacation-04.txt
Date: Sun, 6 Nov 2005 15:55:06 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcXjFF2mYetZ3JlZRXOd9KD0/OlVew==
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IETF last call for draft-ietf-sieve-vacation-04.txt has concluded.
Please update the document to address last call comments discussed on this
mailing list (I didn't see any sent privately to the IESG).  I'll bring the
document to the IESG for evaluation after the update is available and the WG
confirms that everything has been addressed.

-Scott-



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA5IKHjY096204; Sat, 5 Nov 2005 10:20:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA5IKHtN096203; Sat, 5 Nov 2005 10:20:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA5IKGbq096190 for <[e-mail]>; Sat, 5 Nov 2005 10:20:16 -0800 (PST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Sat, 5 Nov 2005 10:20:13 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1131214812; h=Date: 	 From:Subject:MIME-version:Content-type; b=PCzCPJs0fku7YmE10io2VeFhC jJh+cOxSwo+9DCsIDcInrciUUUupNlXY4oLT3v4Vf368/CALoh7zOP+MpULjw==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Sat, 05 Nov 2005 10:20:08 -0800 (PST)
Cc: Scott Hollenbeck <[e-mail]>, [e-mail]
To: Kjetil Torgrim Homme <[e-mail]>
Message-id: <[e-mail]>
Date: Sat, 05 Nov 2005 10:11:54 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: FW: "Unicode" vs "ISO 10646"
In-reply-to: "Your message dated Mon, 31 Oct 2005 18:42:11 +0100" <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> On Thu, 2005-10-27 at 13:01 -0400, Scott Hollenbeck wrote:
> > Here's something to think about that came up during today's IESG evaluation
> > of draft-ietf-sieve-variables.  It might be worth talking about since the
> > doc needs some other edits before IESG approval.

> > >>From: Brian E Carpenter [mailto:[e-mail]]
> > >>
> > >>While scanning drafts in Frankfurt airport, I noticed
> > >>that two of them (the iris and sieve drafts) refer in the
> > >>text to Unicode.
> > >>
> > >>My understanding is that the IETF recommendation is to
> > >>use the ISO 10646 coded character set, and I thought there
> > >>were good reasons we specified that instead of Unicode.
> > >>
> > >>What should we be looking for in RFCs?
> >>
> >> Where is that recommendation?
> >
> > RFC 2277 = BCP 18
> >
> > which doesn't even mention Unicode. (Also see RFC 2130).

> on the other hand, stringprep (RFC 3454) is quite explicit in that it is
> based on Unicode 3.2, rather than "ISO 10646 with amendments".

I haven't checked this, but it might be due to ISO 10646 not containing the
necessary information about normalization procedures.

> I
> believe this is a more stringent choice, although I'm unsure if an
> explicit reference to Unicode 3.2 is the right choice for miscellaneous
> other documents.

It is definitely a more stringent choice. Historically ISO 10646 has tracked
changes in Unicode, so saying "ISO 10646 with amendments" has historically
corresponded to "a recent version of Unicode". A reference to Unicode 3.2,
OTOH, means that version and that version only.

> I believe it would be very useful to define a stringprep profile for
> Sieve.  the profile may be defined for more general usage (comparators
> too, others?), but something [SIEVE] can refer to would make things a
> whole lot clearer.  I don't suggest to make it mandatory for Sieve, but
> *either* you support US-ASCII only (and use the identity mapping for
> other code points) *or* you support the profile.

I really don't see the value in this. You said later that it would be used for
matching and for :upper and :lower. I think sieve is a case where using
a nameprep profile by default in matching could easily cause more problems
than it solves. I suppose there's some value in making :upper and :lower
more versatile, but I don't think having a single, global default profile
for this is the right way to do it.

				Ned



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA42BElD070154; Thu, 3 Nov 2005 18:11:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA42BEnq070153; Thu, 3 Nov 2005 18:11:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA42BDgn070144 for <[e-mail]>; Thu, 3 Nov 2005 18:11:13 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.43) id 1EXr2r-0000Br-6R; Fri, 04 Nov 2005 03:11:09 +0100
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx1.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EXr2o-0001wx-W4; Fri, 04 Nov 2005 03:11:07 +0100
Subject: Re: FW: "Unicode" vs "ISO 10646"
From: Kjetil Torgrim Homme <[e-mail]>
To: Philip Guenther <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Fri, 04 Nov 2005 03:10:59 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.594, required 12, autolearn=disabled, AWL 1.22, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, 2005-11-03 at 09:26 -0800, Philip Guenther wrote:
> Kjetil Torgrim Homme <[e-mail]> writes:
> ...
> >I believe it would be very useful to define a stringprep profile for
> >Sieve.  the profile may be defined for more general usage (comparators
> >too, others?), but something [SIEVE] can refer to would make things a
> >whole lot clearer.  I don't suggest to make it mandatory for Sieve, but
> >*either* you support US-ASCII only (and use the identity mapping for
> >other code points) *or* you support the profile.
> 
> Could you be more specific about what this profile would be used for in
> [SIEVE]?  If it's 'just' a comparator, then it belongs in the collation
> doc, but that already defines defines a *nameprep* based collation
> (i;nameprep;v=1;uv=3.2) as well as collations using the Unicode
> Collation Algorithm, so I suspect you have more in mind that just using
> it as a comparator.

well, by using a nameprep profile, quite a few normal characters are
prohibited, in particular U+00A0 (&nbsp;) is way too common in e-mail to
be disallowed, IMHO.  but I'm not quite clear what prohibiting a
character really means for Sieve.

I just want something which makes sense for matching in base Sieve, but
I also want a :lower and :upper which works in "variables".  using the
nameprep profile is certainly better than locking it to US-ASCII,
though.
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3HQdh5004023; Thu, 3 Nov 2005 09:26:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3HQdDA004022; Thu, 3 Nov 2005 09:26:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-out.sendmail.com (smtp-out.sendmail.com [209.246.26.45]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3HQcoD004015 for <[e-mail]>; Thu, 3 Nov 2005 09:26:38 -0800 (PST) (envelope-from [e-mail])
Received: from lab.smi.sendmail.com ([10.210.100.93]) by foon.sendmail.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA3HQXNU021218 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 3 Nov 2005 09:26:33 -0800
X-DomainKeys: Sendmail DomainKeys Filter v0.2.7 foon.sendmail.com jA3HQXNU021218
DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; b=isWh5Gf3DP/jAAohjg6puP6tSc5BdBKbjqF9hzYW1YMUxrUw9CrjHYHGjJAkmWZ8+ qncy5CtzZss7OL+oDyDUtVZKd+U80cfCWLjT5bBwDvTI8MYhcCXP7SJBAJdVozt1fbm KZliqqUQCL+Ca2xEgll0Pg8FgCmZQJVpKjxKVXw=
Received: from lab.smi.sendmail.com (localhost [127.0.0.1]) by lab.smi.sendmail.com (8.13.3/8.13.3) with ESMTP id jA3HQXsw043651; Thu, 3 Nov 2005 09:26:33 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kjetil Torgrim Homme <[e-mail]>
Cc: [e-mail]
From: Philip Guenther <[e-mail]>
Subject: Re: FW: "Unicode" vs "ISO 10646" 
In-reply-to: <[e-mail]> 
References: <[e-mail]>  <[e-mail]> 
Date: Thu, 03 Nov 2005 09:26:33 -0800
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>

Kjetil Torgrim Homme <[e-mail]> writes:
...
>I believe it would be very useful to define a stringprep profile for
>Sieve.  the profile may be defined for more general usage (comparators
>too, others?), but something [SIEVE] can refer to would make things a
>whole lot clearer.  I don't suggest to make it mandatory for Sieve, but
>*either* you support US-ASCII only (and use the identity mapping for
>other code points) *or* you support the profile.

Could you be more specific about what this profile would be used for in
[SIEVE]?  If it's 'just' a comparator, then it belongs in the collation
doc, but that already defines defines a *nameprep* based collation
(i;nameprep;v=1;uv=3.2) as well as collations using the Unicode
Collation Algorithm, so I suspect you have more in mind that just using
it as a comparator.


Philip Guenther



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3EtmXJ086145; Thu, 3 Nov 2005 06:55:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA3EtmAU086144; Thu, 3 Nov 2005 06:55:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA3EtmSj086128 for <[e-mail]>; Thu, 3 Nov 2005 06:55:48 -0800 (PST) (envelope-from [e-mail])
X-Spam-Score: 1
Received: from SCOTTY (unverified [10.42.44.102]) by mail.rockliffe.com (Rockliffe SMTPRA 6.3.29) with ESMTP id <[e-mail]>; Thu, 3 Nov 2005 06:55:42 -0800
Message-ID: <003d01c5e086$a98bad30$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Tony Hansen" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-hansen-sieve-loop-01.txt]
Date: Thu, 3 Nov 2005 14:55:40 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm glad to see you've merged the loop/mime I-drafts (as I'd recommended) 
:o) A little surprised that you've stuck with the "sieve-loop" rather than 
the "sieve-mime" as it seems like it's extensions targetted at mime more 
than it is to looping.  Along these lines I'd suggest:

- Sieve Extensions: MIME Bodypart Iteration, MIME Tests, Replacement and
-                               Enclosure

+ Sieve Extensions: MIME Tests, MIME Bodypart Iteration, Replacement and
+                               Enclosure

2 Sieve Loops

I can see that this makes perfect sense when used with replace and am glad 
to see you've included "break" which I completely missed on my first scan. 
Is it worth being a little more explicit when describing the behaviour of 
other tests like header/address/size within a for.every.part test?  This 
could probably done purely by extended example.

3 Test "mime"

I like this test, but my earlier comments from 2004 still stand 
(http://www.imc.org/ietf-mta-filters/mail-archive/msg01723.html).  I think a 
header part sepecifier like this would still be of value:

   Syntax:   header [HEADER-PART] [COMPARATOR] [MATCH-TYPE]
             <header-names: string-list> <key-list: string-list>

    HEADER-PART: ":value" / ":parameter" <param-names: string-list>

However having a mime test specifically targetted at looking at mime headers 
won't prevent a HEADER-PART, so I guess I can't have a strong objection.

You say:

   If used within the context of a "for.every.part" iterator, the "mime"
   test will examine the headers associated with the current MIME part
   context.

   If used outside the context of a "for.every.part" iterator, the
   "mime" test will examine all MIME body parts and return true if any
   of them satisfies the test.

While I'm glad you've provided the facility to easily look for attachments 
of the given type without using for.every.part, this wasn't the behaviour I 
was expecting and I think it's too quirky.  What if i find an attachment of 
type rfc822 (think of multipart/digest), and then I'd want to recursively 
look through all the attachments of just that attached message?  I would 
much rather the mime test just look at the current body part context, and we 
provide a switch which asks for the test to apply to all the child body 
parts too where relevant.  This switch then also makes sense when used with 
other tests like header, exists, size, address.  Something like:

    mime :recursive :type :is "image"

Or:

    mime :anybodypart :type :is "image"
    header :anybodypart :contains "Subject" "important"

4 Action Replace

   When used in the context of a "for.every.part" loop, the MIME part to
   be replaced is the "current" MIME part.  If the current MIME context
   is a multipart MIME part, the entire multipart MIME part is replaced.
   (Replacing a non-multipart MIME part within a "for.every.part" loop
   context does not alter the overall message structure.)

I think I know what you are trying to get at with the bit in (), but I don't 
actually understand what you have said.  I suggest just dropping the () bit, 
as I don't think it's necessary.

I think we should say "The replace action happens immediately, and therefore 
when used inside a for.every.part loop will affect the iteration of that 
loop and all subsequent tests in this script".  Much in the same way as is 
done in the edit header extension.

5 Action Enclose

Need an example of the :headers argument in use.

   This enclose action
   takes precedance over all other message modifications, such as
   "replace".  If multiple "enclose" actions are executed by a script,
   only the text specified on the last one is used when creating the
   enclosed message.

I find the above quite confusing.  Perhaps you could say something like "The 
enclose action MUST NOT happen immediately, but rather be delayed until we 
have finished processing the script".  If we then have replace happen 
immediately, there's no clash between enclose/replace as one happens 
immediately, and the other at the end of the script.

However enclose currently doesn't seem to allow us to enclose attached 
messages, it just wraps the entire message.  Do we want it to support 
enclosing attached rfc822 content?  Again I'm thinking of multipart/digest 
or just forwarded rfc822 content.

  This action does not affect messages that are
   forwarded via a "redirect" action.

I don't like the last sentence very much at all.  It implies I need to 
forward before I modify, which means I'll likely end up with two copies of 
the message which sounds like an awkward issue to deal with and I'm not sure 
it's the right behaviour anyway.  If I read a script that had a 
replace/enclose as well as a redirect, then I'd expect that the redirected 
message to have the replace/enclose action included.  Is it not most likely 
we'd be using enclose/replace for security/moderation reasons, so why 
wouldn't we want this to apply for redirected mail?

   Specifically, the original message becomes a multipart/mixed message
   with two parts: a text/plain portion with the string argument as its
   body, and a message/rfc822 portion with the original message
   enclosed.  The Content-Type: header field becomes multipart/mixed.
   The Subject: header is specified by the :subject argument.  Any
   headers specified by :headers are copied from the old message into
   the new message.

Might I suggest that we copy all the headers by default, including the 
subject?  If we don't are we not then at risk of creating mail loops etc and 
also breaking the threading of messages due to the altered subject 
line/references/message-id?  That means we don't need the :headers/:subject 
arguments at all :o)

Nigel 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2LhIeL071330; Wed, 2 Nov 2005 13:43:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA2LhI8d071329; Wed, 2 Nov 2005 13:43:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2LhH14071321 for <[e-mail]>; Wed, 2 Nov 2005 13:43:17 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.43) id 1EXQO1-00035d-PU for [e-mail]; Wed, 02 Nov 2005 22:43:13 +0100
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx5.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EXQNv-0002je-FS for [e-mail]; Wed, 02 Nov 2005 22:43:07 +0100
Subject: Re: Material for the Sieve meeting in Vancouver
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>  <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 02 Nov 2005 22:43:01 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.63, required 12, autolearn=disabled, AWL 1.18, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 2005-11-02 at 21:57 +0100, Kjetil Torgrim Homme wrote:
> just wondering, it is 3 minutes until the meeting according to my watch,
> but the Jabber room is empty.  am I on the right server?
> [e-mail] (also known as [e-mail])

what do you mean, I should check the day of the month as well?  :-)
-- 
Kjetil T.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2KvlYd064532; Wed, 2 Nov 2005 12:57:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jA2Kvl8G064531; Wed, 2 Nov 2005 12:57:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (IDENT:[e-mail] [129.240.130.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2KvkNp064365 for <[e-mail]>; Wed, 2 Nov 2005 12:57:46 -0800 (PST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.43) id 1EXPfy-0005w7-GZ for [e-mail]; Wed, 02 Nov 2005 21:57:42 +0100
Received: from 250.80-203-78.nextgentel.com ([80.203.78.250] helo=chico.njus.no) by mail-mx3.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id 1EXPfv-000772-Ck for [e-mail]; Wed, 02 Nov 2005 21:57:39 +0100
Subject: Re: Material for the Sieve meeting in Vancouver
From: Kjetil Torgrim Homme <[e-mail]>
To: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Wed, 02 Nov 2005 21:57:33 +0100
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.664, required 12, autolearn=disabled, AWL 1.15, FORGED_RCVD_HELO 0.05, RCVD_IN_SORBS_DUL 0.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2005-10-31 at 16:43 +0000, Alexey Melnikov wrote:
> I would also like to know who is going to attend the meeting and who can 
> participate in jabber.

just wondering, it is 3 minutes until the meeting according to my watch,
but the Jabber room is empty.  am I on the right server?
[e-mail] (also known as [e-mail])
-- 
Kjetil T.