Subject: sieve-06bis

From: Tim Showalter <[email-masked]>
Date: 11 Feb 1999 15:11:44 -0500

Hi.  This draft has some of the changes folks have asked for.  Notably
missing are the things Steve posted that I wasn't sure about, noted in
my previous message, and anything related to multiple fileinto.

Tim

-- 
Tim Showalter <[email-masked]>

---

From: Tony Hansen <[email-masked]>
Date: Sat, 13 Feb 1999 14:12:53 -0500

> my previous message, and anything related to multiple fileinto.

A few typos and mostly minor comments.

	Tony Hansen
	[email-masked]

===

   All implementations MUST support the "i;octet" comparator (simply
   compares octets) and the "i;ascii-casemap" comparator (which treats
   uppercase and lowercase English characters in the same).  If left
                                              ^^ as
   unspecified, the default is "i;ascii-casemap".

===

   Actions that do not affect delivery status can be used multiple times
   and in any combination with each other.  In the base draft, this
                                                               ^^^^ these
   actions are "fileinto" and "redirect".

===

As I was reading section 4, I kept wondering what the "require" string
was supposed to be for each of the optional commands. I suggest adding
that information to each section of an action that is optional.

   Because some implementations cannot implement the reject command, it
   is optional.
               ^^ The string to be used for the require command is "reject".

===

   The "fileinto" action drops the message into a named folder.
   Implementations SHOULD support fileinto, but in some environments
   this may be impossible.
                          ^^ The string to be used for the require command
                             is "fileinto".

===

   The require action notes that a script makes use of an certain
   extension.  Such a declaration is required to use the extension, as
   discussed in section 2.10.2.  Multiple capabilities can be declared
                        ^^^^^^ 2.10.5
   with a single require.

===

   Example:  require ["fileinto", "envelope"];
                                   ^^^^^^^^ "reject".

What is "envelope" supposed to represent? The envelope test is not
optional, or if it is, it's not marked as such.

===

5.4.     Test envelope

This section is written strictly in terms of SMTP. Other transfer protocols
do exist and should not be dismissed.

===

   The "envelope" test is true if the specified part of the RFC-822
                                                            ^^^^^^^ SMTP (or equivalent)
   envelope matches the specified key.

If an RFC were to be mentioned, it should be 821, not 822. Besides, the
SMTP protocol RFC821 is being rewritten, so refering to a particular RFC
is not recommended.

===

   If one of the envelope-part strings is (case insensitive) "from",
   then matching occurs against the FROM address used in the SMTP MAIL
   command.
          ^^, or equivalent

   If one of the envelope-part strings is (case insensitive) "to", then
   matching occurs against the TO address used in the SMTP RCPT command
                                                                       ^^, or equivalent,
   that resulted in this message getting delivered to this user.  Note
   that only the most recent TO is avaliable.

===

The Test address and Test envelope sections need examples:

   Example:     if address :all "from" :is "[email-masked]" {
                      discard;
                }

   Example:     if envelope :all "from" :is "[email-masked]" {
                      discard;
                }

===

7.      Transmission

   The MIME type for a Sieve script is "application/sieve".

This needs the complete registration section from the MIME documents (RFC 2048). Suggested text follows:

     Subject: Registration of MIME media type applicaton/sieve

     MIME media type name: application
     MIME subtype name: sieve
     Required parameters: none
     Optional parameters: none
     Encoding considerations: Most sieve scripts will be textual, written in UTF-8.
        When non-7bit characters are used, quoted-printable would be appropriate for transport
        systems that require 7bit encoding.
     Security considerations: Discussed in section 10 of RFC XXXX.
     Interoperability considerations: Discussed in section 2.10.5 of RFC XXXX.
     Published specification: RFC XXXX.
     Applications which use this media type: sieve-enabled mail servers
     Additional information:
       Magic number(s):
       File extension(s): .siv
       Macintosh File Type Code(s):
     Person & email address to contact for further information:
	See the discussion list at [email-masked].
     Intended usage:
	COMMON
     Author/Change controller:
	See Author information in RFC XXXX.

---

From: Tim Showalter <[email-masked]>
Date: 15 Feb 1999 16:43:14 -0500

> Date: Sat, 13 Feb 1999 14:12:53 -0500
> From: Tony Hansen <[email-masked]>
> 
> Tim Showalter wrote:
> > 

Thank you.

> optional, or if it is, it's not marked as such.

Does this need to be optional?  I can't remember anymore.

> do exist and should not be dismissed.

I'd rather going to add some generic text at the bottom.  Is that okay?

