Re: thoughts about external lists

[Ned Freed <[e-mail]>]

> Hello Ned,

> Thanks for your feedback.  I agree with you that the lists in
> address/envelope/header are not-necessary-expandable (could be very
> large or only check for membership can be made).  However this thoughts
> are not valid for "reject :list", where the parameter has to be a
> necessary-expandable list.

Actually, that's not the case. One way to implement redirect :list is to look
up the list name and turn it into a list address, then send to that address and
have the expansion occur completely outside the Sieve context.

This approach probably doesn't make sense for a Sieve implementation operating
before final delivery, because in that case the implementation should not
have problems accesing mailing list content. But an MUA-based implemenation
accessing service-side lists might be required to operate in this fashion.
The content of mailing lists can be sensitive.

				Ned




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T0fDsA000695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 17:41:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9T0fDnm000693; Tue, 28 Oct 2008 17:41:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9T0f2Lw000617 for <[e-mail]>; Tue, 28 Oct 2008 17:41:12 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Tue, 28 Oct 2008 17:41:00 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Tue, 28 Oct 2008 17:40:58 -0700 (PDT)
Date: Tue, 28 Oct 2008 17:34:49 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: thoughts about external lists
In-reply-to: "Your message dated Tue, 28 Oct 2008 09:09:40 +0100" <[e-mail]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
Cc: IETF Sieve WG <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hello Ned,

> Thanks for your feedback.  I agree with you that the lists in
> address/envelope/header are not-necessary-expandable (could be very
> large or only check for membership can be made).  However this thoughts
> are not valid for "reject :list", where the parameter has to be a
> necessary-expandable list.

Actually, that's not the case. One way to implement redirect :list is to look
up the list name and turn it into a list address, then send to that address and
have the expansion occur completely outside the Sieve context.

This approach probably doesn't make sense for a Sieve implementation operating
before final delivery, because in that case the implementation should not
have problems accesing mailing list content. But an MUA-based implemenation
accessing service-side lists might be required to operate in this fashion.
The content of mailing lists can be sensitive.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S89wm1091667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2008 01:09:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9S89wTb091666; Tue, 28 Oct 2008 01:09:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9S89jur091626 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 01:09:57 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1Kuje5-0003qA-3i; Tue, 28 Oct 2008 09:09:45 +0100
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.3] (d90-134-43-206.cust.tele2.de [90.134.43.206]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id m9S89hAF002816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 28 Oct 2008 08:09:44 GMT
Message-ID: <[e-mail]>
Date: Tue, 28 Oct 2008 09:09:40 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: Re: thoughts about external lists
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.94/8521/Tue Oct 28 06:23:52 2008 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Ned,

Thanks for your feedback.  I agree with you that the lists in 
address/envelope/header are not-necessary-expandable (could be very 
large or only check for membership can be made).  However this thoughts 
are not valid for "reject :list", where the parameter has to be a 
necessary-expandable list.

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

Ned Freed wrote:
> 
>> Rereading draft-melnikov-sieve-external-lists-01 the main idea that came
>> to my mind is that ":list" adds one more (unnecessary) dimension.  In
>> case of "header", "address" and "envelope" test, their last parameter so
>> far is a string-list:
> 
>>              address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
>>              <header-list: string-list> <key-list: string-list>
> 
>>              envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
>>              <envelope-part: string-list> <key-list: string-list>
> 
>>              header [COMPARATOR] [MATCH-TYPE]
>>              <header-names: string-list> <key-list: string-list>
> 
>> With ":list" added the last parameter will be altered from "list of
>> strings" to a "list of list of strings".
> 
> Not really, it's a list of external lists.
> 
>> At the same time mixing
>> "internal" and external lists gets more complicated than necessary.  For
>> doing a check "if a mail does not come from my three girlfriends,  or my
>> company, then reject it" it would be necessary to write
> 
>>     if anyof(envelope "from" ["g1", "g2", "g3"],
>>          envelope :lists "from" ["my-department", "our-partners"]) { 
>> reject
>> ":P"; }
> 
> I actually prefer this. Rather strongly.
> 
>> I think it would be better to allow references to lists in any
>> string-list, which expands the references, so that the string-list can
>> be used normal.  What about replacing :list "my-pets" with L{my-pets},
>> hence the above check would be rewritten as
> 
>>     if envelope "from" ["g1", "g2", "g3", L{my-department},
>> L{<our-partners}] { reject ":P"; }
> 
> Well, first of all, what you're proposing is a syntax change to the core
> language. That's unacceptable IMO.
> 
> I'm not sure you can get around this problem in a reasonable way - the 
> obvious
> trick to try is to extend things to support "list" variables. Asuming 
> this can
> bge made to work, it certainly has things going for it - it lets you do 
> things
> like pull in a list, modify it in fairly complex ways, and then check stuff
> against it.
> 
> However, the problem that arises if you do this is that this is a really
> awkward fit into existing implementations (ours at least and I suspect 
> others
> too). The problem is that things are geared around first evaluating list
> constructs and then checking them, not the other way around. So what if 
> that
> list expands into 1,000,000 addresses. Or more to the point, what if the 
> list
> is defined in such a way that the only acces you have is a membership 
> check;
> there's no way to extract the list? It' still possible to implement this as
> list variables - I think - but it gets really nasty really quickly.
> 
>> In this way only the definition of string-list has to be changed.  The
>> test envelope, address and header stay untouched.  For "redirect" one
>> has just to write that it accepts now string-list instead of just
>> "string".
> 
> I'm certainly in favor of having the ability to do list tests in other
> contexts, but my proposal is to match :list a new MATCH-TYPE, with all
> that implies.
> 
>                 Ned
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RN0UOH003360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 16:00:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9RN0UFV003359; Mon, 27 Oct 2008 16:00:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RN0JV2003326 for <[e-mail]>; Mon, 27 Oct 2008 16:00:29 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 27 Oct 2008 16:00:16 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 27 Oct 2008 16:00:14 -0700 (PDT)
Date: Mon, 27 Oct 2008 15:40:52 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: thoughts about external lists
In-reply-to: "Your message dated Mon, 27 Oct 2008 23:14:48 +0100" <[e-mail]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
Cc: IETF Sieve WG <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=UTF-8; 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>

> Rereading draft-melnikov-sieve-external-lists-01 the main idea that came
> to my mind is that ":list" adds one more (unnecessary) dimension.  In
> case of "header", "address" and "envelope" test, their last parameter so
> far is a string-list:

>              address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
>              <header-list: string-list> <key-list: string-list>

>              envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
>              <envelope-part: string-list> <key-list: string-list>

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

> With ":list" added the last parameter will be altered from "list of
> strings" to a "list of list of strings".

Not really, it's a list of external lists.

> At the same time mixing
> "internal" and external lists gets more complicated than necessary.  For
> doing a check "if a mail does not come from my three girlfriends,  or my
> company, then reject it" it would be necessary to write

> 	if anyof(envelope "from" ["g1", "g2", "g3"],
> 		 envelope :lists "from" ["my-department", "our-partners"]) { reject
> ":P"; }

I actually prefer this. Rather strongly.

> I think it would be better to allow references to lists in any
> string-list, which expands the references, so that the string-list can
> be used normal.  What about replacing :list "my-pets" with L{my-pets},
> hence the above check would be rewritten as

> 	if envelope "from" ["g1", "g2", "g3", L{my-department},
> L{<our-partners}] { reject ":P"; }

Well, first of all, what you're proposing is a syntax change to the core
language. That's unacceptable IMO.

I'm not sure you can get around this problem in a reasonable way - the obvious
trick to try is to extend things to support "list" variables. Asuming this can
bge made to work, it certainly has things going for it - it lets you do things
like pull in a list, modify it in fairly complex ways, and then check stuff
against it.

However, the problem that arises if you do this is that this is a really
awkward fit into existing implementations (ours at least and I suspect others
too). The problem is that things are geared around first evaluating list
constructs and then checking them, not the other way around. So what if that
list expands into 1,000,000 addresses. Or more to the point, what if the list
is defined in such a way that the only acces you have is a membership check;
there's no way to extract the list? It' still possible to implement this as
list variables - I think - but it gets really nasty really quickly.

> In this way only the definition of string-list has to be changed.  The
> test envelope, address and header stay untouched.  For "redirect" one
> has just to write that it accepts now string-list instead of just
> "string".

I'm certainly in favor of having the ability to do list tests in other
contexts, but my proposal is to match :list a new MATCH-TYPE, with all
that implies.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RMFArf095274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Oct 2008 15:15:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9RMFAu9095271; Mon, 27 Oct 2008 15:15:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9RMEvO9095200 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 27 Oct 2008 15:15:09 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1KuaMS-0001Zj-1e; Mon, 27 Oct 2008 23:14:56 +0100
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.3] (d90-134-7-7.cust.tele2.de [90.134.7.7]) (authenticated bits=0) by smtp.aegee.org (8.14.3/8.13.6) with ESMTP id m9RMEqRU011623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 27 Oct 2008 22:14:55 GMT
Message-ID: <[e-mail]>
Date: Mon, 27 Oct 2008 23:14:48 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: thoughts about external lists
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.94/8513/Mon Oct 27 20:06:35 2008 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

