Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt (fwd)

From: "Aaron Stone" <[email-masked]>
Date: Thu, 25 Aug 2005 23:58:47 -0000

On Thu, Aug 25, 2005, Kjetil Torgrim Homme <[email-masked]> said:

> On Thu, 2005-08-25 at 15:30 +0000, Aaron Stone wrote:
>> On Thu, Aug 25, 2005, Kjetil Torgrim Homme <[email-masked]> said:
>> > "All variables have global scope: they are visible until processing
>> > stops."
>> > 
>> > I find this sufficiently clear to answer "yes" to all three of Cyrus'
>> > questions, but then I wrote it :-)
>> 
>> I wouldn't have gotten that on my own in a million years, neither in
>> implementing a Sieve interpreter nor in writing my own scripts. 
> 
> okay, would you interpret that statement differently, or is it just
> easily overlooked?

Both... it's only a single sentence, and a major issue. I think a section
entitled "Scope" at around 4.2 or 4.1.4 would be best. Also, when the
issue comes up the user or implementor will have the question, "Why does
my variable contain weird values after an include?" or "Why can't I access
a variable set in another file?" and the answer should be explicit to
those questions.

[snip]
> there is only one script, it just so happens that it may consist of more
> than one file :-)

Ok, but that doesn't change my position ;-)

:local would be like C's static applied to a variable in the file.

>> The very presence of a :global and/or :local modifier makes for an
>> explanation that will clarify things for implementors and end users alike.
>> On this point, what do folks think?
> 
> I don't think it is a very important point.  the scripts I see tend to
> use a "stop" as soon as possible, and there is little need to keep state
> across an include statement.  the risk of having your state trampled on
> is small, especially since you'll tend to control all the script
> components yourself.  indeed, I think it would be more common to use a
> global variable set in the included file to return the result to the
> calling file.

Include will allow more sites to create libraries of common scripts. These
scripts will want to keep most of their namespace clean and/or protected.
Prefixed on the variables might work, but a :local / :global mechanism
would make these protections more explicit.

Aaron

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 26 Aug 2005 03:24:55 +0200

> a variable set in another file?" and the answer should be explicit to

I'm afraid I don't see how to expound on the sentence, since there _is_
only one scope from that draft's perspective.  the issue is better
discussed in the "include" draft.

> would make these protections more explicit.

I'm not opposed to adding a ":local" modifier in the "include" draft.  I
can live with a no-op ":global", too, but I would prefer to not add
redundant elements.

suggested text:

------
4. Interaction with the "variables" extension

        Variables are by default globally scoped, and once set can be accessed until the
        script terminates.  This can lead to unintended name clashes, and to reduce that
        risk, this extension adds a modifier to the "set" action which is available to
        scripts requiring both the "variables" and "include" extensions.

4.1. Modifier ":local"

        A variable value set with the modifier ":local" will shadow the global value until
        the script returns.  This value is unchanged across "include" statements.  In
        contrast with other modifiers for "set", this modifier does not have any particular
        precedence and it does not change the resulting value.

                require "variables";
                set "var" "Hello Kitty";
                if address :localpart "From" "tweety" {
                	set :local "var" "Hello Birdie";
                	set "var" "Tweety says hello";
                }
                
                # At this point, "${var}" can expand to either "Hello Kitty" or "Hello Birdie",
                # never "Tweety says hello".  A script which includes this snippet, will find
                # that "${var}" is either "Hello Kitty" or "Tweety says hello" after the
                # "include", unless it had executed a statement like
                #   set :local "var" "something"
                # prior to the include, in which case "${var}" will still be "something".
-----

the implication here is that you must use :local everytime you set a
local variable.
-- 
Kjetil T.

---

From: "Aaron Stone" <[email-masked]>
Date: Fri, 26 Aug 2005 01:45:54 -0000

>                 	set "var" "Tweety says hello";

Are you implying that we're adding both file scope and curly brace scope?
I have the understanding that curly braces don't have any scope of their
own. Perhaps its just an issue of building out a more complete example?
(Showing two files and the values a variable has in different places.)

Aaron

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 26 Aug 2005 13:08:54 +0200

> Are you implying that we're adding both file scope and curly brace scope?

no.  if you don't specify :local, you are changing the global variable,
even if it is invisible.

okay, so you clearly didn't like these semantics.  since the
implementation must track which scope of the variable is active for
referencing, it might as well use that state to decide which scope to
modify during "set".

new suggested text:
-----
4.1. Scope modifier ":local"

        A variable value set with the modifier ":local" will shadow the
global value until
        the script returns.  This value is unchanged across "include"
statements.
        Subsequent "set" actions will modify the local value unless a
different scope
        modifier has been specified.

        In contrast with other modifiers for "set", this modifier does
not have any
        particular precedence and it does not change the resulting
value.
-----

with these semantics, ":global" wouldn't be a no-op, but what happens in
this example?

    set "var" "a";
    set :local "var" "b";
    set :global "var" "c";
    # what is ${var} here?
    set "var" "d";
    # and here?

I don't think we need ":global", and it would be confusing to use.
-- 
Kjetil T.

---

From: "Nigel Swinson" <[email-masked]>
Date: Fri, 26 Aug 2005 14:44:29 +0100

> I don't think we need ":global", and it would be confusing to use.

I consider PHP a very mature scripting language and I consider thier scoping rules very well thought out most likely very carefully discussed.  After using the language for several years I haven't really found fault with them.  It make me think it's worth copying what they have done.  And thus:

I think Aaron and I are suggesting:

Set file scope variable
    set "var" "Hello Kitty";

Set global scope variable, where global affects all scripts that come into existance with the include spec
    set :global "var" "Hello Kitty";

Set local scope variable, where local affects the current and nested command block (filescope if not currently in a control block.)  (would doubt would ever be used)
    set :local "var" "Hello Kitty";

And Kjetil seems to disagree.  Anybody else out there have any opinions?

Nigel

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Aug 2005 10:04:22 -0400

Hi Nigel,

--On August 26, 2005 2:44:29 PM +0100 Nigel Swinson 
<[email-masked]> wrote:

> I consider PHP a very mature scripting language and I consider thier
> scoping rules very well thought out most likely very carefully discussed.
> After using the language for several years I haven't really found fault
> with them.  It make me think it's worth copying what they have done.  And
> thus:
>
> Set global scope variable, where global affects all scripts that come
> into existance with the include spec     set :global "var" "Hello Kitty";
>
> Set local scope variable, where local affects the current and nested
> command block (filescope if not currently in a control block.)  (would
> doubt would ever be used)     set :local "var" "Hello Kitty";
>

I do think the security concerns that Nigel brought up are valid. As such 
there does need to be a way for script authors to prevent their variables 
from being used either in an included script or by the scripts that include 
it. A simple solution to that would be a ":private" and ":public" scoping 
where ":private" means file scope only. The default is ":public" scope.

One thing with scoping that we also have to be concerned with is handling 
errors. What if a script attempts to use a ":private" variable from another 
script? Should that be a run-time or activation time error? Or should sieve 
do something sensible, e.g. make the new variable ":private" too? It would 
probably be better to have errors at activation time. In fact I would also 
suggest having warnings at activation time to warn of variables from one 
file being used in another, if the user wants to know about it.

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 26 Aug 2005 16:11:39 +0200

Cyrus Daboo writes:
> I do think the security concerns that Nigel brought up are valid. As 
> such there does need to be a way for script authors to prevent their 
> variables from being used either in an included script or by the 
> scripts that include it. A simple solution to that would be a 
> ":private" and ":public" scoping where ":private" means file scope 
> only. The default is ":public" scope.

(If you mean file scope, please call it :file.)

Arnt

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 26 Aug 2005 17:10:59 +0200

> I think Aaron and I are suggesting:

this means the variables draft needs to change.  I don't know how to
express this notion, so please suggest new text.  such a change is no
doubt big enough that we need to cancel the IETF last call and bring the
document back to the working group for a new revision.

>     set :global "var" "Hello Kitty";

   set "var" "a";
   set :global "var" "b";

does "var" have local or global scope now?  similarily:

   set :global "var" "c";
   set "var" "d";

-- 
Kjetil T.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Aug 2005 11:25:59 -0400

Hi Kjetil,

> document back to the working group for a new revision.

I would like to avoid having to redo variables at this point. I would 
prefer any changes to be in the include draft as that is the one causing 
all these problems. As such include should extend variables to cope with 
the specific file-scoping issues that it uniquely causes. Variables itself 
should probably not say anything about this at all now.

-- 
Cyrus Daboo

---

From: Ned Freed <[email-masked]>
Date: Fri, 26 Aug 2005 09:24:36 -0700 (PDT)

> should probably not say anything about this at all now.

I am in complete agreement with Cyrus here. We need to move forward, not 
continuously reexamine every decision we've made.

				Ned

---

From: "Aaron Stone" <[email-masked]>
Date: Fri, 26 Aug 2005 19:19:23 -0000

> should probably not say anything about this at all now.

Thinking some more, Kjetil's one-liner about variable scope in the
variables draft makes perfect sense in the context of there being only one
file in a script. It is the include draft that adds more files, and more
potential scopes, and so in the include draft this should be explained and
accounted for.

I withdraw my complaint about the scope detail in the variables draft :-)

Aaron

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 29 Aug 2005 14:04:32 +0100

> I withdraw my complaint about the scope detail in the variables draft :-)

I am also totally happy with this too.  :o)

It's slightly unfortunate that the term "global variable" in the variables draft may end up meaning "file scope" in the context of variables+include, but I agree that it's not a major issue, and it's not worth holding up the variables draft for.

Nigel

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 30 Aug 2005 18:12:10 +0100

>It's slightly unfortunate that the term "global variable" in the variables draft may end up meaning "file scope" in the context of variables+include, but I agree that it's not a major issue, and it'…
I think we all agree what the term "global variable" means in the 
variables draft.
But if people feel that the term "global variable" might be confusing, 
we can still replace it with something else as an editorial change.

---

From: "Nigel Swinson" <[email-masked]>
Date: Tue, 30 Aug 2005 18:26:33 +0100

> But if people feel that the term "global variable" might be confusing, we 
> can still replace it with something else as an editorial change.

Well at the risk of getting hit, I think it would be wise to change it from:

   All variables have global scope: they are visible until processing
   stops.

To:

   All variables have file scope: they are visible to the remainder
   of the current script.

Nigel

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 30 Aug 2005 22:58:43 +0200

>    All variables have file scope: they are visible to the remainder

the consequence of this is that global variables are only visible in
included scripts if they require the "include" extension themselves.  I
don't think this natural behaviour, and why I have advocated making
variables global by default.

there is an alternative which may be easier to get consensus for:  the
change of text above, and an extra extension, call it "globals".
"globals" adds the :global modifier for "set" _and_ makes already
declared globals available to the current script.

this means that a script will only be able to use the variables it has
set itself unless it explicitly asks to import the globals.

"globals" can be put in the "include"-document, or in a separate
document.  I favour the former as I think there is a natural connection.
(it could also be in "variables", but that would delay the document
needlessly.)
-- 
Kjetil T.

---

From: "Aaron Stone" <[email-masked]>
Date: Tue, 30 Aug 2005 21:03:30 -0000

>    All variables have file scope: they are visible to the remainder

As Kjetil pointed out last week, there is only one script, though there
may be many files included. We should be careful not to confuzzle the two
words. Also, from the point of view of the variables draft in a vacuum,
there is only one file, only one script, and only one scope. 

How about this:

    All variables have global scope within a script. Future specifications
    may allow for a script to be composed of more than one file, or for
    running more than one script per message [delivery?]. Such
    specifications may provide for different variable scoping rules.

Aaron

---

From: "Nigel Swinson" <[email-masked]>
Date: Tue, 30 Aug 2005 22:34:02 +0100

> declared globals available to the current script.

... where a global variable is available both to the current script, to all scripts it includes, and all scripts that include it.

Either of the above would be fine by me, and I agree the latter would be preferable :o)

I consider the contents of a .siv file to be a script.  And that you can build larger scripts by using the include extension.  To declare that "there is only one script" seems quite confusing to me, as what then do you call a .siv file that is included by the parent siv file?  Is it not a script too?  Conveniently, the abstract of the include spec already seems to already fit with my definition of a script.

> set itself unless it explicitly asks to import the globals.

.. and it uses the :global modifier when it uses the set action.
 