(I've fixed the RFC-822 reference, of course.)

I've added this text to the bottom of 5.4:
| If a protocol other than SMTP is used for message transport,
| implementations are expected to adapt this command, mapping the "from"
| and "to" envelope parts to the appropriate parts of the envelope.

>    Example:     if envelope :all "from" :is "[email-masked]" {

I've added these, moving the :is argument towards the front of the
command (envelope :all :is "from" "[email-masked]").

> (RFC 2048). Suggested text follows:

I'm doing some markup, but will otherwise take this completely.

I assume we need a Mac filetype.  I can't remember the rules on those;
can someone come up with one?  (SIVE, in whatever case is appropriate,
would be good, I think).

Thanks...

---

From: Michael Salmon <[email-masked]>
Date: Tue, 16 Feb 1999 11:01:03 +0100

+----- On 11 Feb 1999 15:11:44 EST, Tim Showalter writes:
| --Multipart_Thu_Feb_11_15:11:43_1999-1
| Content-Type: text/plain; charset=US-ASCII
| 
| Hi.  This draft has some of the changes folks have asked for.  Notably
| missing are the things Steve posted that I wasn't sure about, noted in
| my previous message, and anything related to multiple fileinto.

Hi
   a couple of minor points.

/Michael

[...]
| 2.7.2.   Comparisons across Character Sets
| 
| All Sieve scripts are represented in UTF-8, but messages may involve
| a number of character sets.  In order for comparisons to work across
| character sets, implementations SHOULD implement the following
| behavior:
| 
| Implementations decode header charsets to UTF-8.  Two strings are
| considered equal if their UTF-8 representations are identical.
| Implementations should decode charsets represented in the forms
| specified by [MIME] for both message headers and bodies.
| Implementations must be capable of decoding US-ASCII, ISO-8859-1,
| the ASCII subset of ISO-8859-* character sets, and UTF-8.

I think that ISO-8859-15 would be more appropriate than -1, it fixes 
the bugs in -1 and adds the euro.

| If implementations fail to support the above behavior, they MUST
| conform to the following:
| 
| No two strings containing 8-bit data can be considered equal.

I agree with what I think that you mean but shouldn't it say something 
more like:

No two strings can be considered equal if either string contains octets 
greater than 127.

[...]
| 2.10.3.  Message Uniqueness in a Mailbox
| 
| Implementations SHOULD NOT write a message to a mailbox where a copy
| of it already exists, even if a script explicitally asks for a
                                         ^^^^^^^^^^^^ explicitly
| message to be written to a mailbox twice.
| 
| The test for equality of two messages is not defined by this memo.

I think that this is a little tough although of course it isn't 
mandatory. Perhaps it should be mandatory for a script to not deliver 
more than once to a mailbox .

[...]
[...]
| 4.7.     Action require
| 
| 
| Syntax:   require <capabilities: string-list>
| 
| The require action notes that a script makes use of an certain
| extension.  Such a declaration is required to use the extension, as
| discussed in section 2.10.2.  Multiple capabilities can be declared
| with a single require.
| 
| 
| Example:  require ["fileinto", "envelope"];

What should happen if a require is not satisfied? I would guess that a 
required extension would be checked when the script was loaded but what 
happens if an extension is removed?

[...]
| 9.1.     Lexical Tokens
| 
| Sieve scripts are encoded in UTF-8.  The following assumes a valid
| UTF-8 encoding; special characters in Sieve scripts are all ASCII.
| 
| The following are tokens in Sieve:
[...]
| multi-line = "text:" *(SP / HTAB) (comment / CRLF)
| *((1*CHAR-NOT-DOT *CHAR CRLF) / ("." 1*CHAR-NOT-DOT *CHAR
| CRLF) /           (".." *CHAR CRLF) / CRLF)         "." CRLF
| ;; note when used,         ;; a leading ".." on a line is
| mapped to ".".

This is slightly different to the definition in 2.4.2 in that it allows 
white space after the :.

[...]
| In order to prevent mail loops, an implementation MUST refuse to
| filter a message that it has already filtered once; that is, a
| message must not pass through a given server twice.

This seems excessive to me, especially as servers are becoming larger 
and larger all the time. I think that mail loops would be prevented if 
a message could only be kept or discarded when it had been seen twice 
by the same user.

---

From: Tim Showalter <[email-masked]>
Date: 16 Feb 1999 17:26:53 -0500

> Date: Tue, 16 Feb 1999 11:01:03 +0100
> From: Michael Salmon <[email-masked]>

> the bugs in -1 and adds the euro.

For better or worse, I believe 8859-1 is more common and should be
required, but I don't have a string opinion on the subject.

Is this not the case?

> No two strings can be considered equal if either string contains octets 

You're right; changed.

> more than once to a mailbox .

I'm not sure what you want.  That language is weasily enough to allow an 
awful lot, quite possibly too much.

The reason for that second paragraph is that I consider two messages
with the same message-id equal enough, but others will want to compare
bodies in some meaningful way.

> happens if an extension is removed?

The script doesn't run at all.  I've added this sentence to 2.10.5:

| If a script does not understand an extension declared with require,
| the script must not be used at all.

> [Re: 9.1 definition of multi-line]

2.4.2 fixed.

> a message could only be kept or discarded when it had been seen twice 

How would one write such a script?

I think that this should be on a per-user basis, not a per-server basis,
and I'll fix it accordingly:

| In order to prevent mail loops, implementations must prevent messages
| from passing through a given user twice.

I think this is what I intended, and I believe it's a clear improvement.

I only want to discuss the case where a user relays a message to himself 
(i.e., a loop).  Two messages with the same message-id can have
different return-path values (say, if one hits a mailing list) and I
don't want to require anything in that case; that's normal and fine and
scripts should handle it accordingly.

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 16 Feb 1999 16:10:58 -0800

> a message could only be kept or discarded when it had been seen twice 

	I don't think this RFC is the place to specify how to stop
	mail loops, except insofar as "an implementation SHOULD be
	smart enough to prevent looping of messages."  A seperate
	"Best Current Practice" draft would be more appropriate,
	and I'd love to work with somebody on that.

-- 
J.D. Falk <[email-masked]>                     Got clue?  http://www.ispf.com/
Special Agent In Charge (Abuse Issues)
Critical Path, Inc.

---

From: Michael Salmon <[email-masked]>
Date: Wed, 17 Feb 1999 11:40:36 +0100

+----- On Tue, 16 Feb 1999 16:10:58 PST, "J.D. Falk" writes:
| On 02/16/99, Michael Salmon <[email-masked]> wrote: 
| 
| > | In order to prevent mail loops, an implementation MUST refuse to
| > | filter a message that it has already filtered once; that is, a
| > | message must not pass through a given server twice.
| > 
| > This seems excessive to me, especially as servers are becoming larger 
| > and larger all the time. I think that mail loops would be prevented if 
| > a message could only be kept or discarded when it had been seen twice 
| > by the same user.
| 
| I don't think this RFC is the place to specify how to stop
| mail loops, except insofar as "an implementation SHOULD be
| smart enough to prevent looping of messages."  A seperate
| "Best Current Practice" draft would be more appropriate,
| and I'd love to work with somebody on that.

That seems reasonable though prevention of mail loops should be 
mandatory.

/Michael

---

From: Michael Salmon <[email-masked]>
Date: Wed, 17 Feb 1999 11:37:58 +0100

+----- On 16 Feb 1999 17:26:53 EST, Tim Showalter writes:
| > Date: Tue, 16 Feb 1999 11:01:03 +0100
| > From: Michael Salmon <[email-masked]>
| 
| > | Implementations decode header charsets to UTF-8.  Two strings are
| > | considered equal if their UTF-8 representations are identical.
| > | Implementations should decode charsets represented in the forms
| > | specified by [MIME] for both message headers and bodies.
| > | Implementations must be capable of decoding US-ASCII, ISO-8859-1,
| > | the ASCII subset of ISO-8859-* character sets, and UTF-8.
| > 
| > I think that ISO-8859-15 would be more appropriate than -1, it fixes 
| > the bugs in -1 and adds the euro.
| 
| For better or worse, I believe 8859-1 is more common and should be
| required, but I don't have a string opinion on the subject.
| 
| Is this not the case?

It is the case today but it is unlikely to be the case when sieve 
become a standard. The most important reason is the replacement of the 
generic money symbol (0xa4 ¤) with the euro symbol but it also includes 
some of the characters that they missed in Latin1.

[...]
| > [...]
| > | 2.10.3.  Message Uniqueness in a Mailbox
| > | 
| > | Implementations SHOULD NOT write a message to a mailbox where a copy
| > | of it already exists, even if a script explicitally asks for a
| > | message to be written to a mailbox twice.
| > | 
| > | The test for equality of two messages is not defined by this memo.
| > 
| > I think that this is a little tough although of course it isn't 
| > mandatory. Perhaps it should be mandatory for a script to not deliver 
| > more than once to a mailbox .
| 
| I'm not sure what you want.  That language is weasily enough to allow an 
| awful lot, quite possibly too much.
| 
| The reason for that second paragraph is that I consider two messages
| with the same message-id equal enough, but others will want to compare
| bodies in some meaningful way.

What I meant was that a message must be actively delivered into a 
mailbox twice during a single execution of the script. It would be nice 
if it could suppress the duplication of existing messages but I think 
that that could be too hard in some cases.

Should a message that is identical to a message that has been stored 
and then deleted be considered a duplicate? I think that it is 
acceptable but should not be mandatory.

| > What should happen if a require is not satisfied? I would guess that a 
| > required extension would be checked when the script was loaded but what 
| > happens if an extension is removed?
| 
| The script doesn't run at all.  I've added this sentence to 2.10.5:
| 
| | If a script does not understand an extension declared with require,
| | the script must not be used at all.

Good, does the action of sieve in this case need to be defined. As I 
see it there are 2 possibilities, 
1) perform a keep i.e. pretend that the script is null
2) write the message back into the queue
In both cases an error message should be written into the mailbox I 
think, though preferably never more than one.