Rereading draft-melnikov-sieve-external-lists-01 the main idea that came 
to my mind is that ":list" adds one more (unnecessary) dimension.  In 
case of "header", "address" and "envelope" test, their last parameter so 
far is a string-list:

             address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
             <header-list: string-list> <key-list: string-list>

             envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
             <envelope-part: string-list> <key-list: string-list>

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

With ":list" added the last parameter will be altered from "list of 
strings" to a "list of list of strings".   At the same time mixing 
"internal" and external lists gets more complicated than necessary.  For 
doing a check "if a mail does not come from my three girlfriends,  or my 
company, then reject it" it would be necessary to write

	if anyof(envelope "from" ["g1", "g2", "g3"],
		 envelope :lists "from" ["my-department", "our-partners"]) { reject 
":P"; }

I think it would be better to allow references to lists in any 
string-list, which expands the references, so that the string-list can 
be used normal.  What about replacing :list "my-pets" with L{my-pets}, 
hence the above check would be rewritten as

	if envelope "from" ["g1", "g2", "g3", L{my-department}, 
L{<our-partners}] { reject ":P"; }

In this way only the definition of string-list has to be changed.  The 
test envelope, address and header stay untouched.  For "redirect" one 
has just to write that it accepts now string-list instead of just 
"string".

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NA7RcR091941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 03:07:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NA7RWi091940; Thu, 23 Oct 2008 03:07:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NA7FB1091925 for <[e-mail]>; Thu, 23 Oct 2008 03:07:27 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 0578A4AC78; Thu, 23 Oct 2008 12:07:13 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1224756432-66249-7731 for [e-mail]; Thu, 23 Oct 2008 12:07:12 +0200
Message-Id: <[e-mail]>
Date: Thu, 23 Oct 2008 12:05:51 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Questions regarding RFC 5228
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <MhWndMxi56Dr7/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mark E. Mallett writes:
> On Tue, Oct 21, 2008 at 10:58:45PM +0200, Arnt Gulbrandsen wrote:
>> I wrote the example in the natural, readable way on purpose.
>
> Sorry, I was just making a charitable guess. Natural, readable=20
> examples are good, but not when they don't work. It certainly begged=20
> the point that Kjetil Torgrim Homme raised, i.e., that it would=20
> require some magical conversion of the address string in order to=20
> make any sense.

Exactly.

The complexity isn't going away. You can accept difficult conversions in=20
the code, or you can push it into the user's sieve script and the=20
documentation of what address does. See below.

(Actually I don't think that particular conversion would be so difficult=20
=E2=80=94 I've done much worse ones. Turn <a.b.c.d> into ["a@b.c.d", =
"a.b@c.d",=20
"a.b.c@d"] and Sieve's usual matching rules will do the rest. But other=20
ones could be arbitrarily difficult.)

>> So you're saying it should be okay to use the address test for=20
>> non-address-fields, except that :user and :domain might not work at=20
>> all, and :all might work differently from the way it usually works?
>
> No, I'm saying that the address test should work the same way all the=20
> time when it finds an address. I don't get what you are saying there.

Let me try it differently.

The address test is defined to test an address against another address,=20
or against a part of another address. The domain part, the user part,=20
or optionally the subaddress part.

The address test could also test

  - addresses against a non-address
  - non-addresses against an address (what my example did)
  - non-addresses against a non-address (what yours did)

But I think that doing that leads to unacceptable complexity and/or=20
unreliability.

Complexity: If you want to guarantee a particular behaviour for e.g.=20
non-addresses against non-addresses, then the documentation's=20
explanation of what the address test does becomes too difficult for=20
mere mortals. Testing becomes a pain, too.

Or unreliability: You mentioned that in your code, :all worked on=20
list-id, right? Suppose one of your colleagues revises your address=20
parser so that it canonicalises "From: Cron Daemon <root>" into "From:=20
Cron Daemon <[e-mail]>". Then using address :all on list-id=20
stops working and address :localpart starts working.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9MLXiK2046797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2008 14:33:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9MLXitl046796; Wed, 22 Oct 2008 14:33:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9MLXX51046785 for <[e-mail]>; Wed, 22 Oct 2008 14:33:43 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 35736 invoked by uid 101); 22 Oct 2008 17:33:32 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Wed, 22 Oct 2008 17:33:32 -0400
To: [e-mail]
Subject: Re: Questions regarding RFC 5228
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <MhWndMxi56Dr7/[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <MhWndMxi56Dr7/[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, Oct 21, 2008 at 10:58:45PM +0200, Arnt Gulbrandsen wrote:
> 
> Mark E. Mallett writes:
> >Yes, Arnt's test should not attempt to combine "list-id" with "to" and 
> >"cc". I suspect that was just a quick mistake.
> 
> I wrote the example in the natural, readable way on purpose.

Sorry, I was just making a charitable guess.  Natural, readable examples
are good, but not when they don't work.  It certainly begged the point
that Kjetil Torgrim Homme raised, i.e., that it would require some
magical conversion of the address string in order to make any sense.


> >But there's a good point in there (not about converting the format, 
> >but about the lack of an '@').  My implementation does not require an 
> >'@' in any address in an address test.  If an '@' is missing, 
> >:localpart and :domain do not return anything, but :all returns the 
> >entire string.  I believe this is correct behavior according to 
> >RFC5228 (but even if it weren't, I'd make it work that way anyway, 
> >since I'd want it to be useful rather than fail).  The list-id header 
> >field has a well defined format that conforms to the way my 
> >implementation extracts addreses, and so I feel happy using the 
> >address test against List-ID.  e.g.:
> 
> So you're saying it should be okay to use the address test for 
> non-address-fields, except that :user and :domain might not work at 
> all, and :all might work differently from the way it usually works?

No, I'm saying that the address test should work the same way all the
time when it finds an address.  I don't get what you are saying there.

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LL0Mio086454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 14:00:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LL0M0m086453; Tue, 21 Oct 2008 14:00:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LL0AAj086441 for <[e-mail]>; Tue, 21 Oct 2008 14:00:21 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 8A2114AC93; Tue, 21 Oct 2008 23:00:09 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1224622808-66249-7110 (3 recipients); Tue, 21 Oct 2008 23:00:08 +0200
Message-Id: <MhWndMxi56Dr7/[e-mail]>
Date: Tue, 21 Oct 2008 22:58:45 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Questions regarding RFC 5228
Cc: "Mark E. Mallett" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mark E. Mallett writes:
> Yes, Arnt's test should not attempt to combine "list-id" with "to" and 
> "cc". I suspect that was just a quick mistake.

I wrote the example in the natural, readable way on purpose.

> But there's a good point in there (not about converting the format, 
> but about the lack of an '@').  My implementation does not require an 
> '@' in any address in an address test.  If an '@' is missing, 
> :localpart and :domain do not return anything, but :all returns the 
> entire string.  I believe this is correct behavior according to 
> RFC5228 (but even if it weren't, I'd make it work that way anyway, 
> since I'd want it to be useful rather than fail).  The list-id header 
> field has a well defined format that conforms to the way my 
> implementation extracts addreses, and so I feel happy using the 
> address test against List-ID.  e.g.:

So you're saying it should be okay to use the address test for 
non-address-fields, except that :user and :domain might not work at 
all, and :all might work differently from the way it usually works?

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LKEnHt083989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 13:14:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LKEnCg083988; Tue, 21 Oct 2008 13:14:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9LKEb9p083975 for <[e-mail]>; Tue, 21 Oct 2008 13:14:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 18443 invoked by uid 101); 21 Oct 2008 16:14:36 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Tue, 21 Oct 2008 16:14:36 -0400
To: [e-mail]
Subject: Re: Questions regarding RFC 5228
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, Oct 21, 2008 at 12:10:22AM +0200, Kjetil Torgrim Homme wrote:
> 
> On Mon, 2008-10-20 at 21:16 +0200, Arnt Gulbrandsen wrote:
> > if address :is :all [ "list-id", "to", "cc" ] "[e-mail]" {
> >      fileinto "sieve";
> > }
> 
> I hope that users will not relying on their server converting
> ietf-mta-filters.imc.org into [e-mail].  Likewise for
> extracting stuff from a mailto URL.  I wouldn't object to this being
> added to RFC 5228bis (or do we call it 3028ter?), but with the current
> state of affairs these headers should be left alone, and the address
> operator should fail.

Yes, Arnt's test should not attempt to combine "list-id" with "to" and "cc".
I suspect that was just a quick mistake.

But there's a good point in there (not about converting the format, but
about the lack of an '@').  My implementation does not require an '@' in
any address in an address test.  If an '@' is missing, :localpart and
:domain do not return anything, but :all returns the entire string.  I
believe this is correct behavior according to RFC5228 (but even if it
weren't, I'd make it work that way anyway, since I'd want it to be
useful rather than fail).  The list-id header field has a well defined
format that conforms to the way my implementation extracts addreses, and
so I feel happy using the address test against List-ID.  e.g.:

   if anyof(
      address :is :all ["to", "cc"] "[e-mail]",
      address :is :all "list-id" "ietf-mta-filters.imc.org" )
     { ... }

(barring typos and errors ..)

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LInaVI078050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 11:49:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LIna7T078049; Tue, 21 Oct 2008 11:49:36 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LInPOX078030 for <[e-mail]>; Tue, 21 Oct 2008 11:49:36 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.64.64] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id 8D96B1F9E; Tue, 21 Oct 2008 11:57:55 -0700 (PDT)
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Aaron Stone <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
Date: Tue, 21 Oct 2008 11:49:24 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.929.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Oct 21, 2008, at 4:20 AM, Arnt Gulbrandsen wrote:

>
> Alexey Melnikov writes:
>> I think the new syntax is backward compatible, but kolab/kontakt  
>> would need to be updated if they want to support the new syntax.
>>
>> BTW, do you have an email address(es) handy for kolab people?
>
> [e-mail] would do, I guess.
>
>>> A new command is the cleanest way. CHECKSCRIPT.
>>
>> I agree this is cleaner. But it has to be an extension (which is  
>> fine in this case)
>
> My intuitive preference is to make an extension, say that server  
> MUST implement it, explain that it is an extension only because past  
> versions of the document didn't contain CHECKSCRIPT, and maybe put  
> warnings into this extension. (I haven't looked at how you did  
> warnings in today's draft.)

+1 for a new mandatory command.

Probably does need to be defined as an extension because there are a  
number of extant implementations. I thought someone said that we're  
breaking use of PUTSCRIPT for syntax validation, but I didn't see  
where that happened in a (very) quick read of the draft. If we make a  
change like that, I think it's reasonable to add CHECKSCRIPT without  
advertising it.

I'll note that the ABNF for PUTSCRIPT still allows a blank name:

command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
sieve-name = string
quoted = DQUOTE *1024QUOTED-CHAR DQUOTE ;; limited to 1024 octets  
between the <">s

Aaron



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LBMCNV015806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 04:22:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LBMC12015805; Tue, 21 Oct 2008 04:22:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LBMBaE015797 for <[e-mail]>; Tue, 21 Oct 2008 04:22:11 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 7E6694AC84; Tue, 21 Oct 2008 13:22:10 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1224588130-66249-6812 for [e-mail]; Tue, 21 Oct 2008 13:22:10 +0200
Message-Id: <[e-mail]>
Date: Tue, 21 Oct 2008 13:20:45 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> I think the new syntax is backward compatible, but kolab/kontakt would 
> need to be updated if they want to support the new syntax.
>
> BTW, do you have an email address(es) handy for kolab people?

[e-mail] would do, I guess.

>> A new command is the cleanest way. CHECKSCRIPT.
>
> I agree this is cleaner. But it has to be an extension (which is fine 
> in this case)

My intuitive preference is to make an extension, say that server MUST 
implement it, explain that it is an extension only because past 
versions of the document didn't contain CHECKSCRIPT, and maybe put 
warnings into this extension. (I haven't looked at how you did warnings 
in today's draft.)

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LB3OBS014442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 04:03:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LB3ONg014441; Tue, 21 Oct 2008 04:03:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LB3NdI014434 for <[e-mail]>; Tue, 21 Oct 2008 04:03:24 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.2] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 21 Oct 2008 12:03:23 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 12:03:16 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> 1). Update to Sieve URL scheme based on Chris Newman's proposal. 
>> Based on the discussion on the mailing list I believe there is rough 
>> consensus to make the change, i.e. to add "authorized user" just 
>> before the script name, but it would be optional. I will send a 
>> separate message on this so that it is clear to everyone what change 
>> I will be implementing.
>
> Did you ask the kolab/kontakt people whether this will break their 
> deployment, or choose non-conflicting syntax?

I think the new syntax is backward compatible, but kolab/kontakt would 
need to be updated if they want to support the new syntax.

BTW, do you have an email address(es) handy for kolab people?

>> 2). Stephan Bosch suggested that some deployments would like to have 
>> script verification mode, without allowing SASL ANONYMOUS. I.e. only 
>> to allow script verification by registered users of the service (SASL 
>> ANONYMOUS would allow *any* user, even not registered on the system, 
>> to perform script validation). ManageSieve used to have such mode by 
>> allowing the empty string as the script name in PUTSCRIPT, but it was 
>> taken out, because I felt at the time that SASL ANONYMOUS was a 
>> cleaner design. Now that I understand that the two mechanisms have 
>> different applicability, I would like to hear WG opinion on this issue.
>
> A new command is the cleanest way. CHECKSCRIPT.

I agree this is cleaner. But it has to be an extension (which is fine in 
this case)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LApwg2013573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 03:51:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LApwRj013572; Tue, 21 Oct 2008 03:51:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LAplVY013557 for <[e-mail]>; Tue, 21 Oct 2008 03:51:58 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id F130E4AC9A; Tue, 21 Oct 2008 12:51:46 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1224586306-66249-6785 for [e-mail]; Tue, 21 Oct 2008 12:51:46 +0200
Message-Id: <[e-mail]>
Date: Tue, 21 Oct 2008 12:50:22 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> 1). Update to Sieve URL scheme based on Chris Newman's proposal. Based 
> on the discussion on the mailing list I believe there is rough 
> consensus to make the change, i.e. to add "authorized user" just 
> before the script name, but it would be optional. I will send a 
> separate message on this so that it is clear to everyone what change 
> I will be implementing.

Did you ask the kolab/kontakt people whether this will break their 
deployment, or choose non-conflicting syntax?

> 2). Stephan Bosch suggested that some deployments would like to have 
> script verification mode, without allowing SASL ANONYMOUS. I.e. only 
> to allow script verification by registered users of the service (SASL 
> ANONYMOUS would allow *any* user, even not registered on the system, 
> to perform script validation). ManageSieve used to have such mode by 
> allowing the empty string as the script name in PUTSCRIPT, but it was 
> taken out, because I felt at the time that SASL ANONYMOUS was a 
> cleaner design. Now that I understand that the two mechanisms have 
> different applicability, I would like to hear WG opinion on this 
> issue.

A new command is the cleanest way. CHECKSCRIPT.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LAfrU7012586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 03:41:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9LAfra0012585; Tue, 21 Oct 2008 03:41:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9LAfd0L012562 for <[e-mail]>; Tue, 21 Oct 2008 03:41:51 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.0.2] ((unknown) [62.3.217.253])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Tue, 21 Oct 2008 11:41:36 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 11:41:30 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've posted draft-ietf-sieve-managesieve-00.txt yesterday.
It has some relatively minor changes from draft-martin-managesieve-12.txt:

1). Addition of the WARNINGS response code (as per comment from Stephan 
Bosch)
2). Addition of the MAXREDIRECTS capability (as per discussion on the 
mailing list)
3). Updates/fixes to some examples (as per Chris Newman's review, etc.)
4). Added IANA registrations of some missing response codes

I only have 2 open issues outstanding:

1). Update to Sieve URL scheme based on Chris Newman's proposal. Based 
on the discussion on the mailing list I believe there is rough consensus 
to make the change, i.e. to add "authorized user" just before the script 
name, but it would be optional. I will send a separate message on this 
so that it is clear to everyone what change I will be implementing.

2). Stephan Bosch suggested that some deployments would like to have 
script verification mode, without allowing SASL ANONYMOUS. I.e. only to 
allow script verification by registered users of the service (SASL 
ANONYMOUS would allow *any* user, even not registered on the system, to 
perform script validation). ManageSieve used to have such mode by 
allowing the empty string as the script name in PUTSCRIPT, but it was 
taken out, because I felt at the time that SASL ANONYMOUS was a cleaner 
design. Now that I understand that the two mechanisms have different 
applicability, I would like to hear WG opinion on this issue.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KMAjNx062208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 15:10:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KMAjeC062207; Mon, 20 Oct 2008 15:10:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KMAXSw062176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Oct 2008 15:10:44 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.69) (envelope-from <[e-mail]>) id 1Ks2xM-0001IF-CR; Tue, 21 Oct 2008 00:10:32 +0200
Received: from 93-177-68-207.cust.consoll.no ([93.177.68.207] helo=[172.16.1.8]) by mail-mx4.uio.no with esmtpsa (TLSv1:CAMELLIA256-SHA:256) user kjetilho (Exim 4.69) (envelope-from <[e-mail]>) id 1Ks2xM-0007XY-48; Tue, 21 Oct 2008 00:10:32 +0200
Subject: Re: Questions regarding RFC 5228
From: Kjetil Torgrim Homme <[e-mail]>
Reply-To: [e-mail]
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Tue, 21 Oct 2008 00:10:22 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, MISSING_SUBJECT=0.001,NO_RECEIVED=-0.001, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 76E15787EE7E7660984134D288EC4952F757E714
X-UiO-SPAM-Test: remote_host: 93.177.68.207 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 1 total 41 max/h 3 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Mon, 2008-10-20 at 21:16 +0200, Arnt Gulbrandsen wrote:
> I looked at this message and saw two more examples.
> 
> List-Id: <ietf-mta-filters.imc.org>
> List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
> 
> Both fields are very widely used, and people do want to handle list mail 
> specially in sieves, so I guess that if the address test ought to work 
> beyond ordinary address fields, then those two are high on the priority 
> list. So has anyone here written the code necessary to have the address 
> test handle List-Id, List-Unsubscribe and friends?
> 
> This sounds like a fine test, just the kind of thing to catch all 
> mailing-list mail.
> 
> if address :is :all [ "list-id", "to", "cc" ] "[e-mail]" {
>      fileinto "sieve";
> }