> (it could also be in "variables", but that would delay the document

I agree, and again I think it preferable to change the word "global" to "file" in the variables draft in order to avoid confusion generated when reading include+variables.  I would settle for what Aaron just suggested, but it still means we end up with two meanings for the word "global".

Nigel

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 31 Aug 2005 00:30:44 +0200

On Tue, 2005-08-30 at 22:34 +0100, Nigel Swinson wrote:
> ... where a global variable is available both to the current script,
> to all scripts it includes, and all scripts that include it.

there is only one set of global variables, and they are available in all
scripts which require "globals".  (an included script needs to require
_all_ extensions which modify the behaviour of the script.)

> I consider the contents of a .siv file to be a script.  And that you
> can build larger scripts by using the include extension.  To declare
> that "there is only one script" seems quite confusing to me,

I retract that comment.  it obviously is at odds with the terminology
used in the "include" draft.

> .. and it uses the :global modifier when it uses the set action.

no, that is not necessary, the global variable may have been set
previously.
 
> I agree, and again I think it preferable to change the word "global"
> to "file" in the variables draft in order to avoid confusion generated
> when reading include+variables.  I would settle for what Aaron just
> suggested, but it still means we end up with two meanings for the word
> "global".

your suggestion could be used verbatim, IMO:

however, it may be needlessly complicated, and this could do as well:

    Variables are only visible to the currently running script.

an explicit definition of "script" would be nice, but I don't see how we
can do it in 3028bis.  a definition in "include" would be good enough, I
think.  in theory, we could have a situation where two documents define
"script" differently, but even if that is the case, it probably wouldn't
be harmful unless a server implements both documents.
-- 
Kjetil T.

Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: Sieve Mailing List <[email-masked]>
Date: Wed, 31 Aug 2005 00:30:44 +0200
Sender: [email-masked]

On Tue, 2005-08-30 at 22:34 +0100, Nigel Swinson wrote:
> ... where a global variable is available both to the current script,
> to all scripts it includes, and all scripts that include it.

there is only one set of global variables, and they are available in all
scripts which require "globals".  (an included script needs to require
_all_ extensions which modify the behaviour of the script.)

> I consider the contents of a .siv file to be a script.  And that you
> can build larger scripts by using the include extension.  To declare
> that "there is only one script" seems quite confusing to me,

I retract that comment.  it obviously is at odds with the terminology
used in the "include" draft.

> .. and it uses the :global modifier when it uses the set action.

no, that is not necessary, the global variable may have been set
previously.
 
> I agree, and again I think it preferable to change the word "global"
> to "file" in the variables draft in order to avoid confusion generated
> when reading include+variables.  I would settle for what Aaron just
> suggested, but it still means we end up with two meanings for the word
> "global".

your suggestion could be used verbatim, IMO:

however, it may be needlessly complicated, and this could do as well:

    Variables are only visible to the currently running script.

an explicit definition of "script" would be nice, but I don't see how we
can do it in 3028bis.  a definition in "include" would be good enough, I
think.  in theory, we could have a situation where two documents define
"script" differently, but even if that is the case, it probably wouldn't
be harmful unless a server implements both documents.
-- 
Kjetil T.

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>
Cc: "Sieve Mailing List" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Tue, 30 Aug 2005 22:34:02 +0100
Sender: [email-masked]

 

Nigel

Date: Tue, 30 Aug 2005 21:03:30 -0000
To: "Nigel Swinson" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[email-masked]>
Cc: "Sieve Mailing List" <[email-masked]>
Sender: [email-masked]

How about this:

Aaron

Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: Sieve Mailing List <[email-masked]>
Date: Tue, 30 Aug 2005 22:58:43 +0200
Sender: [email-masked]

From: "Nigel Swinson" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>
Cc: "Kjetil Torgrim Homme" <[email-masked]>, "Sieve Mailing List" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Tue, 30 Aug 2005 18:26:33 +0100
Sender: [email-masked]

To:

Nigel 

Date: Tue, 30 Aug 2005 18:12:10 +0100
From: Alexey Melnikov <[email-masked]>
To: Nigel Swinson <[email-masked]>
CC: Kjetil Torgrim Homme <[email-masked]>, Sieve Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Sender: [email-masked]

Date: Tue, 30 Aug 2005 12:24:30 -0400
From: Jonathan Clark <[email-masked]>
Reply-To: Jonathan Clark <[email-masked]>
Organization: Mirapoint Inc
To: [email-masked]
Sender: [email-masked]

subscribe

Jonathan Clark
Solutions Architect
Mirapoint Inc

Date: Tue, 30 Aug 2005 17:14:26 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
CC: Lemonade WG <[email-masked]>
Subject: Sieve management protocol: draft-martin-managesieve-05.txt
Sender: [email-masked]

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: A Protocol for Remotely Managing Sieve Scripts
>	Author(s)	: T. Martin, A. Melnikov
>	Filename	: draft-martin-managesieve-05.txt
>	Pages		: 20
>	Date		: 2005-8-22
>  
>
After multiple recent discussions regarding Sieve management protocol 
I've updated Tim Martin's managesieve draft. My intent is to publish 
this document as Informational or Proposed, as there are multiple 
interoperable implementations already.

I think it would be Ok to discuss the document on Sieve WG mailing list 
<[email-masked]>.

Any comments would be welcome.

Alexey

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>, "Aaron Stone" <[email-masked]>
Cc: "Sieve Mailing List" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Mon, 29 Aug 2005 14:04:32 +0100
Sender: [email-masked]

Nigel

Date: Fri, 26 Aug 2005 19:19:23 -0000
To: "Cyrus Daboo" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[email-masked]>
Cc: "Sieve Mailing List" <[email-masked]>
Sender: [email-masked]

Aaron

Cc: Kjetil Torgrim Homme <[email-masked]>, Nigel Swinson <[email-masked]>, Sieve Mailing List <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Date: Fri, 26 Aug 2005 09:24:36 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Sender: [email-masked]

				Ned

Date: Fri, 26 Aug 2005 11:25:59 -0400
From: Cyrus Daboo <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>, Nigel Swinson <[email-masked]>
cc: Sieve Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Sender: [email-masked]

Hi Kjetil,

-- 
Cyrus Daboo

Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[email-masked]>
To: Nigel Swinson <[email-masked]>
Cc: Sieve Mailing List <[email-masked]>
Date: Fri, 26 Aug 2005 17:10:59 +0200
Sender: [email-masked]

   set "var" "a";
   set :global "var" "b";

   set :global "var" "c";
   set "var" "d";

-- 
Kjetil T.

Date: Fri, 26 Aug 2005 16:11:39 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt (fwd)
Cc: Cyrus Daboo <[email-masked]>, Nigel Swinson <[email-masked]>, Aaron Stone <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

Arnt

Date: Fri, 26 Aug 2005 10:04:22 -0400
From: Cyrus Daboo <[email-masked]>
To: Nigel Swinson <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>, Aaron Stone <[email-masked]>
cc: Sieve Mailing List <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Sender: [email-masked]

Hi Nigel,

-- 
Cyrus Daboo

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>, "Aaron Stone" <[email-masked]>
Cc: "Sieve Mailing List" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Fri, 26 Aug 2005 14:44:29 +0100
Sender: [email-masked]

Set file scope variable
    set "var" "Hello Kitty";

Nigel

Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: Sieve Mailing List <[email-masked]>
Date: Fri, 26 Aug 2005 13:08:54 +0200
Sender: [email-masked]

new suggested text:
-----

    set "var" "a";
    set :local "var" "b";
    set :global "var" "c";
    # what is ${var} here?
    set "var" "d";
    # and here?

Date: Fri, 26 Aug 2005 01:45:54 -0000
To: "Kjetil Torgrim Homme" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[email-masked]>
Cc: "Sieve Mailing List" <[email-masked]>
Sender: [email-masked]

Aaron

Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: Sieve Mailing List <[email-masked]>
Date: Fri, 26 Aug 2005 03:24:55 +0200
Sender: [email-masked]

suggested text:

------

4.1. Modifier ":local"

                require "variables";
                set "var" "Hello Kitty";

Date: Thu, 25 Aug 2005 23:58:47 -0000
To: "Kjetil Torgrim Homme" <[email-masked]>, "Sieve Mailing List" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[email-masked]>
Sender: [email-masked]

[snip]

Aaron

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>
Cc: "Sieve Mailing List" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Fri, 26 Aug 2005 00:45:37 +0100
Sender: [email-masked]

> > A :local modifier would do the trick. The text in the drafts should be
> > more explicit about there being a single global namespace for all scripts.
> 

I can't help wondering if you are making a few assumptions:
- a single author wrote/maintain all the scripts
- all the scripts are quite small or
- all the scripts are sufficiently simple that they can be recalled as a whole

At one level aren't namespaces a tool for protecting you against pollution from some other part of a much larger or multi-authored script.  Other tools for breaking down larger scripts would include things like functions an files.  I'm nervous that by declaring that all variables must be more than just file-scope global that we create a problem for ourselves when/if scripts end up getting seriously large.  I recal seeing a script from one of my customers which was in excess of 64K!

Are there security concerns too.  Server Admin controls script A which includes script B which is controlled by an end-user.  The end user could declare a variable in script B that would alter the behaviour of the remainder of script A after the include?

Nigel

Date: Thu, 25 Aug 2005 23:38:49 -0000
To: "Kjetil Torgrim Homme" <[email-masked]>, <MISSING_MAILBOX_TERMINATOR@.SYNTAX-ERROR>, "Sieve Mailing List" <[email-masked]>, <UNEXPECTED_DATA_AFTER_ADDRESS@.SYNTAX-ERROR>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[email-masked]>
Sender: [email-masked]

[snip]

Aaron

Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Sieve Mailing List <[email-masked]>
Date: Fri, 26 Aug 2005 00:16:17 +0200
Sender: [email-masked]

the draft looks good.  a couple comments:

   SIEVE implementations MUST ensure that recursive includes are not
   possible. i.e. if script "A" includes script "B", and script "B"
   includes script "A" an error MUST be generated either when the script
   is uploaded to the SIEVE repository, or when the script is executed.

this can make uploading difficult, the uploader will have to resolve the
graph and upload in the right order.  I would prefer to change
"uploaded" to "activated".

      :global
         Indicates that the named script is stored in a site-wide SIEVE
         repository, accessible to all users of the SIEVE system.

to avoid possible confusion with scoping, I think ":system" is a better
name.  ":site" is another alternative.

typo section:

   Its convenient to be able to break SIEVE [1] scripts down into
   ===
   and a special 'vacation' script, the later being activated when the
                                        latter(?)
   via an includes in an existing script.  An error MUST be generated
          "include"
   when a missing included script is descovered during execution.  If
                                      =

-- 
Kjetil T.

Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Sieve Mailing List <[email-masked]>
Date: Thu, 25 Aug 2005 23:45:10 +0200
Sender: [email-masked]

> > [:global] would be a no-op, but a :local modifier is definitely possible if
> > needed.
> 
> It would only be a no-op if the default namespace is the global namespace
> ;-) Unless you guys are already deeply along the path of a single
> namespace, I believe a per-file namespace is less likely to cause
> confusing results.

I personally find a global namespace to be the less confusing option.
cutting the script into pieces and including those from a master file
shouldn't change its meaning, IMHO.  (you'll usually need to duplicate
require statements, though.)

> A :local modifier would do the trick. The text in the drafts should be
> more explicit about there being a single global namespace for all scripts.

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 25 Aug 2005 15:27:01 -0400
To: Matthew Elvey <[email-masked]>
Cc: Kjetil Torgrim Homme <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for	draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

On Tue, Aug 23, 2005 at 05:40:27PM -0700, Matthew Elvey wrote:
> 
> Misleading the user into thinking that he's reducing bounces is 
> unacceptable.  I am extremely firmly opposed to any changes that allow 
> refuse and reject to have the exact same results from the users/victim's 
> viewpoint.  The AU's email system is compliant or it isn't.  Saying the 
> system is compliant when just a piece theoretically could be, but when 
> in actual use, the system isn't compliant makes no sense.  It seems 
> we'll have to go for rough consensus, noting this as a point of 
> disagreement.
> (Mark, have I convinced you? It wasn't clear from your last email.)

Not really.  I understand your point of view, though, and agree that
refusal is a good goal, but with a different outlook on the specifics of
getting there.

Anyway, nothing new for me to add.. 

mm

From: "Nigel Swinson" <[email-masked]>
To: "Kjetil Torgrim Homme" <[email-masked]>, "Aaron Stone" <[email-masked]>
Cc: "Sieve Mailing List" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Date: Thu, 25 Aug 2005 17:02:17 +0100
Sender: [email-masked]

> It would only be a no-op if the default namespace is the global namespace
> ;-) Unless you guys are already deeply along the path of a single
> namespace, I believe a per-file namespace is less likely to cause
> confusing results.

FWIW I totally agree.  I wonder if even though the variables spec puts it that way, it would be ok to interpret "Global" as "File scope" and add text to the include draft to permit this.  Indeed it's only with the include extension that the possibility of anything wider than File Scope exists.  I'm also a PHP user and I also think they've done a pretty good job with their :global specifer.

> A :local modifier would do the trick. The text in the drafts should be
> more explicit about there being a single global namespace for all scripts.

I think a :local modifier is a bit of a waste... you'd likely only use it AFTER you'd spent ages debugging an awkward problem.  I'd much rather we helped them avoid the awkward problem in the first place and hence my support for a :superglobal type modifier.

Nigel

Date: Thu, 25 Aug 2005 15:30:05 -0000
To: "Kjetil Torgrim Homme" <[email-masked]>, "Aaron Stone" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[email-masked]>
Cc: "Cyrus Daboo" <[email-masked]>, "Sieve Mailing List" <[email-masked]>
Sender: [email-masked]

On Thu, Aug 25, 2005, Kjetil Torgrim Homme <[email-masked]> said:

> On Thu, 2005-08-25 at 01:59 +0000, Aaron Stone wrote:
>> According to the changelog in the ietf-variables-06 draft, a clarification
>> was made that variables do span includes. I could not find where this was
>> specified in the document, however. It sounds like the open issue is being
>> left to the include draft to resolve ;-)
> 
> this is the text which was added:
> 

>> Applying a PHP-ish model, each file would have a totally clean namespace.
>> If you wanted a variable to cross both namespaces, you would declare it
>> Global. In the ietf-variables-06 draft, section 4.1, gives a list of
>> modifiers. How about a :global modifier?
> 
> that would be a no-op, but a :local modifier is definitely possible if
> needed.

It would only be a no-op if the default namespace is the global namespace
;-) Unless you guys are already deeply along the path of a single
namespace, I believe a per-file namespace is less likely to cause
confusing results.

A :local modifier would do the trick. The text in the drafts should be
more explicit about there being a single global namespace for all scripts.

Aaron

Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: Kjetil Torgrim Homme <[email-masked]>
To: Aaron Stone <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Sieve Mailing List <[email-masked]>
Date: Thu, 25 Aug 2005 17:16:42 +0200
Sender: [email-masked]

On Thu, 2005-08-25 at 01:59 +0000, Aaron Stone wrote:
> According to the changelog in the ietf-variables-06 draft, a clarification
> was made that variables do span includes. I could not find where this was
> specified in the document, however. It sounds like the open issue is being
> left to the include draft to resolve ;-)

this is the text which was added:

> Applying a PHP-ish model, each file would have a totally clean namespace.
> If you wanted a variable to cross both namespaces, you would declare it
> Global. In the ietf-variables-06 draft, section 4.1, gives a list of
> modifiers. How about a :global modifier?

that would be a no-op, but a :local modifier is definitely possible if
needed.
-- 
Kjetil T.

Date: Thu, 25 Aug 2005 01:59:55 -0000
To: "Cyrus Daboo" <[email-masked]>, "Sieve Mailing List" <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
From: "Aaron Stone" <[email-masked]>
Sender: [email-masked]

On Wed, Aug 24, 2005, Cyrus Daboo <[email-masked]> said:

> One other issue: how should include scripts interact with variables? Some 
> questions to illustrate this problem:
> 
> 1) Should a variable defined in a 'parent' script be available in 'child' 
> (included) scripts?
>
> 2) Should a variable defined in a 'child' script be available in the 
> 'parent' script after the point of inclusion? And if so, should those 
> variables be available to other 'child' scripts included after that point?
> 
> 3) Should variables defined in a 'child' script only be local to that 
> script?
> 
> Comments?