Another thing that comes to mind is when are requires examined? Can 
they exist inside if statements? I can see advantages to that but it 
also seems to leave the way open for behaviour that is hard to debug.

[...]
| > [...]
| How would one write such a script?

What I had in mind was that redirect was a null action on any message 
that had been seen. If nothing else was done then an implicit keep 
would be performed.

| I think that this should be on a per-user basis, not a per-server basis,
| and I'll fix it accordingly:
| 
| | In order to prevent mail loops, implementations must prevent messages
| | from passing through a given user twice.
| 
| I think this is what I intended, and I believe it's a clear improvement.
| 
| I only want to discuss the case where a user relays a message to himself 
| (i.e., a loop).  Two messages with the same message-id can have
| different return-path values (say, if one hits a mailing list) and I
| don't want to require anything in that case; that's normal and fine and
| scripts should handle it accordingly.

I agree, it seems to fit in well with 2.10.3, in the best of all 
possible worlds no matter what strange things you do you only get one 
copy of a message.

/Michael

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Wed, 17 Feb 1999 08:25:35 -0800 (PST)

> some of the characters that they missed in Latin1.

Expect the impact of 8859-15 (so-called Latin 0) to be negligible. The only
vendors who are supporting it are those who have weak Unicode implementations.
The dominent desktop is Microsoft Windows, and it supports the Euro just fine
through Unicode; I have yet to see any application on MS Windows that supports
8859-15.