I hope that users will not relying on their server converting
ietf-mta-filters.imc.org into [e-mail].  Likewise for
extracting stuff from a mailto URL.  I wouldn't object to this being
added to RFC 5228bis (or do we call it 3028ter?), but with the current
state of affairs these headers should be left alone, and the address
operator should fail.

(yes, I'd like to loosen the requirement of flagging errors for applying
this test on header fields known not to include addresses, too.)
-- 
regards,
Kjetil T.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KM0Wx5061732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 15:00:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KM0W9j061731; Mon, 20 Oct 2008 15:00:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KM0UZp061722 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Oct 2008 15:00:31 -0700 (MST) (envelope-from [e-mail])
Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1Ks2kJ-00007j-RE; Mon, 20 Oct 2008 23:57:03 +0200
Message-ID: <[e-mail]>
Date: Tue, 21 Oct 2008 00:00:17 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: Arnt Gulbrandsen <[e-mail]>, [e-mail]
Subject: Re: Questions regarding RFC 5228
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-VirusScan: Found to be clean
X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.144, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 0.85, BAYES_00 -2.60)
X-RenameIT-MailScanner-From: [e-mail]
X-Spam-Status: No
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ned Freed writes:
>> Stephan Bosch writes:
>> > * RFC 5228 (Sieve) : 5.1.  Test address:
>> > "Implementations MUST restrict the address test to headers that
>> > contain addresses, but MUST include at least From, To, Cc, Bcc,
>> > Sender, Resent-From, and Resent-To, and it SHOULD include any other
>> > header that utilizes an "address-list" structured header body."
>> >   -> Will this cause a compile error, or are the disallowed headers
>> >  simply ignored? My implementation currently considers this to be a
>> >  compile error.
> 
>> So does mine.
> 
> Our implementation does not. We allow address tests on all possible header
> fields. The test fails if the field does not contain actual addresses.
<SNIP>Long explanation about why this is wrong.</SNIP>

There is a reason why I pose this as a question. :) I am just trying to 
follow the standard here. Your points are valid and they do make me 
wonder why this was added in the new Sieve RFC. However, I do think we 
should reach some sort of consensus here to prevent ill portability of 
scripts that 'address' obscure headers.

>> >    * RFC 5228 (Sieve) : 5.4.  Test envelope:
>> > "The "envelope" test is true if the specified part of the [SMTP] (or
>> > equivalent) envelope matches the specified key.  This specification
>> > defines the interpretation of the (case insensitive) "from" and "to"
>> > envelope-parts.  Additional envelope-parts may be defined by other
>> > extensions; implementations SHOULD consider unknown envelope parts an
>> > error."
> 
>> Again, I give an error at compile time, none at runtime.
> 
> We check this at runtime. Changing things to perform a compile time check
> wouldn't be difficult, at least in the common case of no variable
> substitutions, but since this can't be done when ihave is turned on and 
> we're
> headed towards a situation where the vast majority of scripts we process 
> use
> ihave, I don't see any point in spending the time to implement this.
I agree.

>> >   -> Given the variables extension, sometimes the specified envelope
>> >  parts aren't known until runtime. Should invalid ones abort the
>> >  script or is ignoring them a better practice?
> 
> A script that manages to do an envelope test on an nonexistant envelope 
> part is
> broken in a fairly fundamental way. This needs to be noted, and the way 
> you do
> that is to throw an error.
Ok.

Regards,

Stephan



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KLkE3F061210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 14:46:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KLkERN061209; Mon, 20 Oct 2008 14:46:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KLkEKX061203 for <[e-mail]>; Mon, 20 Oct 2008 14:46:14 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 4E32C3A6B05; Mon, 20 Oct 2008 14:45:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-sieve-managesieve-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 20 Oct 2008 14:45:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : A Protocol for Remotely Managing Sieve Scripts
	Author(s)       : A. Melnikov, T. Martin
	Filename        : draft-ietf-sieve-managesieve-00.txt
	Pages           : 45
	Date            : 2008-10-20

Sieve scripts allow users to filter incoming email.  Message stores
are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them.  This document
describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server.  This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed
scripts.

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

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KLh2KE061056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 14:43:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KLh2v7061055; Mon, 20 Oct 2008 14:43:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KLgnXf061043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 20 Oct 2008 14:43:02 -0700 (MST) (envelope-from [e-mail])
Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1Ks2TF-00080v-KH for [e-mail]; Mon, 20 Oct 2008 23:39:25 +0200
Message-ID: <[e-mail]>
Date: Mon, 20 Oct 2008 23:42:39 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Questions regarding RFC 5228
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-VirusScan: Found to be clean
X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.139, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 0.86, BAYES_00 -2.60)
X-RenameIT-MailScanner-From: [e-mail]
X-Spam-Status: No
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

(OOPS, used wrong identity)