According to the changelog in the ietf-variables-06 draft, a clarification
was made that variables do span includes. I could not find where this was
specified in the document, however. It sounds like the open issue is being
left to the include draft to resolve ;-)

I program most frequently in C and in PHP. I can't think how we might
apply any of C's scoping rules because curly braced scopes do not exist in
Sieve. Everything is global. This rather reminds me of PHP, actually.

Applying a PHP-ish model, each file would have a totally clean namespace.
If you wanted a variable to cross both namespaces, you would declare it
Global. In the ietf-variables-06 draft, section 4.1, gives a list of
modifiers. How about a :global modifier?

set :global "a";
# Now ${a} in this script points to the same memory as ${a} everywhere.

But... both set is defined like this:
   Usage:    set [MODIFIER] [COMPARATOR] <name: string> <value: string>

So how about this:

set :global "a" "${a}"

Or perhaps:

set :import "a" "${a_from_my_parent}"
set :export "a_back_to_parent" "${a}"

Aaron

Date: Wed, 24 Aug 2005 19:52:59 -0400
From: Cyrus Daboo <[email-masked]>
To: Sieve Mailing List <[email-masked]>
Subject: I-D ACTION:draft-daboo-sieve-include-03.txt  (fwd)
Sender: [email-masked]

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

Hi folks,
I have published a new version of the include draft. Note that this is NOT 
a working group item - its a personal submission. I am aware of at least 
two implementations of this (one complete, one in progress) and think it 
worth publishing at proposed status, though experimental might also be 
applicable. That's an open question for debate.

One other issue: how should include scripts interact with variables? Some 
questions to illustrate this problem:

1) Should a variable defined in a 'parent' script be available in 'child' 
(included) scripts?

2) Should a variable defined in a 'child' script be available in the 
'parent' script after the point of inclusion? And if so, should those 
variables be available to other 'child' scripts included after that point?

3) Should variables defined in a 'child' script only be local to that 
script?

Comments?

-- 
Cyrus Daboo
--==========B7BCC00AF52DE387B812==========
Content-Type: message/rfc822;
 name="I-D ACTION:draft-daboo-sieve-include-03.txt "

To: [email-masked]
From: [email-masked]
Date: Wed, 24 Aug 2005 15:50:01 -0400
Subject: I-D ACTION:draft-daboo-sieve-include-03.txt 
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SIEVE Email Filtering: Include Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-include-03.txt
	Pages		: 11
	Date		: 2005-8-24
	
The SIEVE Email Filtering "include" extension permits users to
   include one SIEVE script inside another.  This can make managing
   large scripts or multiple sets of scripts much easier, as well as
   supporting common 'libraries' of scripts.  Users are able to include
   their own personal scripts or site-wide scripts provided by the local
   SIEVE implementation.

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

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

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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-daboo-sieve-include-03.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--==========B7BCC00AF52DE387B812==========--

To: [email-masked]
From: [email-masked]
Date: Wed, 17 Aug 2005 15:50:01 -0400
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-variables-06.txt 
Reply-To: [email-masked]
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 Extension: Variables
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-06.txt
	Pages		: 15
	Date		: 2005-8-17
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

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

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

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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-06.txt

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

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Date: Wed, 24 Aug 2005 10:36:45 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Vendor-specific capability strings / extensions
Sender: [email-masked]

On Tue, Aug 23, 2005 at 02:28:55PM -0400, Mark E. Mallett wrote:
> Just curious: is anybody using a vendor-specific capability string for a
> private sieve extension?  I notice that none are registered at
> 
>   http://www.iana.org/assignments/sieve-extensions

I use "vnd.exim.fileinto-max", but the extension is not in the main
distribution.  It implements rolling mailboxes that remove old messages
when delivering new ones, if age, used quota or the number of mails
exceed the specified limit.  Great for folders with announcement lists.

Michael

From: "Nigel Swinson" <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Vendor-specific capability strings / extensions
Date: Wed, 24 Aug 2005 04:08:42 +0100
Sender: [email-masked]

x_body and x_sms.  Both of which had very sketchy I-Drafts when they were implemented.

Nigel
 
----- Original Message ----- 
From: "Mark E. Mallett" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 23, 2005 7:28 PM
Subject: Vendor-specific capability strings / extensions

> 
> 
> Just curious: is anybody using a vendor-specific capability string for a
> private sieve extension?  I notice that none are registered at
> 
>   http://www.iana.org/assignments/sieve-extensions
> 
> mm
> 
> 

Subject: Re: Working Group Last Call for	draft-ietf-sieve-refuse-reject-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Matthew Elvey <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Wed, 24 Aug 2005 03:19:49 +0200
Sender: [email-masked]

On Tue, 2005-08-23 at 17:40 -0700, Matthew Elvey wrote:
> Misleading the user into thinking that he's reducing bounces is 
> unacceptable.  I am extremely firmly opposed to any changes that allow 
> refuse and reject to have the exact same results from the users/victim's 
> viewpoint.  The AU's email system is compliant or it isn't.  Saying the 
> system is compliant when just a piece theoretically could be, but when 
> in actual use, the system isn't compliant makes no sense.  It seems 
> we'll have to go for rough consensus, noting this as a point of 
> disagreement.

I don't think we disagree much, really.

A) a Sieve implementation offering "refuse" is compliant if it is able
to reject the message during the submission attempt.

B) the e-mail system which the Sieve implementation is part of, is only
compliant if the same is true for the submission attempt coming from the
remote system.

it should be possible to evaluate a Sieve implementation's compliance to
the specification on its own.  e.g., Cyrus-IMAPD may be compliant even
if it is impossible to make a compliant system with AcmeMTA and
Cyrus-IMAPD together.  this implies that an implementation of the
"refuse" specification MUST allow the administrator to disable the
extension manually.

> Yup.  Holdover from when there was one action defined.  But let's 
> finalize whether we're merging the two actions first..

ah, good.

> This didn't actually get going:
> > FYI: Alexey and I are discussing the hurdles to merging refuse and 
> > reject and other options and will post about this anon. 
> My feelings: I kind of like this proposal (at least the one-action 
> part), but IIRC, we had run into an issue where some folks demanded to 
> be able to send (non ASCII) text that would only fit in an MDN or DSN, 
> it wouldn't fit in an SMTP response code.    So how can we have one 
> action w/o brushing this issue under the rug? 
> 
> Idea: We can say that a bounce is sent instead of a 550 if the 
> characters specified in the reason string aren't compatible with the 
> character set permitted in an SMTP response.  We can be baroque and add 
> another option, but I'd REALLY like to keep the thing as simple as possible.

when combined with "variables", non-ASCII characters from the message
can be captured and included in the reject message.  since this would
happen during runtime, we can't make it fail too badly.  I think we have
only two options:  turn the reject action into a no-op, or send a DSN.
I prefer the no-op option, with the addition that an implementation
SHOULD reject uploaded scripts which employs the "refuse" extension and
contain verbatim non-ASCII characters in the rejection text.
-- 
Kjetil T.

Date: Tue, 23 Aug 2005 17:40:27 -0700
From: Matthew Elvey <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for	draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

