Subject: thoughts about external lists

From: Дилян Палаузов<[email-masked]>
Date: Mon, 27 Oct 2008 23:14:48 +0100

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".

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

---

From: Ned Freed <[email-masked]>
Date: Mon, 27 Oct 2008 15:40:52 -0700 (PDT)

> strings" to a "list of list of strings".

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

> At the same time mixing

> 		 envelope :lists "from" ["my-department", "our-partners"]) { reject

I actually prefer this. Rather strongly.

> 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.

> has just to write that it accepts now string-list instead of just

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

---

From: Дилян Палаузов<[email-masked]>
Date: Tue, 28 Oct 2008 09:09:40 +0100

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.

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

---

From: Ned Freed <[email-masked]>
Date: Tue, 28 Oct 2008 17:34:49 -0700 (PDT)

> 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

Date: Tue, 28 Oct 2008 17:34:49 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: thoughts about external lists
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Cc: IETF Sieve WG <[email-masked]>
Sender: [email-masked]

> 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

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Tue, 28 Oct 2008 09:09:40 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: Re: thoughts about external lists
Sender: [email-masked]

Hello Ned,

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

> contexts, but my proposal is to match :list a new MATCH-TYPE, with all

Date: Mon, 27 Oct 2008 15:40:52 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: thoughts about external lists
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
Cc: IETF Sieve WG <[email-masked]>
Sender: [email-masked]

				Ned

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Mon, 27 Oct 2008 23:14:48 +0100
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: thoughts about external lists
Sender: [email-masked]

Hello,

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

Date: Thu, 23 Oct 2008 12:05:51 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

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 ["[email-masked]", =
"[email-masked]",=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 <[email-masked]>". Then using address :all on list-id=20
stops working and address :localpart starts working.

Arnt

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 22 Oct 2008 17:33:32 -0400
To: [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

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

Date: Tue, 21 Oct 2008 22:58:45 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Questions regarding RFC 5228
Cc: "Mark E. Mallett" <[email-masked]>
Sender: [email-masked]

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

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 21 Oct 2008 16:14:36 -0400
To: [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

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" ] "[email-masked]" {
> >      fileinto "sieve";
> > }
> 
> I hope that users will not relying on their server converting
> ietf-mta-filters.imc.org into [email-masked].  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"] "[email-masked]",
      address :is :all "list-id" "ietf-mta-filters.imc.org" )
     { ... }

(barring typos and errors ..)

mm

Cc: [email-masked]
From: Aaron Stone <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
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
Sender: [email-masked]

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?
>
> [email-masked] 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

Date: Tue, 21 Oct 2008 13:20:45 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
Sender: [email-masked]

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?

[email-masked] 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

Date: Tue, 21 Oct 2008 12:03:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
Sender: [email-masked]

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)

Date: Tue, 21 Oct 2008 12:50:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
Sender: [email-masked]

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

Date: Tue, 21 Oct 2008 11:41:30 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: draft-ietf-sieve-managesieve-00.txt is to replace draft-martin-managesieve-12.txt
Sender: [email-masked]

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.

Subject: Re: Questions regarding RFC 5228
From: Kjetil Torgrim Homme <[email-masked]>
Reply-To: [email-masked]
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Date: Tue, 21 Oct 2008 00:10:22 +0200
Sender: [email-masked]

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:[email-masked]?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" ] "[email-masked]" {
>      fileinto "sieve";
> }

I hope that users will not relying on their server converting
ietf-mta-filters.imc.org into [email-masked].  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.

Date: Tue, 21 Oct 2008 00:00:17 +0200
From: Stephan Bosch <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

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

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-managesieve-00.txt 
Date: Mon, 20 Oct 2008 14:45:01 -0700 (PDT)
Sender: [email-masked]

--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:     <[email-masked]>

--NextPart--

Date: Mon, 20 Oct 2008 23:42:39 +0200
From: Stephan Bosch <[email-masked]>
To: [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

(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.

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 20 Oct 2008 15:48:08 -0400
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

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:[email-masked]?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

Date: Mon, 20 Oct 2008 21:16:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

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:[email-masked]?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" ] "[email-masked]" {
     fileinto "sieve";
}

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

Simplicity is a valuable feature.

Arnt

From: "=?windows-1251?B?TWFuYWdhcl9Gb3h0cm90?=" <[email-masked]>
To: <[email-masked]>
Subject: =?windows-1251?B?wOry8+Dr/O3uIOTr/yDk6PDl6vLu8OAg7+4g7+Xw8e7t4Ovz?=
Date: Mon, 20 Oct 2008 11:33:26 -0700
Sender: [email-masked]

������������ ����: 

________ 

>	��������  ��  ���������  �  �����������  ��������.  �����  ��������������  ������  �  ����������  ����������.
________

(������, ������, ������, ������ ��������, ���������, ����������� ���, ����� ���������� �������� ����������� ����������� ������� �� ������ ��� ������) 

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

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 20 Oct 2008 14:28:02 -0400
To: [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

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

Date: Mon, 20 Oct 2008 09:53:18 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Questions regarding RFC 5228
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> 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

Date: Mon, 20 Oct 2008 12:28:32 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

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

Date: Mon, 20 Oct 2008 11:19:10 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

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?

Date: Mon, 20 Oct 2008 11:21:40 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Questions regarding RFC 5228
Sender: [email-masked]

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

Date: Sun, 19 Oct 2008 13:18:43 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
Sender: [email-masked]

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

Date: Sun, 19 Oct 2008 12:09:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
Sender: [email-masked]

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;[email-masked]".

+1

Date: Sun, 19 Oct 2008 12:31:58 +0200
From: Stephan Bosch <[email-masked]>
To: [email-masked]
Subject: Questions regarding RFC 5228
Sender: [email-masked]

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
[email-masked]

Date: Sat, 11 Oct 2008 17:40:40 +0100
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: [email-masked]
Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol
Sender: [email-masked]

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.
>  
>

Date: Sat, 11 Oct 2008 17:34:29 +0100
From: Alexey Melnikov <[email-masked]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
CC: [email-masked]
Subject: Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol
Sender: [email-masked]

=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=

> 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.

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-freed-sieve-ihave-03.txt 
Date: Thu,  9 Oct 2008 11:15:02 -0700 (PDT)
Sender: [email-masked]

--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:     <[email-masked]>

--NextPart--

Date: Wed, 01 Oct 2008 10:59:14 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-sieve-notify-mailto-09.txt
Sender: [email-masked]

> 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

Date: Wed, 01 Oct 2008 10:18:00 -0400 (EDT)
From: Derek Diget <[email-masked]>
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
To: [email-masked]
Sender: [email-masked]

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/
***********************************************************************

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-sieve-notify-mailto-09.txt 
Date: Wed,  1 Oct 2008 07:15:01 -0700 (PDT)
Sender: [email-masked]

--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:     <[email-masked]>

--NextPart--

Date: Wed, 1 Oct 2008 16:04:07 +0300
From: Alexandros Vellis <[email-masked]>
To: [email-masked]
Subject: Re: WGLC on draft-freed-sieve-notary-01.txt
Organization: National and Kapodistrian University of Athens
Sender: [email-masked]

* 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