Arnt Gulbrandsen wrote:
> 
> Stephan Bosch writes:
>> Hello,
>>
>> I am finishing up a first release of my Sieve implementation, and one 
>> of the TODO items that yet remains is getting some answers to 
>> questions that arose during development. I've collected these into a 
>> file an now I submit them to this list to get some clarification. Any 
>> help is greatly appreciated.
>>
> Sieve is a simple language... All commands in a script can be arranged 
> into basic blocks, and the basic blocks form a DAG. (I don't remember 
> whether this remains true with Ned's MIME/looping extension.)
> 
> I wonder whether it is possible to walk along the DAG and say "this 
> assignment is invalid since it leads to an error when the variable is 
> used".
In extreme cases, a user can extract data from the incoming message
using :matches or even :regex. Then, there is really no way of telling
what the variable is going to contain. But yes, in all other cases one
could do compile-time string constant evaluation and be done with it.

I am interested particularly in those extreme cases. Not that I see a
particular use for those in the mentioned cases, but I like to be thorough.

Regards,

Stephan.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KJm93u053353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 12:48:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KJm9qg053352; Mon, 20 Oct 2008 12:48:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9KJm8dT053346 for <[e-mail]>; Mon, 20 Oct 2008 12:48:09 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 22121 invoked by uid 101); 20 Oct 2008 15:48:08 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 20 Oct 2008 15:48:08 -0400
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
Subject: Re: Questions regarding RFC 5228
Message-ID: <[e-mail]>
References: <[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 Mon, Oct 20, 2008 at 09:16:42PM +0200, Arnt Gulbrandsen wrote:
> I looked at this message and saw two more examples.
> 
> List-Id: <ietf-mta-filters.imc.org>
> List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
> 
> Both fields are very widely used, and people do want to handle list mail 
> specially in sieves, so I guess that if the address test ought to work 
> beyond ordinary address fields, then those two are high on the priority 
> list. So has anyone here written the code necessary to have the address 
> test handle List-Id, List-Unsubscribe and friends?

Yes, in that I don't do anything special to prohibit List-ID from being
used in an address test.  In fact I use an address test against
"List-ID" heavily in the script for my personal inbox, including for
this very mailing list.  (In kind of a layered way: info is pulled out
of fields using sieve statements and tested against metadata in a
database, but that's a tangent.

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KJINBQ051365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 12:18:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KJINU8051362; Mon, 20 Oct 2008 12:18:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KJICCZ051311 for <[e-mail]>; Mon, 20 Oct 2008 12:18:23 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id A48FA4ACA3; Mon, 20 Oct 2008 21:18:11 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1224530291-66249-6526 for [e-mail]; Mon, 20 Oct 2008 21:18:11 +0200
Message-Id: <[e-mail]>
Date: Mon, 20 Oct 2008 21:16:42 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Questions regarding RFC 5228
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Mark E. Mallett writes:
> Ditto; I was going to say the same thing, and for all the points you 
> mention. This "MUST" (or at least that interpretation of it) is 
> something I disagree with - I think it's unreasonable for an 
> implementation to tell a script writer that they may not attempt to 
> examine or extract or test an address in a header field that the 
> script writer wants to examine or extract or test, even if that 
> header field might not be defined as addresses in it in a structured 
> way. The message-id case is a perfect example, but there are others.

I looked at this message and saw two more examples.

List-Id: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Both fields are very widely used, and people do want to handle list mail 
specially in sieves, so I guess that if the address test ought to work 
beyond ordinary address fields, then those two are high on the priority 
list. So has anyone here written the code necessary to have the address 
test handle List-Id, List-Unsubscribe and friends?

This sounds like a fine test, just the kind of thing to catch all 
mailing-list mail.

if address :is :all [ "list-id", "to", "cc" ] "[e-mail]" {
     fileinto "sieve";
}

> I think that that proscription is more of a script 'con' than a 'pro.' :)

Simplicity is a valuable feature.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KIou8d047594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 11:50:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KIouQ8047593; Mon, 20 Oct 2008 11:50:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.usinternet.com (smtp4.usinternet.com [216.17.3.201]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KIojj9047567 for <[e-mail]>; Mon, 20 Oct 2008 11:50:56 -0700 (MST) (envelope-from [e-mail])
Received: from SERVER1 (unknown [67.118.62.214]) by smtp4.usinternet.com (Postfix) with SMTP id 2D661E168C for <[e-mail]>; Mon, 20 Oct 2008 13:50:42 -0500 (CDT)
Message-ID: <004501c93346$ac7274cd$a8fb7e6c@dxgsjqgfmmlre>
From: "=?windows-1251?B?TWFuYWdhcl9Gb3h0cm90?=" <[e-mail]>
To: <[e-mail]>
Subject: =?windows-1251?B?wOry8+Dr/O3uIOTr/yDk6PDl6vLu8OAg7+4g7+Xw8e7t4Ovz?=
Date: Mon, 20 Oct 2008 11:33:26 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="windows-1251"; 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>

Ïðàêòè÷åñêèé êóðñ: 

________ 

>	ÄÈÐÅÊÒÎÐ  ÏÎ  ÏÅÐÑÎÍÀËÓ    ÑÎÂÐÅÌÅÍÍÎÉ  ÊÎÌÏÀÍÈÈ.  ÍÎÂÛÉ  ÑÒÐÀÒÅÃÈ×ÅÑÊÈÉ  ÏÎÄÕÎÄ  Ê  ÓÏÐÀÂËÅÍÈÞ  ÏÅÐÑÎÍÀËÎÌ.
________


(çíàíèÿ, óìåíèÿ, íàâûêè, ëè÷íûå êà÷åñòâà, ìîòèâàöèÿ, íåîáõîäèìûå ÄïÏ, ÷òîáû îáåñïå÷èòü êîìïàíèþ ìàêñèìàëüíî ïîäõîäÿùèìè êàäðàìè íà êàæäûé âèä ðàáîòû) 

 

27-28 îêòÿáðÿ 2008
(8-044)..223-25-71.
 
      
________

  Íåîáõîäèìûå êîìïåòåíöèè äèðåêòîðà ïî ïåðñîíàëó.
  Ïîçèöèÿ HR-Äèðåêòîðà â ñèñòåìå óïðàâëåíèÿ. Öåëè è çàäà÷è ÄÏ.
  Ïîñòðîåíèå ýôôåêòèâíîé ñëóæáû óïðàâëåíèÿ ïåðñîíàëîì
	- Ìåñòî êàäðîâûõ òåõíîëîãèé â ñèñòåìå óïðàâëåíèÿ ïåðñîíàëîì
	- Êàäðîâàÿ ïîëèòèêà â ñîîòâåòñòâèè ñî ñòàäèåé ðàçâèòèÿ îðãàíèçàöèè
	- Âèäû îðãàíèçàöèîííûõ ñòðóêòóð è ðåãëàìåíòèðóþùèå äîêóìåíòû ñëóæáû ïåðñîíàëà
	- Êðèòåðèè ýôôåêòèâíîñòè äåÿòåëüíîñòè ñëóæáû ïåðñîíàëà
  Óïðàâëåíèå òàëàíòàìè. Êàäðîâûé ìåíåäæìåíò â XXI âåêå
	- Ñîâðåìåííûå òåõíîëîãèè ïîäáîðà ïåðñîíàëà. 
	- Îñòðûé äåôèöèò ÷åëîâå÷åñêèõ ðåñóðñîâ. Ãîòîâû ëè Âû ïåðåæèòü êàäðîâûé êðèçèñ?
	- Ïîçèöèîíèðîâàíèå êîìïàíèè íà ðûíêå òðóäà. Êàê âûãîäíî ïðîäàòü ðàáîòó?
	- Îò ïåðñîíàëà ê ïåðñîíå. Êàê óïðàâëÿòü òàëàíòàìè?
	- Óïðàâëåíèå êàðüåðîé ñîòðóäíèêîâ. Ðàçðàáîòêà èíòåðåñíîãî êàðüåðíîãî ñöåíàðèÿ
	- Ïîäãîòîâêà êàäðîâ âíóòðè îðãàíèçàöèè - êóçíèöà êàäðîâ èëè êîðïîðàòèâíûé óíèâåðñèòåò?
  Ýôôåêòèâíûé èíñòðóìåíòàðèé â ðàáîòå ñëóæáû óïðàâëåíèÿ ïåðñîíàëîì
	- Ïðîôèëèðîâàíèå äîëæíîñòåé
	- Íàéì: ïîäáîð è îòáîð ïåðñîíàëà
	- Îöåíêà ïåðñîíàëà (Assessment Center)
	- Àäàïòàöèÿ ïåðñîíàëà
	- Îáó÷åíèå ïåðñîíàëà. Îáó÷àþùàÿ îðãàíèçàöèÿ
	- Óìåíèå ïðåäîòâðàùàòü òèïè÷íûå îøèáêè, ñâÿçàííûå ñî ñòåðåîòèïàìè â îòíîøåíèè ëþäåé.
	- Êîíñîëèäàöèÿ ïåðñîíàëà, ïîâûøåíèå ëîÿëüíîñòè ñîòðóäíèêîâ è ñíèæåíèå ðåàëüíîé è ïîòåíöèàëüíîé òåêó÷åñòè ïåðñîíàëà
  Ìîòèâàöèÿ ïåðñîíàëà
	- Ìîòèâàöèÿ. Îñíîâíûå èäåè è ïîäõîäû
	- Äèàãíîñòèêà ìîòèâàöèîííîãî ïîòåíöèàëà  îðãàíèçàöèè  ñîòðóäíèêîâ
	- Êàëåéäîñêîï: íåìàòåðèàëüíàÿ è ìàòåðèàëüíàÿ ìîòèâàöèÿ
	- Ìîòèâàöèÿ è äðóãèå ñîñòàâëÿþùèå óïðàâëåíèÿ è ðàçâèòèÿ ïåðñîíàëà
	- Îïûò ðîññèéñêèõ è çàðóáåæíûõ êîìïàíèé
  Êîðïîðàòèâíàÿ êóëüòóðà  â êîìïàíèè
	- Ôóíêöèè è çíà÷åíèå êîðïîðàòèâíîé êóëüòóðû  êîìïàíèè
	- Ôîðìû êîðïîðàòèâíîé êóëüòóðû. Êîðïîðàòèâíûé Êîäåêñ
	- Ìåòîäû è òåõíîëîãèè ðàçðàáîòêè  è âíåäðåíèÿ êîðïîðàòèâíîé êóëüòóðû â êîìïàíèè
	- Ïîääåðæàíèå è êîððåêöèÿ êîðïîðàòèâíîé êóëüòóðû
	- Ïðèìåðû êîðïîðàòèâíîé êóëüòóðû ðîññèéñêèõ è çàïàäíûõ êîìïàíèé
  Âíóòðåííèå êîììóíèêàöèè â êîìïàíèè
	- Ìåòîäû îáðàòíîé ñâÿçè ñ ïåðñîíàëîì
	- Âíóòðåííèé PR óïðàâëåí÷åñêèõ ðåøåíèé
	- Ìîíèòîðèíã è êîððåêöèÿ  îáùåñòâåííîãî ìíåíèÿ â êîìïàíèè
	- Îòâåòû íà âîïðîñû è èíäèâèäóàëüíîå êîíñóëüòèðîâàíèå.

________
  

	Àâòîð è âåäóùèé: Ìóõèòäèíîâà Í.Ò. -  áèçíåñ-òðåíåð , ïñèõîëîã, ãåøòàëüò-òåðàïåâò, ìàãèñòð ïñèõîëîãèè (îáðàçîâàíèå Óêðàèíà, ÐÔ, Ãåðìàíèÿ). Îïûò òðåíåðñêîé ðàáîòû áîëåå 7 ëåò. Ñïåöèàëèçàöèÿ: ýôôåêòèâíîå óïðàâëåíèå â îðãàíèçàöèè ; ïîñòðîåíèå ñòðóêòóðû óïðàâëåíèÿ, ñòðóêòóðû êîììóíèêàöèé â îðãàíèçàöèè; ðàçðàáîòêà âíåäðåíèÿ ñèñòåì ìîòèâàöèè; ýôôåêòèâíîå ôóíêöèîíèðîâàíèå â êîìàíäå; ñòðóêòóðíûå ðåîðãàíèçàöèè , êðèçèñû è êîíôëèêòû â óïðàâëåíèè îðãàíèçàöèåé; àíàëèç âçàèìîäåéñòâèÿ ñ ïàðòíåðàìè, êëèåíòàìè è çàêàç÷èêàìè. Äèðåêòîð ïî ïåðñîíàëó êîìïàíèè. Ïðîâåäåíî áîëåå 150 òðåíèíãîâ è ñåìèíàðîâ â Óêðàèíå è çà ðóáåæîì.
	Ñòîèìîñòü çà 1-ãî ó÷àñòíèêà 1950,00 ãðí., ïðè 2-õ ó÷àñòíèêàõ 3650,00 ãðí (ïðè áîëüøåì êîëè÷åñòâå ó÷àñòíèêîâ, ïðåäîñòàâëÿþòñÿ èíäèâèäóàëüíûå ñêèäêè). * - îïëàòà çà ó÷àñòèå îòíîñèòñÿ ê ÂÐ (ñò.5, ï.5.2.1. Çàêîíà "Î íàëîãîîáëîæåíèè ïðèáûëè"). 
	Ìåñòî ïðîâåäåíèÿ: ã.Êèåâ, êîíôåðåíö-çàë Îòåëÿ "Sankt-Peterburg", áóëüâàð Ò.Øåâ÷åíêî,4 (ì."Êðåùàòèê"). 
 
 
(8-044)  223-25-71.
 



________________________
ÄÄÄ891gbak720855



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KISFQm044138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 11:28:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KISF2W044137; Mon, 20 Oct 2008 11:28:15 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m9KIS3hS044094 for <[e-mail]>; Mon, 20 Oct 2008 11:28:14 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 96511 invoked by uid 101); 20 Oct 2008 14:28:02 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Mon, 20 Oct 2008 14:28:02 -0400
To: [e-mail]
Subject: Re: Questions regarding RFC 5228
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 Mon, Oct 20, 2008 at 09:53:18AM -0700, Ned Freed wrote:
> 
> >Stephan Bosch writes:
> >> Hello,
> >>
> >> I am finishing up a first release of my Sieve implementation, and one
> >> of the TODO items that yet remains is getting some answers to
> >> questions that arose during development. I've collected these into a
> >> file an now I submit them to this list to get some clarification. Any
> >> help is greatly appreciated.
> >>
> >> * RFC 5228 (Sieve) : 5.1.  Test address:
> >> "Implementations MUST restrict the address test to headers that
> >> contain addresses, but MUST include at least From, To, Cc, Bcc,
> >> Sender, Resent-From, and Resent-To, and it SHOULD include any other
> >> header that utilizes an "address-list" structured header body."
> >>   -> Will this cause a compile error, or are the disallowed headers
> >>  simply ignored? My implementation currently considers this to be a
> >>  compile error.
> 
> >So does mine.
> 
> Our implementation does not. We allow address tests on all possible header
> fields. The test fails if the field does not contain actual addresses.

[ snipped ]

Ditto; I was going to say the same thing, and for all the points
you mention.  This "MUST" (or at least that interpretation of it) is
something I disagree with - I think it's unreasonable for an
implementation to tell a script writer that they may not attempt to
examine or extract or test an address in a header field that the script
writer wants to examine or extract or test, even if that header field
might not be defined as addresses in it in a structured way.  The
message-id case is a perfect example, but there are others.

I think that that proscription is more of a script 'con' than a 'pro.'  :)