Misleading the user into thinking that he's reducing bounces is 
unacceptable.  I am extremely firmly opposed to any changes that allow 
refuse and reject to have the exact same results from the users/victim's 
viewpoint.  The AU's email system is compliant or it isn't.  Saying the 
system is compliant when just a piece theoretically could be, but when 
in actual use, the system isn't compliant makes no sense.  It seems 
we'll have to go for rough consensus, noting this as a point of 
disagreement.
(Mark, have I convinced you? It wasn't clear from your last email.)

On 8/23/05 4:36 PM, Kjetil Torgrim Homme sent forth electrons to convey:
> the document could benefit from some editorial reorganisation. 
> ...
>
> in my opinion, section 3 should be renamed ("Server architecture
> requirements", perhaps) and made a subsection of section 5.
>   
Yup.  Holdover from when there was one action defined.  But let's 
finalize whether we're merging the two actions first...

This didn't actually get going:
> FYI: Alexey and I are discussing the hurdles to merging refuse and 
> reject and other options and will post about this anon. 
My feelings: I kind of like this proposal (at least the one-action 
part), but IIRC, we had run into an issue where some folks demanded to 
be able to send (non ASCII) text that would only fit in an MDN or DSN, 
it wouldn't fit in an SMTP response code.    So how can we have one 
action w/o brushing this issue under the rug? 

Idea: We can say that a bounce is sent instead of a 550 if the 
characters specified in the reason string aren't compatible with the 
character set permitted in an SMTP response.  We can be baroque and add 
another option, but I'd REALLY like to keep the thing as simple as possible.
Good idea?

Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Wed, 24 Aug 2005 01:36:36 +0200
Sender: [email-masked]

On Tue, 2005-08-23 at 16:01 -0400, Mark E. Mallett wrote:
> On the other hand if the LMTP tool is being called by an MTA that's
> engaged in an SMTP dialog, and the LMTP's 5xx response results in a
> synchronous 5xx SMTP response by the MTA, then the system that combines
> the MTA and LMTP tool is refuse-compliant.  However if then that MTA is
> part of a larger email system that doesn't convey that result
> synchronously, that larger system is no longer compliant with refuse.
> 
> Now: is the Sieve implementation correct, even though bounce messages
> are generated?  I say yes it is, because it is correctly conveying the
> result of the "refuse" action.  The spec should be about correct Sieve
> implementations regardless of their place in the architecture.

I think you are right.  Sieve compliance and overall system architecture
requirements are separate things.  I think both should be addressed in
the spec, though.

the document could benefit from some editorial reorganisation.  in
particular I don't think it flows well to have this TOC:

  1. Introduction                                                   4
  2. Conventions Used in this Document                              4
  3. Discussion of finer points                                     4
  4. SIEVE "reject" extension                                       5
  5. SIEVE "refuse" extension                                       6
  6. Security Considerations                                        8

in my opinion, section 3 should be renamed ("Server architecture
requirements", perhaps) and made a subsection of section 5.

(sorry for not bringing this up before.)
-- 
Kjetil T.

Date: Tue, 23 Aug 2005 13:40:22 -0700
From: Matthew Elvey <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

Misleading the user into thinking that he's reducing bounces is 
unacceptable.  I am extremely firmly opposed to any changes that allow 
refuse and reject to have the exact same results from the users/victim's 
viewpoint.  The AU's email system is compliant or it isn't.  Saying the 
system is compliant when just a piece theoretically could be, but when 
in actual use, the system isn't compliant makes no sense.  It seems 
we'll have to go for rough consensus, noting this as a point of 
disagreement. 
Consider: You can't deduce that 'a boa constrictor is harmless' from the 
fact that 'a dead boa constrictor is harmless'.

On 8/23/05 1:01 PM, Mark E. Mallett sent forth electrons to convey:
> On Tue, Aug 23, 2005 at 12:21:39PM -0700, Matthew Elvey wrote:
>   
>> No, that doesn't address my concern from a previous email:
>>
>> On 8/19/05 2:18 PM, Matthew Elvey sent forth electrons to convey:
>>     
>>> ...[If] a Sieve script running on Dest  encounters a 'refuse', and 
>>> sends a 550 to Relay 2, if Relay 2 then generates a bounce, instead of 
>>> sending a 550 to MSA, then Dest MUST NOT be considered compliant with 
>>> 'refuse'. 
>>>   +------------+                                    +-----------+
>>>   | Originator |                                    | Recipient |
>>>   +-----+------+                                    +-----------+
>>>         |                                                 ^
>>>         |                    Internet                     |
>>>         |                    ___^___                      |
>>>         V                   /       \                     |
>>>     +---------+    +--------+       +---------+      +----+----+
>>>     |         |    |        |       |         |      |         |
>>>     | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
>>>     |         |    |        |       |         |      |         |
>>>     +----+----+    +--------+       +---------+      +---------+
>>>
>>>                                 \_________Destination_AU__________/
>>>
>>>
>>>       
>> That's why we need something like "between Administrative Units" of 
>> "over the open Internet".
>>     

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 23 Aug 2005 16:01:09 -0400
To: Matthew Elvey <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

On Tue, Aug 23, 2005 at 12:21:39PM -0700, Matthew Elvey wrote:
> No, that doesn't address my concern from a previous email:
> 
> On 8/19/05 2:18 PM, Matthew Elvey sent forth electrons to convey:
> >...[If] a Sieve script running on Dest  encounters a 'refuse', and 
> >sends a 550 to Relay 2, if Relay 2 then generates a bounce, instead of 
> >sending a 550 to MSA, then Dest MUST NOT be considered compliant with 
> >'refuse'. 
> >   +------------+                                    +-----------+
> >   | Originator |                                    | Recipient |
> >   +-----+------+                                    +-----------+
> >         |                                                 ^
> >         |                    Internet                     |
> >         |                    ___^___                      |
> >         V                   /       \                     |
> >     +---------+    +--------+       +---------+      +----+----+
> >     |         |    |        |       |         |      |         |
> >     | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
> >     |         |    |        |       |         |      |         |
> >     +----+----+    +--------+       +---------+      +---------+
> >
> >                                 \_________Destination_AU__________/
> >
> >
> That's why we need something like "between Administrative Units" of 
> "over the open Internet".

Yeah, I'd been kind of stewing on that for a while :-)

I think there's some schizophrenia in this discussion as relates to
refuse compliance.  There's one view of compliance that you get when you
focus on any given piece, and another when you combine that piece with
other pieces into a system.  To me, the idea is to make the pieces
compliant, and build compliant systems out of it.  Thus the spec should
say how to make compliant pieces, probably with a discussion about how the
pieces fit into the overall mail system.

If a Sieve implementation exists only in a tool that implements LMTP,
and it does indeed generate a 5xx LMTP response from a refuse verb, then
that specific tool could be viewed as refuse-compliant.  If that tool is
being called by some other program that delivers messages that are
already queued (as LMTP is described in rfc2033 as doing), then that
queue-running tool will probably generate a bounce response, and you
then have system that doesn't implement refuse correctly even if though
the Sieve implementation does.

On the other hand if the LMTP tool is being called by an MTA that's
engaged in an SMTP dialog, and the LMTP's 5xx response results in a
synchronous 5xx SMTP response by the MTA, then the system that combines
the MTA and LMTP tool is refuse-compliant.  However if then that MTA is
part of a larger email system that doesn't convey that result
synchronously, that larger system is no longer compliant with refuse.

Now: is the Sieve implementation correct, even though bounce messages
are generated?  I say yes it is, because it is correctly conveying the
result of the "refuse" action.  The spec should be about correct Sieve
implementations regardless of their place in the architecture.

This is at least one of the things that I am getting at when I say that
focusing on LMTP or SMTP or "over the internet" are all too specific.
It's not important that an implemenation uses LMTP or SMTP to give a 5xx
result, or uses a command line interface and exit with a status code
that indicates refusal, or anything else.  It's important only that that
specific implementation (no matter where or what it is) implement and
report refuse in some way.  That implementation can then be used as part
of some larger system implementation which then has a chance of itself
implementing refuse correctly.  And so on.

IMHO, as always.

mm

Date: Tue, 23 Aug 2005 12:21:39 -0700
From: Matthew Elvey <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

On 8/23/05 11:08 AM, Mark E. Mallett sent forth electrons to convey:
> On Mon, Aug 22, 2005 at 12:41:05PM -0700, Matthew Elvey wrote:
>   
>> On 8/21/05 7:54 AM, Alexey Melnikov sent forth electrons to convey:
>>     
>>> right.  the key is that you decline a message which is sent from a
>>> different administrative domain.  [...] a "refuse" MUST be able
>>> to tell the other administrative domain that the message was rejected
>>> without instantiating the sending of a new message.
>>>       
>> How's this replacement?
>>
>> (The first sentence is unchanged.)
>>
>>   The "refuse" action refuses delivery of a message by sending back
>>
>> the 550 SMTP response code to an SMTP client. This extension can be 
>> supported only by a Sieve implementation capable of sending the 550 over 
>> an SMTP connection between Administrative Units.
>>     
>
> Well, I'm probably being anal (again).  To me, the use of "between
> Administrative Units" and "over the open Internet" are birds of a
> feather.  I don't think it's important to specify where the message is
> transported, or between whom-- only that the message is turned away by
> the receiver during transport, thus avoiding a later asynchronous
> notification via a separate email message.  e.g. I think refusal should
> apply to a transmission to the SMTP server running on localhost.
>
> mm
>   
No, that doesn't address my concern from a previous email:

On 8/19/05 2:18 PM, Matthew Elvey sent forth electrons to convey:
> ...[If] a Sieve script running on Dest  encounters a 'refuse', and 
> sends a 550 to Relay 2, if Relay 2 then generates a bounce, instead of 
> sending a 550 to MSA, then Dest MUST NOT be considered compliant with 
> 'refuse'. 
>    +------------+                                    +-----------+
>    | Originator |                                    | Recipient |
>    +-----+------+                                    +-----------+
>          |                                                 ^
>          |                    Internet                     |
>          |                    ___^___                      |
>          V                   /       \                     |
>      +---------+    +--------+       +---------+      +----+----+
>      |         |    |        |       |         |      |         |
>      | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
>      |         |    |        |       |         |      |         |
>      +----+----+    +--------+       +---------+      +---------+
>
>                                  \_________Destination_AU__________/
>
>
That's why we need something like "between Administrative Units" of 
"over the open Internet".

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 23 Aug 2005 15:02:57 -0400
To: Kjetil Torgrim Homme <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

On Tue, Aug 23, 2005 at 08:56:57PM +0200, Kjetil Torgrim Homme wrote:
> On Tue, 2005-08-23 at 14:08 -0400, Mark E. Mallett wrote:
> > On Mon, Aug 22, 2005 at 12:41:05PM -0700, Matthew Elvey wrote:
> > > How's this replacement?
> > > 
> > > (The first sentence is unchanged.)
> > > 
> > >   The "refuse" action refuses delivery of a message by sending back
> > > 
> > > the 550 SMTP response code to an SMTP client. This extension can be 
> > > supported only by a Sieve implementation capable of sending the 550 over 
> > > an SMTP connection between Administrative Units.
> > 
> > Well, I'm probably being anal (again).  To me, the use of "between
> > Administrative Units" and "over the open Internet" are birds of a
> > feather.
> 
> the current draft doesn't say "over the open Internet", so I don't see
> how this is relevant?

It's relevant because I thought the use of "administrative unit" was
a suggested replacement for "over the open internet" elsewhere in
this thread.  Did I misunderstand?

mm

Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Tue, 23 Aug 2005 20:56:57 +0200
Sender: [email-masked]

On Tue, 2005-08-23 at 14:08 -0400, Mark E. Mallett wrote:
> On Mon, Aug 22, 2005 at 12:41:05PM -0700, Matthew Elvey wrote:
> > How's this replacement?
> > 
> > (The first sentence is unchanged.)
> > 
> >   The "refuse" action refuses delivery of a message by sending back
> > 
> > the 550 SMTP response code to an SMTP client. This extension can be 
> > supported only by a Sieve implementation capable of sending the 550 over 
> > an SMTP connection between Administrative Units.
> 
> Well, I'm probably being anal (again).  To me, the use of "between
> Administrative Units" and "over the open Internet" are birds of a
> feather.

the current draft doesn't say "over the open Internet", so I don't see
how this is relevant?

"Administrative Units" would have to be defined, though.

> I don't think it's important to specify where the message is
> transported, or between whom-- only that the message is turned away by
> the receiver during transport, thus avoiding a later asynchronous
> notification via a separate email message.  e.g. I think refusal should
> apply to a transmission to the SMTP server running on localhost.

is an e-mail system which accepts all e-mail but sticks it in a
directory where it is subsequently picked up by a spam classifier, which
in turn resubmits the message via SMTP on localhost where the Sieve
script is run (*deep breath*) allowed to offer "refuse"?  I'd say no,
since the 550 will not be able to reach the previous e-mail system.

an MTA which doesn't double as a MDA will have to use a callout to the
next hop in the system and wait for its response before passing the
answer back to the other e-mail system.  (a system which does queueing
in some circumstances is fine, but queueing shouldn't be normal
behaviour.)
-- 
Kjetil T.

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 23 Aug 2005 14:28:55 -0400
To: [email-masked]
Subject: Vendor-specific capability strings / extensions
Sender: [email-masked]

Just curious: is anybody using a vendor-specific capability string for a
private sieve extension?  I notice that none are registered at

  http://www.iana.org/assignments/sieve-extensions

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 23 Aug 2005 14:08:17 -0400
To: Matthew Elvey <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

On Mon, Aug 22, 2005 at 12:41:05PM -0700, Matthew Elvey wrote:
> On 8/21/05 7:54 AM, Alexey Melnikov sent forth electrons to convey:
> >right.  the key is that you decline a message which is sent from a
> >different administrative domain.  [...] a "refuse" MUST be able
> >to tell the other administrative domain that the message was rejected
> >without instantiating the sending of a new message.
> How's this replacement?
> 
> (The first sentence is unchanged.)
> 
>   The "refuse" action refuses delivery of a message by sending back
> 
> the 550 SMTP response code to an SMTP client. This extension can be 
> supported only by a Sieve implementation capable of sending the 550 over 
> an SMTP connection between Administrative Units.

Well, I'm probably being anal (again).  To me, the use of "between
Administrative Units" and "over the open Internet" are birds of a
feather.  I don't think it's important to specify where the message is
transported, or between whom-- only that the message is turned away by
the receiver during transport, thus avoiding a later asynchronous
notification via a separate email message.  e.g. I think refusal should
apply to a transmission to the SMTP server running on localhost.

mm

Date: Mon, 22 Aug 2005 12:41:05 -0700
From: Matthew Elvey <[email-masked]>
To: Alexey Melnikov <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

On 8/21/05 7:54 AM, Alexey Melnikov sent forth electrons to convey:
>>> Draft:
>>>>> 5.1  Action refuse
>>>>> ...
>>>>> This extension can be only supported by a Sieve implementation
>>>>> running in an MTA.
>>>>>       
>>>>
>>
>>
> So, possible solutions to address this issue:
> 1). delete the sentence.
> 2). reword to be less prescriptive.
>
> Which one do you prefer? 
Let's reword/replace using the 'key' Kjetil suggested thus:
> right.  the key is that you decline a message which is sent from a
> different administrative domain.  [...] a "refuse" MUST be able
> to tell the other administrative domain that the message was rejected
> without instantiating the sending of a new message.
How's this replacement?

(The first sentence is unchanged.)

   The "refuse" action refuses delivery of a message by sending back

the 550 SMTP response code to an SMTP client. This extension can be 
supported only by a Sieve implementation capable of sending the 550 over 
an SMTP connection between Administrative Units.

Date: Sun, 21 Aug 2005 15:54:35 +0100
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

Mark E. Mallett wrote:

>On Fri, Aug 19, 2005 at 11:44:39AM +0100, Alexey Melnikov wrote:
>  
>
>>Mark E. Mallett wrote:
>>    
>>
>>>>5.1  Action refuse
>>>>  
>>>>
>>>> The "refuse" action refuses delivery of a message by sending back
>>>> the 550 SMTP response code to an SMTP client.
>>>>
>>>> This extension can be only supported by a Sieve implementation
>>>> running in an MTA.
>>>>        
>>>>
>>> 
>>>The way this is worded, an implementation that communicates with an MTA
>>>via LMTP (or any other protocol or mechanism, for that matter) is
>>>prohibited from using "refuse."  There are multiple ways that an MDA may
>>>be invoked by an MTA during the SMTP dialog, where refusal can be
>>>communicated back to the SMTP client.  The MTA itself isn't necessarily
>>>(and probably isn't likely to be) running the Sieve script itself.
>>>      
>>>
>>The current copy we are editing says "running in an MTA or MDA". Does 
>>this address your concern?
>>    
>>
>
>I think it's too specific; as Matthew said in another note, the
>important point is that it's running on behalf of an MTA, or via some
>mechanism under which the response is communicated to the SMTP client at
>SMTP time.  You don't have to list the ways that this can be done, other
>than providing some examples.  An MDA is one example, but it doesn't
>have to be the only one.
>  
>
So, possible solutions to address this issue:
1). delete the sentence.
2). reword to be less prescriptive.

Which one do you prefer?

>>>And actually I am not sure that LMTP needs to be mentioned in the
>>>document at all, other than as an example of one of the ways that an MTA
>>>and an MDA might communicate during the SMTP dialog.  The important thing
>>>is that the Sieve script is being run at SMTP time and its results are
>>>somehow used by the MTA to respond to the SMTP client.
>>>      
>>>
>>I actually disagree. The sieve engine I am working on runs in LMTP 
>>server, it is the one that has to implement refuse.
>>    
>>
>
>Well I agree with you, so I must have been unclear :-)
>  
>
Yes, I've misunderstood you.

>It's the same sort of thing as my comment above, about the difference
>between mandating one or more implementations or protocols (e.g. LMTP),
>vs giving those protocols as examples.  It's the difference between
>saying "MUST use LMTP or be implemented in the MTA" and "may, for
>example, use LMTP or may, for example, be implemented in the MTA."
>  
>

Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Sat, 20 Aug 2005 04:46:34 +0200
Sender: [email-masked]

On Fri, 2005-08-19 at 14:13 -0400, Mark E. Mallett wrote:
> I snipped a bunch, hope that's OK, because I only wanted to remark on
> the "over the open internet" part.  I don't think it's important what
> the medium/network/what-have-you is, it's important that the result be
> given to the originating client, probably via SMTP.

right.  the key is that you decline a message which is sent from a
different administrative domain.  it doesn't matter what how many hops
and database checks your local system performs.  a "refuse" MUST be able
to tell the other administrative domain that the message was rejected
without instantiating the sending of a new message.
-- 
Kjetil T.

Date: Fri, 19 Aug 2005 14:18:11 -0700
From: Matthew Elvey <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: Alexey Melnikov <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------080102040308010403040909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 8/19/05 11:13 AM, Mark E. Mallett sent forth electrons to convey:
>
> I snipped a bunch, hope that's OK, because I only wanted to remark on
> the "over the open internet" part.  
Me too. :)

See txt pic below (view in a fixed-width font)

Example: If the destination AU (using 
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt 
terminology; AU=Administrative Unit)
is bigcompany.dom, and Relay2 is some MTA that just relays mail, and is 
under the control of the destination AU, then if a Sieve script running 
on Dest  encounters a 'refuse', and sends a 550 to Relay 2, if Relay 2 
then generates a bounce, instead of sending a 550 to MSA, then Dest MUST 
NOT be considered compliant with 'refuse'. 

   +------------+                                    +-----------+
   | Originator |                                    | Recipient |
   +-----+------+                                    +-----------+
         |                                                 ^
         |                    Internet                     |
         |                    ___^___                      |
         V                   /       \                     |
     +---------+    +--------+       +---------+      +----+----+
     |         |    |        |       |         |      |         |
     | Source  +--->| MSA    +------>|  Relay2 +----> |  Dest   |
     |         |    |        |       |         |      |         |
     +----+----+    +--------+       +---------+      +---------+

                                 \_________Destination_AU__________/

Further example: If Dest was once reachable directly from the Internet 
and supported 'refuse', and was then protected by Relay2 then (depending 
on Relay2's abilities) Dest might no longer support 'refuse', through no 
fault of the coder of the software on Dest.  It would be the AU 
administrator's responsibility to support 'refuse', or stop claiming to 
support it.

BTW, fastmail handles *outgoing* mail like this - synchronously: If I 
try to send to [email-masked], I an error  message pops up in my 
mail client (Thunderbird). (I've attached a .png screen shot, which may 
well not make it through to your screen.)  (This is far superior to 
getting a message in my inbox from the postmaster/mailer-daemon.)

 error msg

--------------080102040308010403040909
Content-Type: multipart/related;
 boundary="------------040000040500020505030104"

--------------040000040500020505030104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 8/19/05 11:13 AM, Mark E. Mallett sent forth electrons to convey:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap=""><!---->
I snipped a bunch, hope that's OK, because I only wanted to remark on
the "over the open internet" part.  </pre>
</blockquote>
Me too. :)<br>
<br>
See txt pic below (view in a fixed-width font)<br>
<br>
Example: If the destination AU (using
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt">http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt</a>
terminology; AU=Administrative Unit)<br>
is bigcompany.dom, and Relay2 is some MTA that just relays mail, and is
under the control of the destination AU, then if a Sieve script running
on Dest&nbsp; encounters a 'refuse', and sends a 550 to Relay 2, if Relay 2
then generates a bounce, instead of sending a 550 to MSA, then Dest
MUST NOT be considered compliant with 'refuse'.&nbsp; <br>
<pre>   +------------+                                    +-----------+
   | Originator |                                    | Recipient |
   +-----+------+                                    +-----------+
         |                                                 ^
         |                    Internet                     |
         |                    ___^___                      |
         V                   /       \                     |
     +---------+    +--------+       +---------+      +----+----+
     |         |    |        |       |         |      |         |
     | Source  +---&gt;| MSA    +------&gt;|  Relay2 +----&gt; |  Dest   |
     |         |    |        |       |         |      |         |
     +----+----+    +--------+       +---------+      +---------+

                                 \_________Destination_AU__________/