<csg>

---

From: Tim Showalter <[email-masked]>
Date: 17 Feb 1999 17:06:53 -0500

> Date: Wed, 17 Feb 1999 11:37:58 +0100

> that that could be too hard in some cases.

I don't understand your first sentence.  I can't find a case where I
want to write a message to a mailbox twice, ever.  So I've written this,
which says you shouldn't do that.

Do you want implementations to be able to write a message to a mailbox
twice?  Why?

Implementations are supposed to avoid writing messages to mailboxes if
copies of the messages already exist.  They are allowed to do so if they 
really want to.

What would you like the document to say?

> acceptable but should not be mandatory.

Because I didn't define equality, that's a reasonable behavior.  (That
is the behavior I want.)

> think, though preferably never more than one.

We punted on this as a quality of implementation issue.  I believe the
correct behavior is (1) (writing back to the queue when I've gone on
vacation is not what I want) but it was decided not to define it.

> also seems to leave the way open for behaviour that is hard to debug.

I would make requires magical but I believe following from the lack of
definitions of failure behavior described above, we can't define this
unless we define error behavior.

I'm not sure I like what's in the document, but because some folks have
expressed desire not to demand seperate parse/evaluate/execute stages,
anything that suggested such behavior was removed.

> possible worlds no matter what strange things you do you only get one 

I think what you're asking for is that a Sieve script ignores
"redirects" if it's seen this message before, possibly detectable by the
addition of a header.  That's not a bad idea, actually.  Anyone else
care for this?

---

From: Ned Freed <[email-masked]>
Date: Wed, 17 Feb 1999 15:34:55 -0800 (PST)

> vendors who are supporting it are those who have weak Unicode implementations.

Had anyone asked me to predict the impact of iso-8859-15 in advance this is
certainly what I would have said. However, this is not what I'm observing in
practice -- we've had a number of customers ask for 8bit charsets that contain
the Euro and iso-8859-15 support in particular. (And this despite the fact
we've had reasonably complete Unicode support in place for years that nobody
seems terribly interested in.)

> through Unicode; I have yet to see any application on MS Windows that supports

This may be true but I think it misses the point. Having good application
support for iso-8859-15 isn't really necessary; all you have to have something
that supports an 8bit single byte charset and then all you have to do is use
the right character tables. By contrast, getting full support for Unicode in
place is vastly more difficult.

However, I'm far from convinced this will result in wholesale replacement of
iso-8859-1 with iso-8859-15. At most I'd be willing to add iso-8859-15 to the
list of must-decode charsets, but that's as far as I'd be willing to go.

				Ned