mm



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KHbiOj035441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 10:37:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KHbiJq035440; Mon, 20 Oct 2008 10:37:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KHbWeM035396 for <[e-mail]>; Mon, 20 Oct 2008 10:37:43 -0700 (MST) (envelope-from [e-mail])
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Mon, 20 Oct 2008 10:37:03 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Mon, 20 Oct 2008 10:36:58 -0700 (PDT)
Date: Mon, 20 Oct 2008 09:53:18 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: Questions regarding RFC 5228
In-reply-to: "Your message dated Mon, 20 Oct 2008 11:21:40 +0200" <[e-mail]>
To: Arnt Gulbrandsen <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
Content-transfer-encoding: 7BIT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Stephan Bosch writes:
> > Hello,
> >
> > I am finishing up a first release of my Sieve implementation, and one
> > of the TODO items that yet remains is getting some answers to
> > questions that arose during development. I've collected these into a
> > file an now I submit them to this list to get some clarification. Any
> > help is greatly appreciated.
> >
> > * RFC 5228 (Sieve) : 5.1.  Test address:
> > "Implementations MUST restrict the address test to headers that
> > contain addresses, but MUST include at least From, To, Cc, Bcc,
> > Sender, Resent-From, and Resent-To, and it SHOULD include any other
> > header that utilizes an "address-list" structured header body."
> >   -> Will this cause a compile error, or are the disallowed headers
> >  simply ignored? My implementation currently considers this to be a
> >  compile error.

> So does mine.

Our implementation does not. We allow address tests on all possible header
fields. The test fails if the field does not contain actual addresses.

IMNSHO what you are doing here is quite simply wrong. It might, and I emphasize
MIGHT, be OK to throw an error if an address test is done on a really well
defined field that is either unstructured or structured as something other than
an address list. (Although I see no point in doing that.) But for an unknown
field, you cannot assume that it isn't defined by something somewhere as an
address list. Even if you assume you can keep up with the fields people bother
to register (and if you think you can I have to wonder how you get all the
sites using your software updated to the new definitions in a timely way),
people define an use their own private fields all the time. And nothing we've
done or can do in the standards process is going to change this.

And what about fields that have address syntax but which aren't exactly  an
address-list? The obvious one is message-id, which I believe is a proper subset
of address syntax. I've seen quite a few scripts written that use address tests
on the message-id header. Heck, the way this is written fields defined with
Sender: or From: syntax would be excluded, and that's nothing short of absurd.

I will also point out that the standard doesn't say anything about throwing
errors in this case. "Restricting" a test could mean that, but I think having
the test fail is more than sufficient.

But let's suppose the specificaiton did say an error should occur. I have to
say I would happily violate the specification in that case. The entire point of
Sieve is to give users a rich set of tools they can use to process the messages
they receive, including some seriously messed up stuff. I'm sorry, but when the
need to be able to deal with the broken dreck people actually send around
conflicts with implemnetation purity, effective hanlding of the dreck wins.
Every. Single. Time.

> > -> Given the variables extension, sometimes the specified header names
> > aren't known until runtime. If the previous answer was to cause a
> > compile error, should this abort the script at runtime?

> I don't have variables (yet?). I expect that I would try to give an
> error at compile time and to avoid runtime errors.

> >    * RFC 5228 (Sieve) : 5.4.  Test envelope:
> > "The "envelope" test is true if the specified part of the [SMTP] (or
> > equivalent) envelope matches the specified key.  This specification
> > defines the interpretation of the (case insensitive) "from" and "to"
> > envelope-parts.  Additional envelope-parts may be defined by other
> > extensions; implementations SHOULD consider unknown envelope parts an
> > error."

> Again, I give an error at compile time, none at runtime.

We check this at runtime. Changing things to perform a compile time check
wouldn't be difficult, at least in the common case of no variable
substitutions, but since this can't be done when ihave is turned on and we're
headed towards a situation where the vast majority of scripts we process use
ihave, I don't see any point in spending the time to implement this.

> >   -> Given the variables extension, sometimes the specified envelope
> >  parts aren't known until runtime. Should invalid ones abort the
> >  script or is ignoring them a better practice?

A script that manages to do an envelope test on an nonexistant envelope part is
broken in a fairly fundamental way. This needs to be noted, and the way you do
that is to throw an error.

> Sieve is a simple language... All commands in a script can be arranged
> into basic blocks, and the basic blocks form a DAG. (I don't remember
> whether this remains true with Ned's MIME/looping extension.)

It's not my extension, but since it doesn't change the syntax or structure of
Sieve I don't see how it could impact the blocking. But it certainly can make
static analysis more difficult if not impossible.

> I wonder whether it is possible to walk along the DAG and say "this
> assignment is invalid since it leads to an error when the variable is
> used".

Sure, that's possible in a lot of cases, but not all. The envelope part name
could come from the message data itself (sounds like a really bad idea, but you
can certainly do it), so unless your compilation step is done in a
message-dependant way that's a fundamental limit on analysis. (We compile in a
message-independent way so the same compiled script can be applied to multiple
messages. We even have the ability to store compiled scripts on disk and read
them back.)

But even if message data isn't involved or can be built into the compilation
process, I'm pretty sure doing it in full generality is at least in NP.

The real question, then, is whether this check is worth the bother. Since I
don't think even checking static string arguments to envelope is worth doing at
compile time, it goes without saying where I stand on doing even more analysis
of this case.

				Ned



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KAU0gE096473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 03:30:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KAU0Gx096472; Mon, 20 Oct 2008 03:30:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KATxA5096466 for <[e-mail]>; Mon, 20 Oct 2008 03:29:59 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id CFCB74AC91; Mon, 20 Oct 2008 12:29:58 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1224498598-66249-6332 for [e-mail]; Mon, 20 Oct 2008 12:29:58 +0200
Message-Id: <[e-mail]>
Date: Mon, 20 Oct 2008 12:28:32 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Questions regarding RFC 5228
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> How would you do that if you supported variables? Are you just going 
> to reject the second parameter because it contains a variable 
> reference?

It would be easy for me to walk back (at compile time) from where the 
variable is used to the locations where it's set, and see if each of 
those values look legal, illegal or indeterminate.

Don't know what I'd do when the value looks indeterminate, but I hope to 
get an idea from this thread.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KAJcHi095798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 03:19:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9KAJcvO095797; Mon, 20 Oct 2008 03:19:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9KAJRdZ095779 for <[e-mail]>; Mon, 20 Oct 2008 03:19:38 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.52.112] (92.40.52.112.sub.mbb.three.co.uk [92.40.52.112])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 20 Oct 2008 11:19:25 +0100
Message-ID: <[e-mail]>
Date: Mon, 20 Oct 2008 11:19:10 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: Questions regarding RFC 5228
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>

Arnt Gulbrandsen wrote:

> Stephan Bosch writes:
>
>> Hello,
>>
>> I am finishing up a first release of my Sieve implementation, and one 
>> of the TODO items that yet remains is getting some answers to 
>> questions that arose during development. I've collected these into a 
>> file an now I submit them to this list to get some clarification. Any 
>> help is greatly appreciated.
>>
>> * RFC 5228 (Sieve) : 5.1.  Test address:
>> "Implementations MUST restrict the address test to headers that 
>> contain addresses, but MUST include at least From, To, Cc, Bcc, 
>> Sender, Resent-From, and Resent-To, and it SHOULD include any other 
>> header that utilizes an "address-list" structured header body."
>>   -> Will this cause a compile error, or are the disallowed headers 
>>  simply ignored? My implementation currently considers this to be a 
>>  compile error.
>
> So does mine.