</pre>
<p>Further example: If Dest was once reachable directly from the
Internet and supported 'refuse', and was then protected by Relay2 then
(depending on Relay2's abilities) Dest might no longer support
'refuse', through no fault of the coder of the software on Dest.&nbsp; It
would be the AU administrator's responsibility to support 'refuse', or
stop claiming to support it.<br>
</p>
<p>BTW, fastmail handles *outgoing* mail like this - synchronously: If
I try to send to <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>, I an error&nbsp; message pops up in my
mail client (Thunderbird). (I've attached a .png screen shot, which may
well not make it through to your screen.)&nbsp; (This is far superior to
getting a message in my inbox from the postmaster/mailer-daemon.)<br>
</p>
<br>
<br>
&nbsp;<img alt="error msg" src="cid:[email-masked]"
 height="258" width="466"><br>
<br>
</body>
</html>

--------------040000040500020505030104
Content-Type: image/png; x-mac-type="0"; x-mac-creator="0";
 name="Picture 2.png"
Content-Transfer-Encoding: base64
Content-ID: <[email-masked]>
Content-Disposition: inline;
 filename="Picture 2.png"

--------------040000040500020505030104--

--------------080102040308010403040909--

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 19 Aug 2005 14:13:41 -0400
To: Matthew Elvey <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, "Mark E. Mallett" <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

On Fri, Aug 19, 2005 at 09:09:21AM -0700, Matthew Elvey wrote:
> I think we may need to refer to the fact that what we're concerned about 
> is that if there's an SMTP connection over the open Internet, it is the 
> one where we require the rejection to take place.

   ...

>  This extension can only be supported by a Sieve implementation
>   that is invoked on behalf of the MTA during SMTP time, and that
>   can communicate its results to the MTA which can then return a
>   status to the SMTP client on the other side of every SMTP connection 
> over the open Internet over which mail is received.
> 
> "on the other side of every SMTP connection over the open Internet" is 
> intended to make clear that the 550 goes to the generally distant, 
> untrusted client.

I snipped a bunch, hope that's OK, because I only wanted to remark on
the "over the open internet" part.  I don't think it's important what
the medium/network/what-have-you is, it's important that the result be
given to the originating client, probably via SMTP.  I'd even go so far
as to say that "refuse" should apply to any protocol where messages are
transported, and that SMTP is being used in the document as an example
protocol, even though it's the example that applies to the vast majority
of probable implementations.  But perhaps you can only carry
non-specificness so far.

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 19 Aug 2005 13:48:03 -0400
To: Alexey Melnikov <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

On Fri, Aug 19, 2005 at 11:44:39AM +0100, Alexey Melnikov wrote:
> Mark E. Mallett wrote:
> 
> >>5.1  Action refuse
> >>   
> >>
> >>  The "refuse" action refuses delivery of a message by sending back
> >>  the 550 SMTP response code to an SMTP client.
> >>
> >>  This extension can be only supported by a Sieve implementation
> >>  running in an MTA.
> >  
> >The way this is worded, an implementation that communicates with an MTA
> >via LMTP (or any other protocol or mechanism, for that matter) is
> >prohibited from using "refuse."  There are multiple ways that an MDA may
> >be invoked by an MTA during the SMTP dialog, where refusal can be
> >communicated back to the SMTP client.  The MTA itself isn't necessarily
> >(and probably isn't likely to be) running the Sieve script itself.
> > 
> The current copy we are editing says "running in an MTA or MDA". Does 
> this address your concern?

I think it's too specific; as Matthew said in another note, the
important point is that it's running on behalf of an MTA, or via some
mechanism under which the response is communicated to the SMTP client at
SMTP time.  You don't have to list the ways that this can be done, other
than providing some examples.  An MDA is one example, but it doesn't
have to be the only one.

> >And actually I am not sure that LMTP needs to be mentioned in the
> >document at all, other than as an example of one of the ways that an MTA
> >and an MDA might communicate during the SMTP dialog.  The important thing
> >is that the Sieve script is being run at SMTP time and its results are
> >somehow used by the MTA to respond to the SMTP client.
> >
> I actually disagree. The sieve engine I am working on runs in LMTP 
> server, it is the one that has to implement refuse.

Well I agree with you, so I must have been unclear :-)
It's the same sort of thing as my comment above, about the difference
between mandating one or more implementations or protocols (e.g. LMTP),
vs giving those protocols as examples.  It's the difference between
saying "MUST use LMTP or be implemented in the MTA" and "may, for
example, use LMTP or may, for example, be implemented in the MTA."

mm

Date: Fri, 19 Aug 2005 09:09:21 -0700
From: Matthew Elvey <[email-masked]>
To: Alexey Melnikov <[email-masked]>
CC: "Mark E. Mallett" <[email-masked]>, IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

FYI: Alexey and I are discussing the hurdles to merging refuse and 
reject and other options and will post about this anon.

On 8/19/05 3:44 AM, Alexey Melnikov sent forth electrons to convey:
>
> Mark E. Mallett wrote:
> .......
>> So it's really "when more than one RCPT TO has been
>> accepted" instead of "when a message has multiple valid recipients."
>> (picky, I know.)
>>  
>>
> That is exactly what Matthew and I were trying to say, but your 
> suggested text is much clearer. Thanks.
Right.
>
>>> 4.2  "reject" compatibility with other actions
>>>   
>>>   Implementations MUST prohibit more than one reject in a SIEVE
>>>   script.
>>>   
>>
>> must prohibit "the execution of..."  (certainly more than one reject can
>> appear in a script).
>>  
>>
> Yes. Fixed.
:)
>
>>> 5.1  Action refuse
>>>   
>>>   The "refuse" action refuses delivery of a message by sending back
>>>   the 550 SMTP response code to an SMTP client.
>>>
>>>   This extension can be only supported by a Sieve implementation
>>>   running in an MTA.
>>>   
>>   The way this is worded, an implementation that communicates with an 
>> MTA
>> via LMTP (or any other protocol or mechanism, for that matter) is
>> prohibited from using "refuse."  There are multiple ways that an MDA may
>> be invoked by an MTA during the SMTP dialog, where refusal can be
>> communicated back to the SMTP client.  The MTA itself isn't necessarily
>> (and probably isn't likely to be) running the Sieve script itself.
>>  
>>
> The current copy we are editing says "running in an MTA or MDA". Does 
> this address your concern?
> The intent was certainly to allow for MDA.
>
> Regarding MTA/MDA executing Sieve directly versa an external process 
> MTA/MDA is talking to: I certainly would want to allow for both, as 
> this is an implementation detail. So do you think "running in an MTA 
> or MDA" can be interpreted to mean that an external process is not 
> allowed?
> How should we make the clear?
I think we may need to refer to the fact that what we're concerned about 
is that if there's an SMTP connection over the open Internet, it is the 
one where we require the rejection to take place.  I'm not sure how to 
word that. Maybe that's the right wording to use. Maybe
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-04.txt has 
better terms for this.  It's an SMTP connection between Edge MTAs of 
different AUs?   Perhaps Dave Crocker would provide advice on good 
wording, using his draft.
>
>> And actually I am not sure that LMTP needs to be mentioned in the
>> document at all, other than as an example of one of the ways that an MTA
>> and an MDA might communicate during the SMTP dialog.  The important 
>> thing
>> is that the Sieve script is being run at SMTP time and its results are
>> somehow used by the MTA to respond to the SMTP client.
>>  
>>
> I actually disagree. The sieve engine I am working on runs in LMTP 
> server, it is the one that has to implement refuse.
>
>>    This extension can only be supported by a Sieve implementation
>>    that is invoked on behalf of the MTA during SMTP time, and that
>>    can communicate its results to the MTA which can then return a
>>    status to the SMTP client.
Getting there.
How' bout
  This extension can only be supported by a Sieve implementation
   that is invoked on behalf of the MTA during SMTP time, and that
   can communicate its results to the MTA which can then return a
   status to the SMTP client on the other side of every SMTP connection 
over the open Internet over which mail is received.

"on the other side of every SMTP connection over the open Internet" is 
intended to make clear that the 550 goes to the generally distant, 
untrusted client.

 "over which mail is received." is there just so that we aren't 
inadvertently disallowing the blocking of  connections (e.g. from known 
bad actors) before Sieve sees them.
>>
>> Another somewhat thorny point is that a Sieve script may be invoked at
>> the time when the SMTP server sees the "RCPT TO" so that the refusal may
>> be communicated to the SMTP client at that time (before DATA).  At this
>> stage, various Sieve facilities (e.g. header tests, fileinto, keep) are
>> not available.  I don't know whether this has to be mentioned in this
>> draft, but once you have "refuse" capability, this does come into play.
>>  
>>
> Running Sieve scripts before message headers/body are available is 
> certainly possible and not prohibited by the draft.
> However I think this is somewhat outside the scope for the document, 
> as this is effectively a different Sieve profile.
>
>>
>>  <snip>
>>
> Both fixed, thanks.
>
Yeah, thanks.  :)