My implementation allows "address" on any header - it will just try to 
parse it as an email address.

>> -> Given the variables extension, sometimes the specified header 
>> names aren't known until runtime. If the previous answer was to cause 
>> a compile error, should this abort the script at runtime?
>
> I don't have variables (yet?). I expect that I would try to give an 
> error at compile time and to avoid runtime errors.

How would you do that if you supported variables? Are you just going to 
reject the second parameter because it contains a variable reference?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9K9NJ3a091086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2008 02:23:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9K9NJPu091085; Mon, 20 Oct 2008 02:23:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9K9N8lv091074 for <[e-mail]>; Mon, 20 Oct 2008 02:23:19 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 36D3A4AC94; Mon, 20 Oct 2008 11:23:07 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1224494586-66249-6315 for [e-mail]; Mon, 20 Oct 2008 11:23:06 +0200
Message-Id: <[e-mail]>
Date: Mon, 20 Oct 2008 11:21:40 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Questions regarding RFC 5228
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephan Bosch writes:
> Hello,
>
> I am finishing up a first release of my Sieve implementation, and one 
> of the TODO items that yet remains is getting some answers to 
> questions that arose during development. I've collected these into a 
> file an now I submit them to this list to get some clarification. Any 
> help is greatly appreciated.
>
> * RFC 5228 (Sieve) : 5.1.  Test address:
> "Implementations MUST restrict the address test to headers that 
> contain addresses, but MUST include at least From, To, Cc, Bcc, 
> Sender, Resent-From, and Resent-To, and it SHOULD include any other 
> header that utilizes an "address-list" structured header body."
>   -> Will this cause a compile error, or are the disallowed headers 
>  simply ignored? My implementation currently considers this to be a 
>  compile error.

So does mine.

> -> Given the variables extension, sometimes the specified header names 
> aren't known until runtime. If the previous answer was to cause a 
> compile error, should this abort the script at runtime?

I don't have variables (yet?). I expect that I would try to give an 
error at compile time and to avoid runtime errors.

>    * RFC 5228 (Sieve) : 5.4.  Test envelope:
> "The "envelope" test is true if the specified part of the [SMTP] (or 
> equivalent) envelope matches the specified key.  This specification 
> defines the interpretation of the (case insensitive) "from" and "to" 
> envelope-parts.  Additional envelope-parts may be defined by other 
> extensions; implementations SHOULD consider unknown envelope parts an 
> error."

Again, I give an error at compile time, none at runtime.

>   -> Given the variables extension, sometimes the specified envelope 
>  parts aren't known until runtime. Should invalid ones abort the 
>  script or is ignoring them a better practice?

Sieve is a simple language... All commands in a script can be arranged 
into basic blocks, and the basic blocks form a DAG. (I don't remember 
whether this remains true with Ned's MIME/looping extension.)

I wonder whether it is possible to walk along the DAG and say "this 
assignment is invalid since it leads to an error when the variable is 
used".

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9JBKP2s010249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Oct 2008 04:20:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9JBKPed010248; Sun, 19 Oct 2008 04:20:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9JBKEwo010234 for <[e-mail]>; Sun, 19 Oct 2008 04:20:24 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 2AD904AC9A; Sun, 19 Oct 2008 13:20:11 +0200 (CEST)
Received: from [e-mail] (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1224415210-66249-6107 for [e-mail]; Sun, 19 Oct 2008 13:20:10 +0200
Message-Id: <[e-mail]>
Date: Sun, 19 Oct 2008 13:18:43 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
References: <[e-mail]> <WxPyYZT7VbrwFPawr/[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> 2. IMHO dsn-redirect should apply to the vacation and notify/mailto 
>> commands as well as to redirect.
>
> RFC 5230 (vacation), section 5.1 says:
>
>   The SMTP MAIL FROM address of the message envelope SHOULD be set to 
>   <>.  NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the 
>   SMTP transaction if the NOTARY SMTP extension [RFC3461] is 
>   available.

Oh, I'd confused 5230's language with some of that in 5228 4.2. Sorry.

> So what you say would only apply if at least one of the SHOULDs is 
> violated. So I wouldn't bother.

... would only apply to notify/mailto, not to vacation.

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9JBA3Om009630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Oct 2008 04:10:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9JBA3c2009629; Sun, 19 Oct 2008 04:10:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9JB9qqo009603 for <[e-mail]>; Sun, 19 Oct 2008 04:10:02 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.217.73] (92.40.217.73.sub.mbb.three.co.uk [92.40.217.73])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 19 Oct 2008 12:09:50 +0100
Message-ID: <[e-mail]>
Date: Sun, 19 Oct 2008 12:09:36 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
References: <[e-mail]> <WxPyYZT7VbrwFPawr/[e-mail]>
In-Reply-To: <WxPyYZT7VbrwFPawr/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> 2. IMHO dsn-redirect should apply to the vacation and notify/mailto 
> commands as well as to redirect.

RFC 5230 (vacation), section 5.1 says:

   The SMTP MAIL FROM address of the message envelope SHOULD be set to
   <>.  NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the
   SMTP transaction if the NOTARY SMTP extension [RFC3461] is available.

So what you say would only apply if at least one of the SHOULDs is violated. So I wouldn't bother.

> 3. An ORCPT example in the paragraph about ORCPT, something like 
> "rfc822;[e-mail]".

+1



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9JAWQKU007128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Oct 2008 03:32:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9JAWQbJ007127; Sun, 19 Oct 2008 03:32:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9JAWDDU007114 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 19 Oct 2008 03:32:25 -0700 (MST) (envelope-from [e-mail])
Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.31]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <[e-mail]>) id 1KrVX7-0001zW-QW for [e-mail]; Sun, 19 Oct 2008 12:29:13 +0200
Message-ID: <[e-mail]>
Date: Sun, 19 Oct 2008 12:31:58 +0200
From: Stephan Bosch <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: [e-mail]
Subject: Questions regarding RFC 5228
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RenameIT-MailScanner-VirusScan: Found to be clean
X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.126, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 0.87, BAYES_00 -2.60)
X-RenameIT-MailScanner-From: [e-mail]
X-Spam-Status: No
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

I am finishing up a first release of my Sieve implementation, and one of 
the TODO items that yet remains is getting some answers to questions 
that arose during development. I've collected these into a file an now I 
submit them to this list to get some clarification. Any help is greatly 
appreciated.

* RFC 5228 (Sieve) : 5.1.  Test address:
"Implementations MUST restrict the address test to headers that contain 
addresses, but MUST include at least From, To, Cc, Bcc, Sender, 
Resent-From, and Resent-To, and it SHOULD include any other header that 
utilizes an "address-list" structured header body."
   
  -> Will this cause a compile error, or are the disallowed headers 
simply ignored? My implementation currently considers this to be a 
compile error.
  -> Given the variables extension, sometimes the specified header names 
aren't known until runtime. If the previous answer was to cause a 
compile error, should this abort the script at runtime?
    
* RFC 5228 (Sieve) : 5.4.  Test envelope:
"The "envelope" test is true if the specified part of the [SMTP] (or 
equivalent) envelope matches the specified key.  This specification 
defines the interpretation of the (case insensitive) "from" and "to" 
envelope-parts.  Additional envelope-parts may be defined by other 
extensions; implementations SHOULD consider unknown envelope parts an 
error."
   
  -> Given the variables extension, sometimes the specified envelope 
parts aren't known until runtime. Should invalid ones abort the script 
or is ignoring them a better practice?

Regards,

--
Stephan Bosch
[e-mail]




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BGeq9S089363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2008 09:40:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9BGeqH1089362; Sat, 11 Oct 2008 09:40:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BGepxu089356 for <[e-mail]>; Sat, 11 Oct 2008 09:40:51 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.84.137] (92.40.84.137.sub.mbb.three.co.uk [92.40.84.137])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 11 Oct 2008 17:40:48 +0100
Message-ID: <[e-mail]>
Date: Sat, 11 Oct 2008 17:40:40 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Kjetil Torgrim Homme <[e-mail]>
CC: [e-mail]
Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme wrote:

>On Sun, 2008-09-21 at 12:55 +0100, Alexey Melnikov wrote:
>  
>
>>Chris Newman has reviewed the ManageSieve document and sent me the 
>>following comment on Sieve URLs that point to scripts:
>>
>>    
>>
>>>Section 3:
>>>
>>>      
>>>
>>>>        sieveurl-script = "sieve://" [ authority ] "/" scriptname
>>>>        
>>>>
>>>* IMAP URLs made the mistake of confusing the identity used to 
>>>authenticate with the identity that owns the script.  This makes IMAP 
>>>URLs cumbersome. I would strongly encourage a naming model that 
>>>separates the two and keeps the script owner explicit.  For example:
>>>
>>>  sieveurl-script = "sieve://" [ authority ] "/" owner "/" scriptname
>>>      
>>>
>>I agree with Chris, however I am concerned that there are existing 
>>applications using <sieveurl-script> form of Sieve URLs.
>>So I would like to hear from people:
>>1). opinions on whether you think this change is a good or a bad idea
>>    
>>
>
>it might be a good change.  the URI specification as I read it does not
>mandate changes to the userinfo to indicate separate namespaces, but
>it's clearly allowable.  if we put authentication credentials in the
>"authority" (e.g., authz "=" auth ":" password "@" server), this will
>too create a new namespace...
>  
>
Hmm, this is something that no other URI scheme does. So I would rather 
avoid creating a separate syntax.

>oh -- I think the ManageSieve specification should disallow encoding the
>password as part of the URI,
>
As far as I remember the base URI document has already prohibited this 
feature, so I don't think we need to worry about this.

>or it needs to go the whole hog and specify how to encode SASL methods, the need for TLS etc.
>
IMAP URI document did this. I am a big believer in negotiating the best 
security using SASL and TLS, so I don't think there is any benefit.
Certainly not for SASL mechanisms.

>to make the owner an explicit part of the path itself is a clean and
>intuitively understandable solution, especially for listscripts when the
>user is authorised to edit the scripts of many owners.  the other
>alternative is to make it crystal clear that the userinfo component in
>authority indicates the owner, and authorization by other parties can
>not be encoded in the URI.
>  
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BGYpQu089148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2008 09:34:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9BGYpJv089147; Sat, 11 Oct 2008 09:34:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9BGYd3k089136 for <[e-mail]>; Sat, 11 Oct 2008 09:34:50 -0700 (MST) (envelope-from [e-mail])
Received: from [92.40.84.137] (92.40.84.137.sub.mbb.three.co.uk [92.40.84.137])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sat, 11 Oct 2008 17:34:38 +0100
Message-ID: <[e-mail]>
Date: Sat, 11 Oct 2008 17:34:29 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
CC: [e-mail]
Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=
=B2 wrote:

> Hello,

Hi =D0=94=D0=B8=D0=BB=D1=8F=D0=BD,

>>> Section 3:
>>>
>>>>         sieveurl-script =3D "sieve://" [ authority ] "/" scriptname
>>>
>>> * IMAP URLs made the mistake of confusing the identity used to=20
>>> authenticate with the identity that owns the script.  This makes=20
>>> IMAP URLs cumbersome. I would strongly encourage a naming model that=20
>>> separates the two and keeps the script owner explicit.  For example:
>>>
>>>   sieveurl-script =3D "sieve://" [ authority ] "/" owner "/" scriptname
>>
> What about
>    sieveurl-script =3D "sieve://" [ authority ] "/" [owner "/"] scriptname
>
> And missing [owner "/"] implies authentication ID =3D authorization ID

This might work. But I think this would also require that any "/" in the=20
<owner> or <scriptname> be URL %-encoded. This shouldn't be a problem=20
for existing deployments, because I don't think use of "/" in script=20
names is common anyway (and some servers currently disallow it).

>> 1). opinions on whether you think this change is a good or a bad idea
>
> Good.
>
>> 2). if you know of any application using existing <sieveurl-script>=20
>> form (with no "owner").
>
> I used kio_slave on my old computer some years ago, but to what I=20
> remember as "root" I could edit only the global scripts, not the=20
> users' ones. By enhancing the URI with owner-part, the "root" can=20
> access anyscript by just changing the URI (and the client software=20
> then issues an UNAUTHENTICATE/AUTHENTICATE commands to access it).
>
> Alternatively the URI could be "sieve://" [[ owner "@" ] authority]...

<authority> can already contain an optional name of the user the client=20
should authenticate as.
I don't think sticking authorization identity (=3D=3D "owner") would be=20
syntactically valid according to the URI specification.

> As next one could think on a way how the "root" or any other who can=20
> access the script of more than one person can retrieve the list of=20
> script-owners, s/he has access to (in means of URI and protocol command).

This can probably be an extension.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m99IFlP6086643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2008 11:15:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m99IFllk086642; Thu, 9 Oct 2008 11:15:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m99IFlam086636 for <[e-mail]>; Thu, 9 Oct 2008 11:15:47 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 0DC593A67FC; Thu,  9 Oct 2008 11:15:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-freed-sieve-ihave-03.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Thu,  9 Oct 2008 11:15:02 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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


	Title           : Sieve Email Filtering: Ihave Extension
	Author(s)       : N. Freed
	Filename        : draft-freed-sieve-ihave-03.txt
	Pages           : 8
	Date            : 2008-10-09

This document describes the "ihave" extension to the Sieve email
filtering language.  The "ihave" extension provides a means to write
scripts that can take advantage of optional Sieve features but can
still run when those optional features are not available.  The
extension also defines a new error control command intended to be
used to report situations where no combination of available
extensions satisfies the needs of the script.

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

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91ExU5O094798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 07:59:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m91ExUie094797; Wed, 1 Oct 2008 07:59:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91ExIad094784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 1 Oct 2008 07:59:29 -0700 (MST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m91ExH1P023708 for <[e-mail]>; Wed, 1 Oct 2008 10:59:17 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m91ExGak081028 for <[e-mail]>; Wed, 1 Oct 2008 10:59:17 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m91ExGkx018062 for <[e-mail]>; Wed, 1 Oct 2008 10:59:16 -0400
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m91ExG70018053 for <[e-mail]>; Wed, 1 Oct 2008 10:59:16 -0400
Received: from dyn9002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1222873164.3589; Wed, 01 Oct 2008 10:59:24 -0400
Message-ID: <[e-mail]>
Date: Wed, 01 Oct 2008 10:59:14 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-09.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.
> 
> 	Title           : Sieve Notification Mechanism: mailto
> 	Author(s)       : B. Leiba, M. Haardt
> 	Filename        : draft-ietf-sieve-notify-mailto-09.txt
> 	Pages           : 16
> 	Date            : 2008-10-01
> 
> This document describes a profile of the Sieve extension for
> notifications, to allow notifications to be sent by electronic mail.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-mailto-09.txt


There are two changes here:

1. A very small change that makes "don't trigger notifications for
auto-submitted messages" a SHOULD NOT instead of the (old) MUST NOT.  We
clearly agreed on this change, so it shouldn't be an issue.

2. New text in the Security Considerations section that talks a little
more about loop detection/mitigation.  Please review that, and let me
know if you think it's seriously bad, or acceptable to publish.

Assuming that we pass item 2, above, then this should be ready for Lisa
to process with the IESG.

Barry



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91EIHiW091800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 07:18:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m91EIHWl091799; Wed, 1 Oct 2008 07:18:17 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91EI62L091786 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Wed, 1 Oct 2008 07:18:17 -0700 (MST) (envelope-from [e-mail])
Received: from avs02.service.private (avs02.service.private [172.30.31.162]) by mta03.service.private (Sun Java System Messaging Server 6.1 HotFix 0.13 (built Jun  8 2005)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 01 Oct 2008 10:18:06 -0400 (EDT)
Received: from mta-avs03.service.private (mta-avs03.service.private [172.30.30.163]) by avs02.service.private (8.13.8/8.13.8) with ESMTP id m91EHsCi027412	for <[e-mail]>; Wed, 01 Oct 2008 10:18:05 -0400
Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta03.service.private (Sun Java System Messaging Server 6.1 HotFix 0.13 (built Jun  8 2005)) with ESMTPSA id <[e-mail]> for [e-mail]; Wed, 01 Oct 2008 10:18:01 -0400 (EDT)
Date: Wed, 01 Oct 2008 10:18:00 -0400 (EDT)
From: Derek Diget <[e-mail]>
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
In-reply-to: <[e-mail]>
X-X-Sender: [e-mail]
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
X-WMU-PMX-Version: 5.4.5.350696, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.10.1.135514 - Wed Oct  1 10:18:05 2008
X-WMU-PerlMx-Spam: Gauge=, Probability=0% on Wed Oct  1 10:18:05 2008, Report='MSA+ -10, BODY_SIZE_1000_LESS 0, BODY_SIZE_400_499 0, BODY_SIZE_5000_LESS 0, __BOUNCE_CHALLENGE_SUBJ 0, __CP_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 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>

Typo - Section 6, second paragraph, last sentence:  "then" to "them"

>From 

...to request then using the...

To

...to request them using the...



-- 
***********************************************************************
Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA - www.wmich.edu/
***********************************************************************



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

--NextPart

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


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

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

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

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91D296x085901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2008 06:02:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m91D29UJ085900; Wed, 1 Oct 2008 06:02:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from msa.uoa.gr (msa.uoa.gr [195.134.100.72]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m91D1uiW085880 for <[e-mail]>; Wed, 1 Oct 2008 06:02:08 -0700 (MST) (envelope-from [e-mail])
Received: by MSA with id BCD83BBA7F947ED79FA89E725D51E9040FF07F84
Received: from localhost (null.noc.uoa.gr [195.134.100.40]) (authenticated bits=0) by msa.uoa.gr (8.14.1/8.14.1) with ESMTP id m91D1sJ8018699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 1 Oct 2008 16:01:55 +0300 (EEST)
Date: Wed, 1 Oct 2008 16:04:07 +0300
From: Alexandros Vellis <[e-mail]>
To: [e-mail]
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Organization: National and Kapodistrian University of Athens
X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.9; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-UoAMSAId: BCD83BBA7F947ED79FA89E725D51E9040FF07F84
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* Typo: Chapter 7, second capability name should be dsn-redirect. :)

* Idea: Would it make sense to name these capabilities 'envelope-dsn'
and 'redirect-dsn'? Because in a way they extend these existing
capabilities, and also because in the future we could have names like
'envelope-auth' "align" with them.


-- 
Alexandros Vellis
National & Kapodistrian University of Athens
Network Operations Centre