To: [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
From: Michael Haardt <[email-masked]>
Date: Fri, 19 Aug 2005 13:00:52 +0200
Sender: [email-masked]

>  Any line MUST NOT exceed SMTP limit on the maximal line length. The 
> server MAY insert CRLFs to make the reason string conform to any such 
> limits.
>
> Does this address your issue?

I prefer an error upon violating the limit, not leaving it up to the
implementation to work around the violating by folding lines, but it
does address my issue.  Thanks!

Michael

Date: Fri, 19 Aug 2005 11:44:39 +0100
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

Mark E. Mallett wrote:

>>3.   Discussion of finer points
>>   
>>   The "refuse" action MUST refuse to accept an email for delivery at
>>   the SMTP/LMTP level by returning a 5XX reply code, instead of
>>   sending an MDN as required by the "reject" action, other than for
>>   the two exceptions specified below.  A SIEVE implementation that
>>   cannot do so MUST NOT claim to support the refuse extension.
>>    
>>
>   
>This means that scripts have to be written with awareness of the site's
>email delivery architecture, and if that architecture changes, all
>scripts have to change.  I think this is a big burden on both script
>writers and site admins.  Even if approach is to have separate "reject"
>and "refuse" verbs, I'd like to see some way of avoiding this burden.
>  
>
>>   There is an exception when a message has multiple valid recipients,
>>   and at least one but not all of them are refusing delivery (whether
>>   the refusal is caused by execution of a Sieve "refuse" or for
>>   another reason). In this case, the server MUST accept the message
>>   and generate DSNs for all recipients that are refusing it.
>>    
>>
>
>I get what this is saying, but I don't think this is said exactly right.
>An SMTP server can issue 4xx deferal codes for some of the valid
>recipients.  This can be done for various reasons, e.g. if some of the
>valid recipients are over quota, or if the SMTP server is using a trick
>to allow it to do post-DATA rejection by only focusing on one recipient
>at a time (I don't know if anybody actually does this, but I've heard it
>proposed..).  So it's really "when more than one RCPT TO has been
>accepted" instead of "when a message has multiple valid recipients."
>(picky, I know.)
>  
>
That is exactly what Matthew and I were trying to say, but your 
suggested text is much clearer. Thanks.

>>4.2  "reject" compatibility with other actions
>>    
>>
>>   Implementations MUST prohibit more than one reject in a SIEVE
>>   script.
>>    
>>
>
>must prohibit "the execution of..."  (certainly more than one reject can
>appear in a script).
>  
>
Yes. Fixed.

>>5.1  Action refuse
>>    
>>
>>   The "refuse" action refuses delivery of a message by sending back
>>   the 550 SMTP response code to an SMTP client.
>>
>>   This extension can be only supported by a Sieve implementation
>>   running in an MTA.
>>    
>>
>   
>The way this is worded, an implementation that communicates with an MTA
>via LMTP (or any other protocol or mechanism, for that matter) is
>prohibited from using "refuse."  There are multiple ways that an MDA may
>be invoked by an MTA during the SMTP dialog, where refusal can be
>communicated back to the SMTP client.  The MTA itself isn't necessarily
>(and probably isn't likely to be) running the Sieve script itself.
>  
>
The current copy we are editing says "running in an MTA or MDA". Does 
this address your concern?
The intent was certainly to allow for MDA.

Regarding MTA/MDA executing Sieve directly versa an external process 
MTA/MDA is talking to: I certainly would want to allow for both, as this 
is an implementation detail. So do you think "running in an MTA or MDA" 
can be interpreted to mean that an external process is not allowed?
How should we make the clear?

>And actually I am not sure that LMTP needs to be mentioned in the
>document at all, other than as an example of one of the ways that an MTA
>and an MDA might communicate during the SMTP dialog.  The important thing
>is that the Sieve script is being run at SMTP time and its results are
>somehow used by the MTA to respond to the SMTP client.
>  
>
I actually disagree. The sieve engine I am working on runs in LMTP 
server, it is the one that has to implement refuse.

>    This extension can only be supported by a Sieve implementation
>    that is invoked on behalf of the MTA during SMTP time, and that
>    can communicate its results to the MTA which can then return a
>    status to the SMTP client.
>
>Another somewhat thorny point is that a Sieve script may be invoked at
>the time when the SMTP server sees the "RCPT TO" so that the refusal may
>be communicated to the SMTP client at that time (before DATA).  At this
>stage, various Sieve facilities (e.g. header tests, fileinto, keep) are
>not available.  I don't know whether this has to be mentioned in this
>draft, but once you have "refuse" capability, this does come into play.
>  
>
Running Sieve scripts before message headers/body are available is 
certainly possible and not prohibited by the draft.
However I think this is somewhat outside the scope for the document, as 
this is effectively a different Sieve profile.

>>      Example:
>>      require ["refuse", "spamtest"]
>>    
>>
>
>the missing comparator was already mentioned, but it also needs
>"fileinto" for the elsif to work.
>  
>
>>      if spamtest :value "ge" :comparator "i;ascii-numeric" "6" {
>>                   refuse text:
>>   SpamAssassin thinks the message is spam.
>>   It is therefore being refused.
>>   Please call 1-900-PAY-US if you want to reach us.
>>   .
>>                            ;
>>    
>>
>add "}" here.
>  
>
Both fixed, thanks.

>>      elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" {
>>                   fileinto "Suspect";
>>                  }
>>    
>>

Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Date: Fri, 19 Aug 2005 02:16:33 +0200
Sender: [email-masked]

On Thu, 2005-08-18 at 15:06 -0400, Mark E. Mallett wrote:
> Basically:
> 
>    reject [:discard/:keep/:notify] "reason";
> 
> where with no tagged argument, 5xx at SMTP time is done if possible, and
> if not possible, a site-imposed default action would be taken (which
> might be either "discard" or "keep" or "send a notification").

I would prefer an option to make reject "stop" if successful, so you
could simply do:

   reject :refuse :stop "Don't send e-mail to this address";
   fileinto "INBOX.old-address";
   stop;

seems easier than to add all possible actions as options to reject :-).
clearly this requires a small change to the following text:

   Implementations SHOULD prohibit reject when used with other
   actions.

a reject without :refuse would always be successful, since it does best
effort: SMTP time or send bounce message.

we might not need a :stop, we could make :refuse work that way always,
but I think it is better to be explicit about it.

> Drawbacks of a unified approach that I can think of:
> 
>  - Any new syntax would have to be enabled via a new capability.  Here,
>    I would say that ' require "refuse"; ' would enable the new syntax,
>    but the new behavior (i.e., of attempting to turn away the message at
>    SMTP time, with site-specific fallback action) would not require the
>    new capability.  The new behavior would simply be specified in this
>    draft.

right.  I don't see how this is a drawback?  a capability which implies
another would be a first for Sieve, but I think it is a natural thing to
do.

>  - If a Sieve script is invoked when "RCPT TO" is seen, various other
>    Sieve facilities are not available (header tests, fileinto, etc).
>    There may be a need for the script writer to be aware of this.  But I
>    think that can be solved in ways outside the script itself, and this
>    problem is also present in the other approach as well.

this problem isn't specific to the unified approach.

> In the event that I am just whistling in the wind here, I also have
> comments on the actual draft... see next rock.

well, I agree with your views, at least.
-- 
Kjetil T.

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 18 Aug 2005 15:09:29 -0400
To: Cyrus Daboo <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

> 3.   Discussion of finer points
>    
>    The "refuse" action MUST refuse to accept an email for delivery at
>    the SMTP/LMTP level by returning a 5XX reply code, instead of
>    sending an MDN as required by the "reject" action, other than for
>    the two exceptions specified below.  A SIEVE implementation that
>    cannot do so MUST NOT claim to support the refuse extension.
   
This means that scripts have to be written with awareness of the site's
email delivery architecture, and if that architecture changes, all
scripts have to change.  I think this is a big burden on both script
writers and site admins.  Even if approach is to have separate "reject"
and "refuse" verbs, I'd like to see some way of avoiding this burden.

>    There is an exception when a message has multiple valid recipients,
>    and at least one but not all of them are refusing delivery (whether
>    the refusal is caused by execution of a Sieve "refuse" or for
>    another reason). In this case, the server MUST accept the message
>    and generate DSNs for all recipients that are refusing it.

I get what this is saying, but I don't think this is said exactly right.
An SMTP server can issue 4xx deferal codes for some of the valid
recipients.  This can be done for various reasons, e.g. if some of the
valid recipients are over quota, or if the SMTP server is using a trick
to allow it to do post-DATA rejection by only focusing on one recipient
at a time (I don't know if anybody actually does this, but I've heard it
proposed..).  So it's really "when more than one RCPT TO has been
accepted" instead of "when a message has multiple valid recipients."
(picky, I know.)

> 4.2  "reject" compatibility with other actions

>    Implementations MUST prohibit more than one reject in a SIEVE
>    script.

must prohibit "the execution of..."  (certainly more than one reject can
appear in a script).

> 5.1  Action refuse

>    The "refuse" action refuses delivery of a message by sending back
>    the 550 SMTP response code to an SMTP client.
> 
>    This extension can be only supported by a Sieve implementation
>    running in an MTA.
   
The way this is worded, an implementation that communicates with an MTA
via LMTP (or any other protocol or mechanism, for that matter) is
prohibited from using "refuse."  There are multiple ways that an MDA may
be invoked by an MTA during the SMTP dialog, where refusal can be
communicated back to the SMTP client.  The MTA itself isn't necessarily
(and probably isn't likely to be) running the Sieve script itself.

And actually I am not sure that LMTP needs to be mentioned in the
document at all, other than as an example of one of the ways that an MTA
and an MDA might communicate during the SMTP dialog.  The important thing
is that the Sieve script is being run at SMTP time and its results are
somehow used by the MTA to respond to the SMTP client.

    This extension can only be supported by a Sieve implementation
    that is invoked on behalf of the MTA during SMTP time, and that
    can communicate its results to the MTA which can then return a
    status to the SMTP client.

Another somewhat thorny point is that a Sieve script may be invoked at
the time when the SMTP server sees the "RCPT TO" so that the refusal may
be communicated to the SMTP client at that time (before DATA).  At this
stage, various Sieve facilities (e.g. header tests, fileinto, keep) are
not available.  I don't know whether this has to be mentioned in this
draft, but once you have "refuse" capability, this does come into play.

>       Example:
>       require ["refuse", "spamtest"]

the missing comparator was already mentioned, but it also needs
"fileinto" for the elsif to work.

> 
>       if spamtest :value "ge" :comparator "i;ascii-numeric" "6" {
>                    refuse text:
>    SpamAssassin thinks the message is spam.
>    It is therefore being refused.
>    Please call 1-900-PAY-US if you want to reach us.
>    .
>                             ;

add "}" here.

>       elsif spamtest :value "ge" :comparator "i;ascii-numeric" "4" {
>                    fileinto "Suspect";
>                   }

Yours,
-mm-

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 18 Aug 2005 15:06:36 -0400
To: Cyrus Daboo <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

I guess I am going to open this can of worms..

When the "refuse" extension was last discussed at length on this list,
it ended with talk about the interaction between reject and refuse,
whether the script writer really ought to care about the actual refusal
mechanism, and how to fall over between the two verbs (or even whether
two verbs was a good idea).  I thought that the concensus was that some
sort of unified action (where the user didn't really have to know
whether a notice was given at SMTP time or post-SMTP time) would be
best.  I may be looking back at that dialog with blinders on, but quotes
in the archive are pretty direct.

Anyway: my preference would be for a "reject" action by which the script
writer specifies that the message is not wanted, without having to know
which of two verbs to use.  This action would cause a reject/refusal at
the earliest possible point; it would have a default fallback behavior
that would happen if that point was not SMTP-time, and this behavior
could be overriden via some extended syntax (either a tagged option or a
code block).

The benefits of a unified approach:

 - existing scripts using "reject" would inherit SMTP-time refusal as
   soon as it was made available in the environment;

 - scripts would continue to work if the site's mail system
   architecture changes;

 - most users would not have to know or care that there were two kinds
   of refusal/rejection; they would know that their script would do
   the best thing supported by the implementation;

 - the whole thing about "this might not work if multiple recipients
   are given" wouldn't be important to the script writer.

Basically:

   reject [:discard/:keep/:notify] "reason";

where with no tagged argument, 5xx at SMTP time is done if possible, and
if not possible, a site-imposed default action would be taken (which
might be either "discard" or "keep" or "send a notification").  The
tagged argument, if given, would override the site-imposed default.
There would also be a section in the RFC directing implementors to
attempt to detect and inhibit notifications to probable forged
addresses.  One could get more elaborate, naturally, e.g. by being able
to specify the extended SMTP result code (as discussed on the list) or
by having a fallback option be "fileinto" .

Drawbacks of a unified approach that I can think of:

 - Any new syntax would have to be enabled via a new capability.  Here,
   I would say that ' require "refuse"; ' would enable the new syntax,
   but the new behavior (i.e., of attempting to turn away the message at
   SMTP time, with site-specific fallback action) would not require the
   new capability.  The new behavior would simply be specified in this
   draft.

 - If a Sieve script is invoked when "RCPT TO" is seen, various other
   Sieve facilities are not available (header tests, fileinto, etc).
   There may be a need for the script writer to be aware of this.  But I
   think that can be solved in ways outside the script itself, and this
   problem is also present in the other approach as well.

In the event that I am just whistling in the wind here, I also have
comments on the actual draft... see next rock.

mm

Date: Thu, 18 Aug 2005 19:01:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

Michael Haardt wrote:

>>>Section 5.1:
>>>
>>>  If the "reason" string is multiline, than the reason text MUST be
>>>  returned as a multiline SMTP/LMTP response, per [SMTP], section
>>>  4.2.1.
>>>
>>>What should happen for plain old SMTP sessions?
>>>      
>>>
>>I am not sure I understand the question.
>>    
>>
>
>I just read again and although there are clients using HELO and not
>understanding multiline responses, RFC 821 already allowed multiline
>responses under all circumstances.  So forget what I said.
>
>Section 5.1 covers not allowed characters, but should add that it is
>an error if messages generated from the response messages would
>have lines exceeding 512 bytes in length.
>  
>
I've added:

 Any line MUST NOT exceed SMTP limit on the maximal line length. The 
server MAY insert CRLFs to make the reason string conform to any such 
limits.

Does this address your issue?

Alexey

To: [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
From: Michael Haardt <[email-masked]>
Date: Thu, 18 Aug 2005 16:11:05 +0200
Sender: [email-masked]

> >Section 5.1:
> >
> >   If the "reason" string is multiline, than the reason text MUST be
> >   returned as a multiline SMTP/LMTP response, per [SMTP], section
> >   4.2.1.
> >
> >What should happen for plain old SMTP sessions?
> >  
> >
> I am not sure I understand the question.

I just read again and although there are clients using HELO and not
understanding multiline responses, RFC 821 already allowed multiline
responses under all circumstances.  So forget what I said.

Section 5.1 covers not allowed characters, but should add that it is
an error if messages generated from the response messages would
have lines exceeding 512 bytes in length.

Michael

Date: Thu, 18 Aug 2005 14:51:18 +0100
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

Michael Haardt wrote:

>Section 4.1:
>
>  Syntax:   reject <reason: string>
>  
>
>  ^^^^^^ Usage
>  
>
Done, thanks.

>The example uses a string that spans multiple lines.  I don't know if
>that is intentional, as the output would be different.  How about using
>text:?
>
Good point, fixed.

>Section 5.1:
>
>   If the "reason" string is multiline, than the reason text MUST be
>   returned as a multiline SMTP/LMTP response, per [SMTP], section
>   4.2.1.
>
>What should happen for plain old SMTP sessions?
>  
>
I am not sure I understand the question.

>      require ["refuse", "spamtest"]
>
>I miss "comparator-i;ascii-numeric".
>  
>
Fixed, thanks.

>Section 5.2:
>
>   If a script attempts to "refuse" the same message more than once,
>   the implementation may ignore the later attempts or consider it 
>   an error."
>            ^ extra double quotes
>  
>
Yes, already fixed in our current version.

>Section 5.3:
>
>   implementation, the example in section 4.1 would show up in SMTP
>                                          ^^^ section 5.1 instead?
>
>But that are just minor points; all in all the draft is fine with me.
>  
>

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Sieve Extension: Variables' to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Thu, 18 Aug 2005 09:45:04 -0400
Sender: [email-masked]

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

- 'Sieve Extension: Variables '
   <draft-ietf-sieve-variables-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-09-01.

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

From: "Scott Hollenbeck" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>
Cc: [email-masked]
Subject: RE: AD evaluation comments: draft-ietf-sieve-variables
Date: Thu, 18 Aug 2005 09:44:48 -0400
Sender: [email-masked]

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]] 
> Sent: Thursday, August 18, 2005 9:41 AM
> To: Scott Hollenbeck
> Cc: [email-masked]
> Subject: Re: AD evaluation comments: draft-ietf-sieve-variables
> 
> Scott Hollenbeck wrote:
> 
> >Just a small nit and a question:
> >
> >The Abstract should be more clear about the focus of the 
> document.  It
> >describes "This extension", but it doesn't explain what's 
> being extended.
> >  
> >
> The Abstract currently says:
>    In advanced filtering rule sets, it is useful to keep state or
>    configuration details across rules.  This extension changes the
>    interpretation of strings, adds an action to store data in 
> variables,
>    and supplies a new test so that the value of a string can be
>    examined.
> 
> How about the following:
>    In advanced filtering rule sets, it is useful to keep state or
>    configuration details across rules.  This document describes a
>    SIEVE (RFC XXXX) extension that changes the
>    interpretation of  strings, adds an action to store data 
> in variables,
>    and supplies a new test so that the value of a string can be
>    examined.

Looks good to me.

> >RFC 2234 has been obsoleted.  Can the reference to 2234 be 
> updated to refer
> >to 2234bis instead?
> >  
> >
> Absolutely. But I personally would prefer if the document is 
> not delayed 
> on this reference. In practice, this might not be an issue, 
> as there is 
> at least one normative reference (base Sieve document) that 
> would have 
> to be satisfied first.

2234bis is already in the RFC Editor queue.  This doc will be way behind it,
and I can expedite processing of 2234bis if need be.

-Scott-

Date: Thu, 18 Aug 2005 14:40:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
CC: [email-masked]
Subject: Re: AD evaluation comments: draft-ietf-sieve-variables
Sender: [email-masked]

Scott Hollenbeck wrote:

>Just a small nit and a question:
>
>The Abstract should be more clear about the focus of the document.  It
>describes "This extension", but it doesn't explain what's being extended.
>  
>
The Abstract currently says:
   In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

How about the following:
   In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This document describes a
   SIEVE (RFC XXXX) extension that changes the
   interpretation of  strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.
?

>RFC 2234 has been obsoleted.  Can the reference to 2234 be updated to refer
>to 2234bis instead?
>  
>
Absolutely. But I personally would prefer if the document is not delayed 
on this reference. In practice, this might not be an issue, as there is 
at least one normative reference (base Sieve document) that would have 
to be satisfied first.

>These are minor.  Please hold off on making any changes until IETF last call
>comments can be addressed.
>  
>

Date: Thu, 18 Aug 2005 15:19:21 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

Section 4.1:

  Syntax:   reject <reason: string>
  ^^^^^^ Usage

The example uses a string that spans multiple lines.  I don't know if
that is intentional, as the output would be different.  How about using
text:?

Section 5.1:

   If the "reason" string is multiline, than the reason text MUST be
   returned as a multiline SMTP/LMTP response, per [SMTP], section
   4.2.1.

What should happen for plain old SMTP sessions?

      require ["refuse", "spamtest"]

I miss "comparator-i;ascii-numeric".

Section 5.2:

   If a script attempts to "refuse" the same message more than once,
   the implementation may ignore the later attempts or consider it 
   an error."
            ^ extra double quotes

Section 5.3:

   implementation, the example in section 4.1 would show up in SMTP
                                          ^^^ section 5.1 instead?

But that are just minor points; all in all the draft is fine with me.

Michael

From: "Scott Hollenbeck" <[email-masked]>
To: [email-masked]
Subject: AD evaluation comments: draft-ietf-sieve-variables
Date: Thu, 18 Aug 2005 09:18:36 -0400
Sender: [email-masked]

Just a small nit and a question:

The Abstract should be more clear about the focus of the document.  It
describes "This extension", but it doesn't explain what's being extended.

RFC 2234 has been obsoleted.  Can the reference to 2234 be updated to refer
to 2234bis instead?

These are minor.  Please hold off on making any changes until IETF last call
comments can be addressed.

-Scott-

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-variables-06.txt 
Date: Wed, 17 Aug 2005 15:50:01 -0400
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 Extension: Variables
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-06.txt
	Pages		: 15
	Date		: 2005-8-17
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

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

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

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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-sieve-variables-06.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 16 Aug 2005 17:31:11 -0400
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Working Group Last Call for draft-ietf-sieve-refuse-reject-00.txt
Sender: [email-masked]

Hi folks,
I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-refuse-reject-00.txt>

A two week working group last call of this document starts today on August 
16th 2005 and ends on Tuesday, August 30th 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, please 
send both co-chairs (or the list) an email to indicate you have looked at 
it. This will allow the chairs to gauge the scope of reviews of this 
document to aid in our determination on whether to send it to the IESG. 
Thanks.

--
Cyrus Daboo
SIEVE WG Co-chair

Date: Tue, 16 Aug 2005 17:31:34 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Re: Notes for the meeting in Paris
Sender: [email-masked]

Alexey Melnikov wrote:

> Hi everyone,
> I've produced Paris meeting notes from the Jabber logs. Can people 
> please verify them for correctness/completeness.
>
> Thanks!
> Alexey
>
As I haven't received any comments, I will submit the produced notes. 
The only two additions I've made are:

added to the list of actions:

 Kjetil to fix editorial issues in the Variables draft.
 Ken to submit a new revision of Regex to incorporate Sieve :quoteregex 
text.

Date: Mon, 15 Aug 2005 11:38:52 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Working Group Last Call: draft-ietf-sieve-spamtestbis-01.txt
Sender: [email-masked]

I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-spamtestbis-01.txt>

A two week working group last call of this document starts today on 
August 15th 2005 and ends on Monday, August 29th 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, 
please send both co-chairs (or the list) an email to indicate you have 
looked at it. This will allow the chairs to gauge the scope of reviews 
of this document to aid in our determination on whether to send it to 
the IESG. Thanks.

--
Alexey Melnikov
SIEVE WG Co-chair

Date: Sat, 13 Aug 2005 20:02:07 +0100
From: Alexey Melnikov <[email-masked]>
To: Matthew Elvey <[email-masked]>
CC: [email-masked]
Subject: Re: comments on refuse
Sender: [email-masked]

Matthew Elvey wrote:

>>> or if the sieve implementation
>>> is behind any MTAs that don't synchronously pass-through messages.  
>>
> A careful reading of the draft will show that such implementations 
> cannot support the refuse extension.

Uh, no. This is not what the current text says and I don't think we 
should prohibit deployment of refuse for such configurations.

> Please reread the draft and let me know if this is not clear. (Section 
> 3, first paragraph)

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-variables-05.txt 
Date: Fri, 12 Aug 2005 15:50:02 -0400
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 Extension: Variables
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-05.txt
	Pages		: 15
	Date		: 2005-8-12
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

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

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

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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-sieve-editheader-02.txt 
Date: Fri, 12 Aug 2005 15:50:02 -0400
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: Editheader Extension
	Author(s)	: P. Guenther, J. Degener
	Filename	: draft-ietf-sieve-editheader-02.txt
	Pages		: 9
	Date		: 2005-8-12
	
This document defines two new actions for the "Sieve" email
   filtering language that add and delete email header fields.

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

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

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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 10 Aug 2005 19:25:00 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Notes for the meeting in Paris
Sender: [email-masked]

Hi everyone,
I've produced Paris meeting notes from the Jabber logs. Can people 
please verify them for correctness/completeness.

Thanks!
Alexey

===========
Thanks to Pete Resnick and Tony Finch for taking Jabber notes.

The WG had an 1:30 minutes long meeting on Tuesday, August 2nd. Several 
WG members have participated
through Jabber (Cyrus, Ned, Matthew, Ken)

WGLC for the base spec has ended. There were some minor editorial 
comments on the mailing list, in particular
suggestion to change "Syntax:" to "Usage:" everywhere in the document. 
Philip has also pointed out that he has
to change "header" to "header field" to use terminology consistent with 
RFC 2822.

Vacation draft is ready for WGLC. Jeffrey Hutzelman have done a security 
review and didn't find any issues.

Kjetil has talked about updated Variables draft. Recent changes include:
  allow sub-namespaces to be all-numeric (e.g. ${foo.1.2})
  allow to SET variables in namespaces that allow for modifications
  ${0} is now referencing the entire match, not the number of matching 
groups
  new modifiers :quotewildcard and :quoteregex.
One remaining issue is whether regex related text (i.e. :quoteregex) 
should be moved to the Regex draft.
Alexey was trying to convince everybody that dependency on a 
document-which-might-take-arbitrary-long-time
is a bad thing, in particular because Regex hasn't addressed I18N issues 
yet.
General consensus from people in the room to move :quoteregex to Regex 
draft, Ned agrees in Jabber.

Q: Security review of Variables has pointed out issue with silent 
truncation of variables.
A: There is a new text in Security Considerations section. Sorry, this 
should have been listed in the
"recent changes".
Philip has repeated the argument that Ned has maid on the mailing list: 
if there is a language facility
to test if a truncation has occurred, nobody will use it anyway. Jeffrey 
has replied that he is Ok with
not having a test for truncation, as long as the document discusses the 
issue. The room agrees.

Philip then talked about body draft. A new revision was published as a 
result of WGLC. Recent changes include:
 Charset wording aligned with base spec
 Clarified the implicit content-type rules.
New issue: what does it mean to match against non-textual content? 
Matching is defined for Unicode characters,
so what would it mean to convert a sound or image to Unicode?
Alexey has pointed out that IMAP SEARCH only required to work on text/* 
parts, suggested to do the same.
Philip has mentioned that we could assume that bytes are in iso-8859-1. 
Many people in the room disagree.
David Cridland has suggested that comparators could control which mime 
types could be searched with them.
William Leibzon has pointed out that it would be desirable to be able to 
search a MIME prolog and epilogue,
several people seemed to agree.
Pete Resnick has asked Ned about default charset for prolog/epilog. Ned 
has replied that it is US-ASCII,
as defined in RFC 2822.
Cyrus (in Jabber) has suggested to use a separate MIME extension(s) to 
work with MIME bodyparts properly.
Alexey has suggested that maybe we should drop :content, this will 
certainly make the document simpler.
Cyrus has suggested to leave :content as a simple/quick short time solution.
Philip has asked the attendees if anybody but Sendmail have implemented 
Body. David said that Exim might.

Philip then talked about Edit header. Philip thought that it should be 
ready for IETF wide LC, chairs agreed.
Scott Hollenbeck reinforced that "writeup" meant that chairs were going 
to shepherd the document as per new
IESG rules. Chaired confirmed that they were aware of that.

Alexey has talked about Spamtest document, using the slide sent by 
Cyrus. Recent changes included: removing
"-1" from :percent test and a new text explaining how to test that Spam 
check wasn't performed on the message.
New capability "spamtestplus" was added as the result. The document 
should be ready for WGLC.

Alexey has talked about IMAPflags document. The latest revision got 
published in spring. It added back internal
variable (so that the extension can be used without "Variables", e.g. in 
Cyrus Sieve), syntax is backward compatible
with the old IMAPFlags (revision -03) as implemented by CMU. Cyrus has 
confirmed that the document should be ready
for WGLC, Ned agreed.

Alexey has talked about Refuse/Reject draft. He thinks that the document 
is ready for WGLC. Matthew (in jabber)
has reminded him that there is one open issue: what should happen if 
"refuse" is called more than once for a message.
This needs to be discussed on the mailing list (can be done during WGLC).
Philip has said that he didn't like the text on joe jobs in the 
Introduction/Abstract sections. Alexey has asked
for specific suggestions, which Philip has promised to provide on the 
mailing list. Cyrus should issue a WGLC
for the document.

Chris has presented Ned's Date extension. It adds date test. Can search 
for a date at the end of any header,
so this works with Date, Received and even X400-recieved. Ned has added 
a comment in Jabber saying that
the date stuff was structured the way it was to avoid requiring 
variables for everything.
It is possible to test year, month, day, julian (day number on julian 
calendar), hour, minute, second, iso8601,
or timezone. There is also a test for the current date/time. Ned has 
asked the WG if any test is missing or
should be removed. Cyrus suggested to add "day-of-week". Somebody else 
has suggested "day-of-year".
Also seconds should be allowed to have value 60.
Tony Finch has suggested to use modified Julian day, which starts 
counting from the mid-19thc (1863 i think)
and days start at midnight, not midday as in the Julian day. Ned agreed 
with the change.
Cyrus has brought the question about :zone and daylight savings.
Ned/Pete said that zones in the document are numeric, so this shouldn't 
be an issue.
Ned also pointed out that if timezone is not explicitly specified, than 
a local timezone is assumed and
things should work as expected.
Alexey mentioned that the document is not in WG Charter, but it is Ok to 
discuss it on the mailing list.
Ned replied that he didn't really care.

Tony Hansen has presented Sieve loops (MIME parts tests). 
"for.every.part" construct allows to iterate
through the MIME body parts, there is a new "break" construct as well.
Inside the iterator loop the current message is the body part.
Alexey has asked if one can use "fileinto" on a body part. It is not 
currently clear, many other
Sieve extensions can also be meaningless.
The document also defines a new MIME test, which allows to examine MIME 
headers/parameters for the
current part. If the test is used outside of a loop, the test return 
true if any MIME part has a particular
header/parameter.
Two other extensions are also described in the draft: body part 
replacement action (it allows to replace a body
part with a text/plain string) and enclose action (encapsulate the 
entire message in a message/rfc822)
Alexey suggested that replace and enclose can be combined.

Q: Is this worth doing?
Alexey: Seems complex, but worth doing. This is in our Charter.

Suggestion to make this Experimental. Alexey replied that we don't need 
to decide on Experimental versa
Standard Track until we get to WGLC. We might get some implementations 
before the WGLC.
Ned commented in Jabber that this might be very difficult to implement 
for Sun. Jeffrey has asked
Ned if making iterator separate from MIME test would help. Ned said that 
it would.

Alexey recaps issues raised during WGLC for Subaddress. There were some 
minor editorial issues,
also the document is not quite clear that both prefix and suffix forms 
are allowed, also that
multiple characters can be used as a delimiter. Ken needs to submit a 
new revision before this
can be sent off to IESG.

Review of other drafts has followed. WG needs an editor for SMTP AUTH 
test (this can't be a part
of the base document, as we don't want to have a normative reference to 
SMTP AUTH document).
Ned agreed to take this one.

Alexey has asked the WG about the state of Notify draft. Barry will 
start a thread about it,
so that the WG can figure out which notification mechanisms should be 
present and which can be dropped.

Barry has asked about the state of Relational draft. Alexey thinks that 
it is ready for WGLC.

Action items:
 Philip to publish a new revision of base spec to address editorial 
comments raised during WGLC.
 Jeffrey should post a short message about security review of the 
Vacation document.
 Ned to post an update to vacation, if he has any changes pending.
 Ned to repost his old message about addressing I18N in Regex.
 Philip to post a new revision of Body to address searching of 
non-textual bodyparts.
 Alexey/Cyrus to send Edit header to IESG (do writeup, etc.)
 Alexey to issue WGLC for Spamtest.
 Cyrus to issue WGLC for IMAPFlags.
 Cyrus to issue WGLC for Refuse/Reject.
 Alexey/Cyrus to issue WGLC for Relational.
 Ken to address comments raised during WGLC for Subaddress draft.
 Tony/Cyrus to publish combined MIME test draft.
 Ned to create a new draft for testing SMTP AUTH.
 Barry to revive the Notify draft.
 Alexey/Cyrus to propose updated WG milestones on the mailing list.

Date: Wed, 10 Aug 2005 10:38:59 -0400
From: Cyrus Daboo <[email-masked]>
To: Sieve Mailing List <[email-masked]>
Subject: Revised Milestones
Sender: [email-masked]

Hi folks,
In conjunction with Alexey I have put together a revised list of milestones 
for the working group. Please take a look at this and let us know if you 
think these are reasonable, or whether you would prefer a longer time for 
certain items (in particular document authors please note proposed 
submission of your documents and let us know if you can realistically meet 
the deadline). The proposed milestones have us doing a lot of work in 
September through November, with many WG last calls and submissions to IESG.

SIEVE WG Milestones and Goals

Done Submit revised variables draft.
Done Submit revised vacation draft.
Done WG last call for variables draft.
Done Initial submission of RFC 3028bis.
Done Initial submission of revised relational draft.
Done Initial submission of revised subaddress draft.
Done Initial submission of revised spamtest/virustest draft.
Done Submit revised editheader draft.
Done Submit revised imapflags draft.
Done WG last call of revised subaddress draft.
Done Submit revised body test draft.
Done WG last call for editheader draft.
Done Submit revised reject before delivery draft.
Done WG last call for body test draft.
Done WG last call for RFC 3028bis.
Aug 05 Submit variables draft to IESG.
Aug 05 Submit editheader draft to IESG.
Aug 05 WG last call for imap-flags draft.
Aug 05 WG last call of revised spamtest draft.
Sep 05 Submit 3028bis to IESG.
Sep 05 Submit imapflags draft to IESG.
Sep 05 Submit revised spamtest draft to IESG.
Sep 05 WG last call for vacation draft.
Sep 05 WG last call of revised relational draft.
Sep 05 WG last call for refuse draft.
Sep 05 Submit revised notification action draft.
Sep 05 Submit revised MIME part tests draft.
Oct 05 Submit vacation draft to IESG.
Oct 05 Submit revised relational draft to IESG.
Oct 05 Submit refuse draft to IESG.
Oct 05 WG last call of revised subaddress draft.
Nov 05 Submit body test draft to IESG.
Nov 05 Submit revised subaddress draft to IESG.
Nov 05 3028bis interop report.
Nov 05 WG last call for notification action draft.
Nov 05 WG last call for MIME part tests draft.
Jan 06 Submit notification action draft to IESG.
Jan 06 Submit MIME part tests draft to IESG.

-- 
Cyrus Daboo

Content-class: urn:content-classes:message
Subject: RE: Rules Language
Date: Wed, 10 Aug 2005 05:14:00 -0400
From: "Eric Burger" <[email-masked]>
To: "The Purple Streak, Hilarie Orman" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

It would be really, really, really good if we could wrap ourselves
around SIEVE.

The mobile messaging community wants to be able to do OPES like stuff on
content that is streamed out of a server, either by SIP or HTTP.

At the same time, the messaging community is looking at SIEVE as a
potential solution for message-based sorting, i.e. "kill if Spam Score >
90%" or "send me a page if I get mail from my boss."

Being able to use the same language everywhere would be helpful.

Note that SIEVE, while created in the SMTP and IMAP milieu, is
specifically not tied to any transport mechanism.  One of its current
shortcomings, or benefits, depending on your point of view, is the
management of rules is currently undefined (probably will become a work
item somewhere).

I would offer that OPES should get SIEVE to do whatever is necessary to
update it for streaming.

See:
http://www.ietf.org/html.charters/sieve-charter.html

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of The Purple
Streak, Hilarie Orman
Sent: Wednesday, August 10, 2005 12:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: Rules Language

With some trepidation, I offer

http://www.purplestreak.com/ietf-opes/draft-ietf-opes-rules-language-hop
along-00.txt

It is incomplete in several aspects, particularly the detailed grammar,
but I think that it gets at the heart of defining a stream processing
language for OPES.  I had intended to use the Sieve grammar, but
in the time I had for this, I couldn't decide if it is worth the
trouble of using the funky notation.

Comments are, of course, welcome, even more so than no comments.

Hilarie

Date: Sat, 06 Aug 2005 15:11:15 -0700
From: Matthew Elvey <[email-masked]>
To: [email-masked], Alexey Melnikov <[email-masked]>
Subject: Re: comments on refuse
Sender: [email-masked]

I'd like to solve the spam problem (see 
www.rhyolite.com/anti-spam/you-might-be.html ) but we're just proposing 
a small improvement to SIEVE, that will help in a small but significant 
way reduce resource usage, but doesn't require changes that break 
existing Sieve or SMTP implementations.  That implies some serious 
constraints!
'Refuse' only claims to be _less_ likely to result in backscatter to an 
innocent victim.  It is not 'discard', or CSV (the 'best' spam remedy, 
IMO - see 
http://wiki.fastmail.fm/index.php/Certified_Server_Validation), or BATV.

On 8/5/05 11:19 AM, Michael Haardt sent forth electrons to convey:
> On Thu, Aug 04, 2005 at 05:45:04AM -0700, Philip Guenther wrote:
>   
>> draft-ietf-sieve-refuse-reject-00 justifies the 'refuse' extension
>> based on a claimed ability to reduce the amount and/or likelihood
>> of joe-job spam.  By my reading, there is only a reduction in amount
>> by replacing one or more MDNs (one per recipient using 'reject')
>> with one DSN and no reduction in likelihood.
This is not consistent with what you say later; I think you've 
misunderstood the spec.  'Refuse' will replace one notification with 
another in a small fraction (my estimate: 10% of the time(a few % due to 
the exception in section 3, a few % due to 5xx errors to unidentified or 
unblocked relays, etc.) ; certainly << 100%) of the time it acts.  My 
estimate implies a 90% reduction in backscatter for those replacing 
reject with refuse.
>>   While a message that
>> is refused by all recipients can indeed be refused at the SMTP-level
>> at the final dot, a DSN will still be generated unless the message
>> was received directly from the submitting software by the SMTP-based
>> sieve implementation.  
I find that this exception is actually a common case, accounting for >> 
17% of mail delivery attempts.  And in this case, neither an MDN nor a 
DSN is generated. (The research paper at 
http://www.ceas.cc/papers-2005/120.pdf confirms that some 17% of mail 
delivery attempts these days are made from SMTP malware that can't even 
retry, and hence almost certainly can't create DSNs either)
>> That doesn't apply when open relays ("open
>> proxies" in the draft) are involved 
Let me know if I need to explain the difference between open relay and 
open proxy and how each is used by spammers to send spam.

I believe that most mail servers on the Internet do not accept mail from 
identifiable open relays and open proxies at all, and for them 'refuse' 
has no impact on backscatter.

Supporting argument: Most such systems are on blacklists such as 
[http|socks|smtp|web].dnsbl.sorbs.net (see 
http://www.us.sorbs.net/using.shtml for definitions; MAPS and others 
have similar lists among their offerings). In particular they are on the 
blacklists that a consensus of reports state have the lowest risk of 
being used to block non-spam (that is, even lower risk than the SBL 
blacklist, which protects half a billion mailboxes) and hence are the 
most widely used.  When such blacklists are used, mail is often blocked 
before sieve even sees the message. Blocking could occur at EHLO or 
earlier, such as at a border firewall.
>> or if the sieve implementation
>> is behind any MTAs that don't synchronously pass-through messages.
>>     
A careful reading of the draft will show that such implementations 
cannot support the refuse extension.  Please reread the draft and let me 
know if this is not clear. (Section 3, first paragraph)
>
> You are correct, but as a matter of fact, I do receive quite a bunch
> of spam right from the sending host (spam companies or compromised (?)
> dial-up systems) to a single recipient.  I have no numbers, though.
>
> IMHO, messages should be refused at the earliest possible point.  I do not
> like that refuse is not defined that way, leaving open where that point
> is for a specific system.  
OK, I agree with you here.  Now we just have to come up with wording to 
make this clearer in the draft. 
Also, I have noticed that most drafts addressing spam have weak language 
such as:

"The handling of such messages is at the discretion of the verifier or 
final recipient."
              -DKIM draft ( 
http://ietf.org/internet-drafts/draft-allman-dkim-ssp-00.txt )
or
"... system MAY choose to reject or discard email on the
   basis of local policy...  The
   actual policy decisions are outside the scope of this document."
              - http://spf.pobox.com/spf-draft-200406.txt (SenderID has 
very similar language.)
Then again, CSV has somewhat stronger language:
"...caution is required. The receiving SMTP server might:
    - Generate an SMTP session error, as suggested below.
    - Mark the message, to indicate that it failed validation.
    - Place the message into a special queue, for separate handling."
               CSV CSA draft ( 
http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.html#anchor4 )

Would you be satisfied if I added this at the beginning of section 3?:
"Messages should be refused at the earliest possible point."

[Alexey: I am going to steal back the virtual edit baton, OK?  Or have 
you already started making edits?  IIRC you are holding it.]
> I would prefer an action like "refuse at the
> earliest point, and if that means bouncing, then bounce it".
How exactly does what you prefer differ from the action as I defined it 
in the current spec?   The current spec indicates (several times!) that 
bouncing is a last resort and lists several negative side effects.
>   As it is,
> we have reject, which always bounces, and refuse, which always refuses.
> I have to remember which system offers what for avoiding bounces where
> possible.
>   
Backwards compatibility is a #1$@%.  I expected there would be multiple 
objections if I tried redefining reject, which is the only reason I 
haven't tried.
>   
>>  - shouldn't "open proxies" be "open relays"?  This is a reference
>>    to MTAs that relay without limits, right?
>>     
>
> Open proxies may be correct.  For one, there is a bunch SOCKS proxies.
> For another, there are many MTAs that do not count syntax errors
> or enforce SMTP synchronisation points, thus being vulnerable to HTTP
> proxies being used to CONNECT to port 25.  Sending spam through open
> relays has become a little old-fashioned.
>   
"Open proxies" is correct.  With "open relays", the sentence doesn't 
make sense.
> Michael

P.S.:  Alexey: 3042bisv4 gets a belated nod from me.

Date: Fri, 5 Aug 2005 20:19:35 +0200
From: Michael Haardt <[email-masked]>
To: [email-masked]
Subject: Re: comments on refuse
Sender: [email-masked]

On Thu, Aug 04, 2005 at 05:45:04AM -0700, Philip Guenther wrote:
> draft-ietf-sieve-refuse-reject-00 justifies the 'refuse' extension
> based on a claimed ability to reduce the amount and/or likelihood
> of joe-job spam.  By my reading, there is only a reduction in amount
> by replacing one or more MDNs (one per recipient using 'reject')
> with one DSN and no reduction in likelihood.  While a message that
> is refused by all recipients can indeed be refused at the SMTP-level
> at the final dot, a DSN will still be generated unless the message
> was received directly from the submitting software by the SMTP-based
> sieve implementation.  That doesn't apply when open relays ("open
> proxies" in the draft) are involved or if the sieve implementation
> is behind any MTAs that don't synchronously pass-through messages.

You are correct, but as a matter of fact, I do receive quite a bunch
of spam right from the sending host (spam companies or compromised (?)
dial-up systems) to a single recipient.  I have no numbers, though.

IMHO, messages should be refused at the earliest possible point.  I do not
like that refuse is not defined that way, leaving open where that point
is for a specific system.  I would prefer an action like "refuse at the
earliest point, and if that means bouncing, then bounce it".  As it is,
we have reject, which always bounces, and refuse, which always refuses.
I have to remember which system offers what for avoiding bounces where
possible.

>  - shouldn't "open proxies" be "open relays"?  This is a reference
>    to MTAs that relay without limits, right?

Open proxies may be correct.  For one, there is a bunch SOCKS proxies.
For another, there are many MTAs that do not count syntax errors
or enforce SMTP synchronisation points, thus being vulnerable to HTTP
proxies being used to CONNECT to port 25.  Sending spam through open
relays has become a little old-fashioned.

Michael

To: MTA filtering mailing list <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: comments on refuse
Date: Thu, 04 Aug 2005 05:45:04 -0700
Sender: [email-masked]

draft-ietf-sieve-refuse-reject-00 justifies the 'refuse' extension
based on a claimed ability to reduce the amount and/or likelihood
of joe-job spam.  By my reading, there is only a reduction in amount
by replacing one or more MDNs (one per recipient using 'reject')
with one DSN and no reduction in likelihood.  While a message that
is refused by all recipients can indeed be refused at the SMTP-level
at the final dot, a DSN will still be generated unless the message
was received directly from the submitting software by the SMTP-based
sieve implementation.  That doesn't apply when open relays ("open
proxies" in the draft) are involved or if the sieve implementation
is behind any MTAs that don't synchronously pass-through messages.

I therefore suggest that the introduction and abstract limit
themselves to claims that can then be justified in the body of the
draft.

Editorial:
 - shouldn't "open proxies" be "open relays"?  This is a reference
   to MTAs that relay without limits, right?
 - there are many sentences that contain too many commas.  Most
   simply need one or more commas removed; some should be split
   into two sentences
 - abstracts may not contain references
 - the second paragraph of section 3 should be rephrased to state
   that it applies only to SMTP and not LMTP from the start, ala
	"If the implmentation receives a message via SMTP that
	 has multiple valid recipients and at least...

Philip Guenther

Date: Mon, 01 Aug 2005 16:17:29 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: Re: Working Group Last Call: draft-ietf-sieve-3028bis-04.txt  (Sieve base)
Sender: [email-masked]

Alexey Melnikov wrote:

> I would like to draw your attention to the following draft:
>
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-3028bis-04.txt>
>
> A two week working group last call of this document starts today, 19th 
> July 2005 and ends on 2nd August 2005 at 6 pm EST.

I would like to remind people that the WGLC is ending tomorrow.

I need more positive acknowledgments that people have read the draft and 
found no problems. Thanks!

> Please review this document and send issues to the list or direct to 
> the author(s).
>
> NB If you do review this document, but have no issues or comments, 
> please send both co-chairs (or the list) an email to indicate you have 
> looked at it. This will allow the chairs to gauge the scope of reviews 
> of this document to aid in our determination on whether to send it to 
> the IESG. Thanks.
>
> -- 
> Alexey Melnikov
> SIEVE WG Co-chair

-- 
Alexey Melnikov
__________________________________________
Isode M-Box Message Store developer
http://www.isode.com/products/m-box.html

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

Date: Mon, 01 Aug 2005 11:29:08 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: Sieve WG meeting
Sender: [email-masked]

I would like to ask all editor's/resenters to send me slides/notes on 
what they are planning to present during Tuesday Sieve WG session.

Thanks!
Alexey

Date: Mon, 01 Aug 2005 10:22:34 +0100
From: Alexey Melnikov <[email-masked]>
To: Matthew Elvey <[email-masked]>
CC: [email-masked]
Subject: Sieve WG meeting
Sender: [email-masked]

Matthew Elvey wrote:

>> ...
>>
>> Total: 120 minutes.
>
>
> http://ns.ietf.org/ietf/05aug/sieve.txt:
>
> Tuesday, August 2 at 1815-1945 equals:
>
> http://timeanddate.com/worldclock/fixedtime.html?month=8&day=2&year=2005&hour=18&min=15&sec=0&p1=195 
>
>
> Where will the online chat be?  I plan to login...

"sieve" jabber room on "ietf.xmpp.org" server.

> Also, that's only a 90 minute slot, not 120...  we'll be OK?

Oops. Yes, you are correct. We have 2 options - be quick, or stay late 
(we have the last session on Tuesday, so that should be Ok).