Re: 07bis Sieve spec.

[Tim Showalter <[e-mail]>]

> Date: Tue, 30 Mar 1999 15:56:16 -0600
> From: Pete Resnick <[e-mail]>

> >The only point I feel strongly about is this:
> >>2. Why? Maybe I want to make a folder of messages that I have 
> >>rejected, or redirect them to a processor that updates my "bad 
> >>people  to filter against" list. What's the problem with rejecting 
> >>and doing  one of these other things?
> >
> >I do not want the spec to require that users be granted the ability 
> >to make a mail server lie.
> 
> But *if* reject sends an MDN (with the MDN-sent-automatically and 
> automatic-action modes), as I believe it should, and the MDN for 
> reject is "deleted", which is defined as:
> 
>    "deleted"      The message has been deleted.  The recipient may or
>                               may not have seen the message.  The
>                               recipient might "undelete" the message at
>                               a later time and read the message.
> 
> then I don't see this as a lie. You are informing the sender that his 
> message has been automatically deleted from the users normal mail 
> reading facilities and may not be seen by anyone. That's all true.
> 
> If there is consensus for the other stuff and you need some text, I 
> might be able to contribute.

Ok, right, that would change things substantially.  In fact, a lot of
the action interaction garbage goes away, because who cares what you do
with it?

Actually, given this, could we make reject required?  That's a good
thing, too.

Contributions are welcome.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14317 for ietf-mta-filters-bks; Tue, 30 Mar 1999 13:58:36 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14313 for <[e-mail]>; Tue, 30 Mar 1999 13:58:35 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA02195; Tue, 30 Mar 1999 16:58:36 -0500 (EST)
Date: 30 Mar 1999 16:58:47 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: DES Ft. Bragg $400 million in gold bullion Nazi Waco, Texas Rule Psix colonel
To: Pete Resnick <[e-mail]>
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: 07bis Sieve spec.
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Tue, 30 Mar 1999 15:56:16 -0600
> From: Pete Resnick <[e-mail]>

> >The only point I feel strongly about is this:
> >>2. Why? Maybe I want to make a folder of messages that I have 
> >>rejected, or redirect them to a processor that updates my "bad 
> >>people  to filter against" list. What's the problem with rejecting 
> >>and doing  one of these other things?
> >
> >I do not want the spec to require that users be granted the ability 
> >to make a mail server lie.
> 
> But *if* reject sends an MDN (with the MDN-sent-automatically and 
> automatic-action modes), as I believe it should, and the MDN for 
> reject is "deleted", which is defined as:
> 
>    "deleted"      The message has been deleted.  The recipient may or
>                               may not have seen the message.  The
>                               recipient might "undelete" the message at
>                               a later time and read the message.
> 
> then I don't see this as a lie. You are informing the sender that his 
> message has been automatically deleted from the users normal mail 
> reading facilities and may not be seen by anyone. That's all true.
> 
> If there is consensus for the other stuff and you need some text, I 
> might be able to contribute.

Ok, right, that would change things substantially.  In fact, a lot of
the action interaction garbage goes away, because who cares what you do
with it?

Actually, given this, could we make reject required?  That's a good
thing, too.

Contributions are welcome.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14297 for ietf-mta-filters-bks; Tue, 30 Mar 1999 13:56:21 -0800 (PST)
Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14292 for <[e-mail]>; Tue, 30 Mar 1999 13:56:17 -0800 (PST)
Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 2.2); Tue, 30 Mar 1999 15:56:19 -0600
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: [e-mail]
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Eudora [Macintosh version 4.2b75-4.99]
Date: Tue, 30 Mar 1999 15:56:16 -0600
To: Tim Showalter <[e-mail]>
From: Pete Resnick <[e-mail]>
Subject: Re: 07bis Sieve spec.
Cc: Tim Showalter <[e-mail]>, [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 3/30/99 at 4:43 PM -0500, Tim Showalter wrote:

>The only point I feel strongly about is this:
>>2. Why? Maybe I want to make a folder of messages that I have 
>>rejected, or redirect them to a processor that updates my "bad 
>>people  to filter against" list. What's the problem with rejecting 
>>and doing  one of these other things?
>
>I do not want the spec to require that users be granted the ability 
>to make a mail server lie.

But *if* reject sends an MDN (with the MDN-sent-automatically and 
automatic-action modes), as I believe it should, and the MDN for 
reject is "deleted", which is defined as:

   "deleted"      The message has been deleted.  The recipient may or
                              may not have seen the message.  The
                              recipient might "undelete" the message at
                              a later time and read the message.

then I don't see this as a lie. You are informing the sender that his 
message has been automatically deleted from the users normal mail 
reading facilities and may not be seen by anyone. That's all true.

If there is consensus for the other stuff and you need some text, I 
might be able to contribute.

pr
-- 
Pete Resnick <mailto:[e-mail]>
Eudora Engineering - QUALCOMM Incorporated
Ph: [phone] or [phone], Fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14158 for ietf-mta-filters-bks; Tue, 30 Mar 1999 13:44:55 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14154 for <[e-mail]>; Tue, 30 Mar 1999 13:44:54 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA00866; Tue, 30 Mar 1999 16:43:49 -0500 (EST)
Date: 30 Mar 1999 16:43:59 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: SDI South Africa militia domestic disruption assassination [Hello to all my fans in domestic surveillance] Rule Psix
To: Tim Showalter <[e-mail]>
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: 07bis Sieve spec.
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Tue, 30 Mar 1999 13:57:01 -0600
> From: Pete Resnick <[e-mail]>
> Cc: [e-mail]

> OK, not to start controversies that may have already been decided, but:

Too late.  Actually I don't care about most of this, and now's the time
to fix it.  I note, however, that most of that language has been around
for quite a while.

The only point I feel strongly about is this:

> 2. Why? Maybe I want to make a folder of messages that I have 
> rejected, or redirect them to a processor that updates my "bad people 
> to filter against" list. What's the problem with rejecting and doing 
> one of these other things?

I do not want the spec to require that users be granted the ability to
make a mail server lie.

Everything else, I have no problem.  Some of the reject language is
probably too specific, and making things a little more flexible doesn't
bother me.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12927 for ietf-mta-filters-bks; Tue, 30 Mar 1999 11:57:16 -0800 (PST)
Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA12923 for <[e-mail]>; Tue, 30 Mar 1999 11:57:14 -0800 (PST)
Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 2.2); Tue, 30 Mar 1999 13:57:04 -0600
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: [e-mail]
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Eudora [Macintosh version 4.2b75-4.99]
Date: Tue, 30 Mar 1999 13:57:01 -0600
To: Tim Showalter <[e-mail]>
From: Pete Resnick <[e-mail]>
Subject: Re: 07bis Sieve spec.
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

OK, not to start controversies that may have already been decided, but:

On 3/29/99 at 3:51 PM -0500, Tim Showalter wrote:

>Implementations of the language are expected to take place at time 
>of final delivery, when the message is moved to the user-accessible 
>mailbox.
[...]
>A reject message MUST take the form of a failure DSN as specified  by [DSN].

1. Why is a reject sending a DSN instead of a "deleted" MDN? Given 
the first quote above, MDN makes a great deal more sense. It's still 
in the form of multipart/report, but the semantics are much closer to 
MDN than they are to DSN.

>A rejected message may not be filed, redirected, or kept.

2. Why? Maybe I want to make a folder of messages that I have 
rejected, or redirect them to a processor that updates my "bad people 
to filter against" list. What's the problem with rejecting and doing 
one of these other things?

>The optional "reject" action resends the message to the sender, 
>wrapping it in a "reject" form, noting that it was rejected by the 
>recipient.

3. First, I think "resends" is the wrong word here; "returns" is 
probably better. In either case, MUST the entire message be returned, 
or MAY a truncated version be returned instead?

>   Discard MUST be silent; that is, it MUST NOT return a non-delivery
>   notification of any kind.

4. Does this change in the presence of a Disposition-Notification-To: 
header field? Is it still MUST NOT send, or can I send a "denied" 
MDN, as in (from RFC 2298):

   "denied"       The recipient does not wish the sender to be informed
                              of the message's disposition.  A UA may
                              also siliently ignore message disposition
                              requests in this situation.

Finally, it may be a good thing to mention the "dispatched" and/or 
"processed" MDNs in relation to Sieve. They seem applicable.

pr
-- 
Pete Resnick <mailto:[e-mail]>
Eudora Engineering - QUALCOMM Incorporated
Ph: [phone] or [phone], Fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA01893 for ietf-mta-filters-bks; Mon, 29 Mar 1999 12:52:51 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01888 for <[e-mail]>; Mon, 29 Mar 1999 12:52:47 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA26826; Mon, 29 Mar 1999 15:51:28 -0500 (EST)
Date: 29 Mar 1999 15:51:33 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: AK-47 quiche munitions arrangements militia Panama Kibo
To: [e-mail]
Subject: 07bis Sieve spec.
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here's a version of the Sieve spec, 07bis.  Some parts are not yet
complete (see 0.2.2.1).  I will assume that if I don't hear anything
complaining by Wednesday, I will assume that I am to put in action
interaction stuff, and will try and figure out exactly what goes in a
reject DSN.  As I need to go stare at the spec, I am afraid I won't get
it quite right, so guidance is appreciated.

Tim

-- 
Tim Showalter <[e-mail]>







Network Working Group                                       T. Showalter
Internet Draft: Sieve                                    Carnegie Mellon
Document: draft-showalter-sieve-07bis.txt                 March 29, 1999
Expire in six months


                    Sieve: A Mail Filtering Language


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or using this
   protocol are STRONGLY URGED to get in touch with the author before
   embarking on such a project.

Copyright Notice

   Copyright (C) The Internet Society 1999.  All Rights Reserved.













Showalter                 Expire in Six Months                  [Page 1]

Internet DRAFT                   Sieve                    March 29, 1999


Abstract

   This document describes a language for filtering e-mail messages at
   time of final delivery.  It is designed to be implementable on either
   a mail client or mail server.  It is meant to be extensible, simple,
   and independent of access protocol, mail architecture, and operating
   system.  It is suitable for running on a mail server where users may
   not be allowed to execute arbitrary programs, such as on black box
   IMAP servers, as it has no variables, loops, or ability to shell out
   to external programs.









































Showalter                 Expire in Six Months                  [Page 2]

Internet DRAFT                   Sieve                    March 29, 1999





                           Table of Contents



Status of this memo ...............................................    1
Copyright Notice ..................................................    1
Abstract ..........................................................    2
0.      Meta-information on this draft ............................    5
0.1.     Discussion ...............................................    5
0.2.     Known Issues .............................................    5
0.2.1.   Probable Extensions ......................................    5
0.2.2.   Known Bugs ...............................................    5
0.2.2.1. To-Do List ...............................................    6
0.3.     Noted Changes ............................................    6
0.3.1.   since -07 ................................................    6
0.3.2.   since -06 ................................................    7
0.3.3.   since -05 ................................................    7
0.3.4.   since -04 ................................................    8
1.      Introduction ..............................................   10
1.1.     Conventions Used in This Document ........................   10
1.2.     Example mail messages ....................................   11
2.      Design ....................................................   12
2.1.     Form of the Language .....................................   12
2.2.     Whitespace ...............................................   12
2.3.     Comments .................................................   12
2.4.     Literal Data .............................................   13
2.4.1.   Numbers ..................................................   13
2.4.2.   Strings ..................................................   13
2.4.2.1. String Lists .............................................   14
2.4.2.2. Headers ..................................................   14
2.4.2.3. Addresses ................................................   14
2.4.2.4. MIME Parts ...............................................   15
2.5.     Tests ....................................................   15
2.5.1.   Test Lists ...............................................   15
2.6.     Arguments ................................................   15
2.6.1.   Positional Arguments .....................................   15
2.6.2.   Tagged Arguments .........................................   16
2.6.3.   Optional Arguments .......................................   16
2.6.4.   Types of Arguments .......................................   16
2.7.     String Comparison ........................................   17
2.7.1.   Match Type ...............................................   17
2.7.2.   Comparisons Across Character Sets ........................   18
2.7.3.   Comparators ..............................................   18
2.7.4.   Comparisons Against Addresses ............................   19
2.8.     Blocks ...................................................   20



Showalter                 Expire in Six Months                  [Page 3]

Internet DRAFT                   Sieve                    March 29, 1999


2.9.     Commands .................................................   20
2.10.    Evaluation ...............................................   20
2.10.1.  Action Interaction .......................................   21
2.10.2.  Implicit Keep ............................................   21
2.10.3.  Message Uniqueness in a Mailbox ..........................   21
2.10.4.  Limits on Numbers of Actions .............................   21
2.10.5.  Extensions and Optional Features .........................   22
2.10.6.  Errors ...................................................   22
3.      Control Commands ..........................................   23
3.1.    If ........................................................   23
3.2.     Control Structure Require ................................   24
3.3.     Control Structure Stop ...................................   24
4.      Action Commands ...........................................   25
4.1.     Action reject ............................................   25
4.2.     Action fileinto ..........................................   26
4.3.     Action redirect ..........................................   26
4.4.     Action keep ..............................................   26
4.5.     Action discard ...........................................   27
5.      Test Commands .............................................   27
5.1.     Test address .............................................   27
5.2.     Test allof ...............................................   28
5.3.     Test anyof ...............................................   28
5.4.     Test envelope ............................................   29
5.5.     Test exists ..............................................   30
5.6.     Test false ...............................................   30
5.7.     Test header ..............................................   30
5.8.     Test not .................................................   30
5.9.     Test size ................................................   31
5.10.    Test true ................................................   31
6.      Extensibility .............................................   31
6.1.     Capability String ........................................   32
6.2.     IANA Considerations ......................................   32
6.3.     Capability Transport .....................................   33
7.      Transmission ..............................................   33
8.      Parsing ...................................................   34
8.1.     Lexical Tokens ...........................................   34
8.2.     Grammar ..................................................   35
9.      Extended Example ..........................................   35
10.     Security Considerations ...................................   37
11.     Acknowledgments ...........................................   37
12.     Author's Address ..........................................   37
Appendix A.  References ...........................................   37
Appendix B.  Full Copyright Statement .............................   38








Showalter                 Expire in Six Months                  [Page 4]

Internet DRAFT                   Sieve                    March 29, 1999


0.      Meta-information on this draft

   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.

0.1.     Discussion

   This draft is being discussed on the MTA Filters mailing list at
   <[e-mail]>.  Subscription requests can be sent to
   <[e-mail]> (send an email message with the
   word "subscribe" in the body).  More information on the mailing list
   along with a WWW archive of back messages is available at
   <http://www.imc.org/ietf-mta-filters/>.

0.2.     Known Issues

0.2.1.   Probable Extensions

   The following suggestions have been made, and will probably be
   addressed by extensions.

   An extension for regular expressions will be written.  While regular
   expressions are of questionable utility for most users, the
   programmers writing implementations desperately want regular
   expressions.

   "Detailed" addressing or "sub-addressing" (i.e., the "foo" in an
   address "[e-mail]") is not handled, and will be moved
   to an extension for those systems that offer it.

   A vacation command has been requested for an extension.Vacation
   functionality isn't required by the draft because having vacation
   assumes you can store the addresses of people who have already
   received vacation notifications, which isn't always the case.  It is
   in a separate document for no particular reason.

   A suggestion was made to set IMAP flags on delivery (e.g., \Flagged,
   \Deleted, \Answered, \Seen).

   An "include" command is not included, but has been suggested for an
   extension.

0.2.2.   Known Bugs

   I have punted on multiple fileinto.

   The title of 2.10.1 is probably open for suggestions.  Given the
   existence of DSNs and the similarity of names, I'm not happy with it.



Showalter                 Expire in Six Months                  [Page 5]

Internet DRAFT                   Sieve                    March 29, 1999


   Some discussion on how many commands are allowed per command type,
   site-defined limits, etc., needs to be clarified; those parts that
   are discussed in the Security Considerations section need to be
   cleaned up.

   NOTE! that since we have spent a lot of time discussing action
   interaction, and it has been done in a couple different ways and a
   couple different places, there are bits and pieces of old text lying
   around that must be removed.  If you find one, please let me know.

0.2.2.1. To-Do List

   These are the changes from the Sieve BOF meeting that have not been
   made, pending some degree of resolution from the mailing list.

   - Action interaction
     e.g. reject vs. keep/fileinto
     Proposal:
       discard is compatible with everything -- just cancels the
         default keep
       reject is incompatible with all but discard
       keep == fileinto "inbox"

     Discussion:
       add to spec: extensions should discuss incompatible
                    actions
       discussion about extensions having to refer to other
                  extensions, easy to get out of hand.
       discuss on mailing list for resolution

   - User-specified charset on outgoing msg
     Discussion:
       text may be MIME object?
       OK... put in switch: text or MIME
       (switch is in vacation but not rject)

0.3.     Noted Changes

0.3.1.   since -07

   Require an Stop moved to Control Structures section.

   Text removed: "Therefore, an implementation SHOULD only allow one
   "reject" per message processed, and MAY limit the number of redirect
   actions taken."  Covered by 2.10.4.

   Text removed: "An implementation MUST refuse to redirect a message to
   itself."  Hopefully covered by loop control stuff in reject.



Showalter                 Expire in Six Months                  [Page 6]

Internet DRAFT                   Sieve                    March 29, 1999


   Various corrections from Randy Gellens.

   The syntax definitions of allof and anyof have changed to use a
   test-list instead of describing the grammar of the test-list.

0.3.2.   since -06

   Larry Greenfield supplied a rewrite of the grammar that separates
   things out into a tokenizer and a parser.  This grammar also allows
   UTF-8 characters in strings (previous versions limited characters to
   the 0x01-0x7F range).

   Steve Hole made a number of editorial suggestions that were taken.
   This includes discussing a tokenizer in 2.1 and renaming sections 3,
   4, and 5 ("Control Structures" became "Control Commands", "Actions"
   became "Action Commands", and "Tests" became "Test Commands").  Other
   uses of these terms in this document should have been changed to
   match, but I probably missed some.

   Lots of new rules were added to section 2.10, and should be reviewed
   carefully.  I think that they reflect consensus, but am not sure.

   Tokens are defined as being case insensitive.

   Envelope takes a COMPARATOR argument.

   ADDRESS-PART defaults to :all.

   Test "true" has been put back.  Truth was accidentally deleted.

   Gregory Sereda provided several examples, including a long one which
   has been inserted as section 9.

   The copyright date has been fixed and the copyright and I-D
   boilerplate updated with the latest and greatest from the IETF web
   site.

   Unnecessary brackets were remvoed around various syntax elements in
   section 2.7.

   Acknowledgments were moved further towards the end.

   Several other more minor fixes were made.

0.3.3.   since -05

   Draft -05 was never published in the Internet-Drafts repository, but
   was circulated on the [e-mail] mailing list.



Showalter                 Expire in Six Months                  [Page 7]

Internet DRAFT                   Sieve                    March 29, 1999


   All nits submitted by Greg Sereda are hopefully addressed.  Most of
   these were example bugs, but he also pointed out that types for
   arguments were under-specified and in several cases orders of
   arguments disagreed with the syntax.

   "Match keyword" was changed to "match type" as an editorial change.

   "Forward" was renamed to "redirect" because of the conflict between
   multiple meanings of "forward" in order to make it clear exactly what
   we meant.

   Limitation of one redirect per message should be removed.

   The types of arguments have been added to their syntax line.

   Added "require" back in a slightly different form.  "Require" is now
   an action (arbitrarily) and has been added to sec. 2.10 as well.

   Implementations are responsible for not allowing mail loops.

   All discussion of short-circuit evaluation has been removed.  On a
   related note, tests must not have side effects.

   Envelope is required to drop source routes.

   An address-matching primitive has been added.

0.3.4.   since -04

   Here are a list of changes from draft 04.  (It may not be complete.)

   * Concensus: i;ascii-casemap is required.

   * Consensus: i;ascii-casemap is the default.

   * Header name compares are always case-insensitive; the draft now
     says so.

   * Several examples were fixed, but it is likely that errors remain.

   * Bug: Section 7, remove reference to "support".

   * There are two namespaces  for extension names, one "vnd.", one
     everything else, like MIME.

   * All XXXs have been removed, except for in IANA section.

   * Fileinto is optional, and discussion of local mail folders and POP3



Showalter                 Expire in Six Months                  [Page 8]

Internet DRAFT                   Sieve                    March 29, 1999


     has been removed.

   * A non-present comparator is considered to be basically a syntax
     error.

   * Resent headers are not to be added by the "redirect" command.

   * Tagged arguments must follow the keyword, and may not be
     interspersed with positional arguments.

   * Envelope-matching commands are to be added with the syntax that
     Barry suggested.

   * Put back :matches match type.

   * What happens when an error occurs has been dropped.

   * Reject is now optional.

   * Implementations are encouraged to decode header charsets, and if
     they don't, are required to not do compares on 8-bit data.






























Showalter                 Expire in Six Months                  [Page 9]

Internet DRAFT                   Sieve                    March 29, 1999


1.      Introduction

   This memo documents a language that can be used to create filters for
   electronic mail. It is not tied to any particular operating system or
   mail architecture.  It requires the use of [IMAIL]-compliant
   messages, but should otherwise generalize to many systems.

   The language is powerful enough to be useful, but limited in power in
   order to allow for a safe server-side filtering system.  The
   intention is to make it impossible for users to do anything more
   complex (and dangerous) than write simple mail filters, along with
   facilitating GUI-based editors. The language is not Turing-complete,
   and provides no way to write a loop or a function.  Variables are not
   provided.

   Implementations of the language are expected to take place at time of
   final delivery, when the message is moved to the user-accessible
   mailbox.  In systems where the MTA does final delivery, such as
   traditional Unix mail, it is reasonable to sort when the MTA deposits
   mail into the user's mailbox.

   There are a number of reasons to use a filtering system.  Mail
   traffic for most users has been increasing due both to increased
   usage of e-mail, the emergence of unsolicited email as a form of
   advertising, and increased usage of mailing lists.

   Experience at Carnegie Mellon has shown that if a filtering system is
   made available to users, many will make use of it in order to file
   messages from specific users or mailing lists.  However, many others
   did not make use of the Andrew system's FLAMES filtering language
   [FLAMES] due to difficulty in setting it up.

   Because of the expectation that users will make use of filtering if
   it is offered and easy to use, this language has been made simple
   enough to allow many users to make use of it, but rich enough that it
   can be used productively.  However, it is expected that GUI-based
   editors will be the preferred way of editing filters for a large
   number of users.

1.1.     Conventions Used in This Document

   In the sections of this document that discuss the requirements of
   various keywords and operators, the following conventions have been
   adopted.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and
   "MAY" in this document are to be interpreted as defined in
   [KEYWORDS].



Showalter                 Expire in Six Months                 [Page 10]

Internet DRAFT                   Sieve                    March 29, 1999


   Each section on a command (test, action, or control structure) has a
   line labeled "Syntax:".  This line describes the syntax of the
   command, including its name and its arguments.  Required arguments
   are listed inside angle brackets ("<" and ">").  Optional arguments
   are listed inside square brackets ("[" and "]").  Each argument is
   followed by its type, so "<key: string>" represents an argument
   called "key" that is a string.  Literal strings are represented with
   double-quoted strings.  Alternatives are separated with slashes, and
   parenthesis are used for grouping, similar to [ABNF].

   In the "Syntax" line, there are three special pieces of syntax that
   are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART.
   These are discussed in sections 2.7.1, 2.7.3, and 2.7.4,
   respectively.

   The formal grammar for these commands in section 10 and is the
   authoritative reference on how to construct commands, but the formal
   grammar does not specify the order, semantics, number or types of
   arguments to commands, nor the legal command names.  The intent is to
   allow for extension without changing the grammar.

1.2.     Example mail messages

   The following mail messages will be used throughout this document  in
   examples.

   Message A
   -----------------------------------------------------------
   Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST)
   From: [e-mail]
   To: [e-mail]
   Subject: I have a present for you

   Look, I'm sorry about the whole anvil thing, and I really
   didn't mean to try and drop it on you from the top of the
   cliff.  I want to try to make it up to you.  I've got some
   great birdseed over here at my place--top of the line
   stuff--and if you come by, I'll have it all wrapped up
   for you.  I'm really sorry for all the problems I've caused
   for you over the years, but I know we can work this out.
   --
   Wile E. Coyote       "Super Genius"        [e-mail]
   -----------------------------------------------------------








Showalter                 Expire in Six Months                 [Page 11]

Internet DRAFT                   Sieve                    March 29, 1999


   Message B
   -----------------------------------------------------------
   From: youcouldberich!@reply-by-postal-mail.invalid
   Sender: [e-mail]
   To: [e-mail]
   Date:  Mon, 31 Mar 1997 18:26:10 -0800
   Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$

   YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT
   IT!  SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS!  IT WILL
   GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY!
   MONEY! MONEY! COLD HARD CASH!  YOU WILL RECEIVE OVER
   $20,000 IN LESS THAN TWO MONTHS!  AND IT'S LEGAL!!!!!!!!!
   !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1  JUST
   SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW!
   -----------------------------------------------------------

2.      Design

2.1.     Form of the Language

   The language consists of a set of commands.   Each command consists
   of a set of tokens delimited by whitespace.   The first token is the
   command string followed by zero or more arguments.  Arguments may be
   literal data, tags, blocks of commands, or test commands.

   The language is represented in UTF-8, as specified in [UTF-8].

   Tokens in the ASCII range are considered case-insensitive.

2.2.     Whitespace

   Whitespace is used to separate tokens.  Whitespace is made up of
   tabs, newlines (CRLF, never just CR or LF), and the space character.
   The amount of whitespace used is not significant.

2.3.     Comments

   Comments begin with a "#" character that is not contained within a
   string and continue until the next CRLF.  Comments are semantically
   equivalent to whitespace and are permitted to be used anyplace that
   whitespace is (with one exception in multi-line strings, as described
   in the grammar).

   Example:  if size :over 100K { # this is a comment
                discard;
             }




Showalter                 Expire in Six Months                 [Page 12]

Internet DRAFT                   Sieve                    March 29, 1999


2.4.     Literal Data

   Literal data means data that is not executed, merely evaluated "as
   is", to be used as arguments to commands.  Literal data is limited to
   numbers and strings.

2.4.1.   Numbers

   Numbers are given as ordinary decimal numbers.  However, those
   numbers that have a tendency to be fairly large, such as message
   sizes, MAY have a "K", "M", or "G" appended to indicate a multiple of
   a base-two number.  To be comparable with the power-of-two-based
   versions of SI units that computers frequently use, K specifies kilo,
   or 1,024 (2^10) times the value of the number; M specifies mega, or
   1,048,576 (2^20) times the value of the number; and G specifies giga,
   or 1,073,741,824 (2^30) times the value of the number.

   Implementations MUST provide 31 bits of magnitude in numbers, but may
   provide more.

   Only positive integers are permitted by this specification.

2.4.2.   Strings

   Scripts involve large numbers of strings, as they are used for
   pattern matching, addresses, and textual bodies, etc.  Typically,
   short quoted strings suffice for most uses, but a more convenient
   form is provided for longer strings such as bodies of messages.

   A quoted string starts and ends with a single double quote (the <">
   character, ASCII 34).  A backslash ("\", ASCII 92) inside of a quoted
   string is followed by either another backslash or a double quote.
   This two-character sequence represents a single backslash or double-
   quote within the string, respectively.

   Other escape sequences may be permitted depending on context.  An
   undefined escape sequence (such as "\a" in a context where "a" has no
   special meaning) is interpreted as if there were no backslash (in
   this case, "\a" is just "a").

   Non-printing characters such as tabs, CR and LF, and control
   characters are permitted in strings.  NUL (ASCII 0) is not allowed in
   strings.

   For entering larger amounts of text, such as an email message, a
   multi-line form is allowed.  It starts with the keyword "text:",
   followed by a CRLF, and ends with the sequence of a CRLF, a single
   period, and another CRLF.  In order to allow the message to begin



Showalter                 Expire in Six Months                 [Page 13]

Internet DRAFT                   Sieve                    March 29, 1999


   lines with a single-dot, lines are dot-stuffed.  That is, when
   composing a message body, an extra `.' is added before each line
   which begins with a `.'.  When the server interprets the script,
   these extra dots are removed.

   Note that a comment or whitespace may occur in between the "text:"
   and the CRLF, but not within the string itself.

2.4.2.1. String Lists

   When matching patterns, it is frequently convienent to match against
   groups of strings instead of single strings.  For this reason, a list
   of strings is allowed in many tests, implying that if the test is
   true using any one of the strings, then the test is true.
   Implementations are encouraged to use short-circuit evaluation in
   these cases.

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

   Conversely, in any case where a list of strings would be appropriate,
   a single string is allowed without being a member of a list: it is
   equivalent to a list with a single member.  This means that the test
   `exists "To"' is equivalent to the test `exists ["To"]'.

2.4.2.2. Headers

   Headers are a subset of strings.  In the Internet Message
   Specification [IMAIL], each header line is allowed to have whitespace
   nearly anywhere in the line, including after the field name and
   before the subsequent colon.  Extra spaces between the header name
   and the ":" in a header field are ignored.

   A header name never contains a colon.  The "From" header refers to a
   line beginning "From:" (or "From   :", etc.).  No header will match
   the string "From:" due to the trailing colon.

2.4.2.3. Addresses

   A number of commands call for email addresses, which are also a
   subset of strings.  These addresses must be compliant with [IMAIL].
   Implementations MUST ensure that the addresses are syntactically
   valid, but need not ensure that they are actually deliverable.






Showalter                 Expire in Six Months                 [Page 14]

Internet DRAFT                   Sieve                    March 29, 1999


2.4.2.4. MIME Parts

   In a few places, [MIME] bodyparts are represented as strings.  These
   parts include MIME headers and the body.  This provides a way of
   embedding typed data within a Sieve script so that, among other
   things, character sets other than UTF-8 can be used for output
   messages.

2.5.     Tests

   Tests are given as arguments to commands in order to control how they
   run.  Generally, a test is used to decide if a block of code should
   be evaluated.

   Tests MUST NOT have side effects.  That is, a test must not make
   changes to state.  No tests in this specification have side effects,
   and side effects are forbidden in extension tests as well.

   The rationale for this is that tests with side effects impair
   readability and maintainability and are difficult to represent in a
   graphic interface for generating scripts, so side effects are
   confined to actions where they are clearer.

2.5.1.   Test Lists

   Some tests ("allof" and "anyof", which implement logical and and
   logical or, respectively) need to take more than a single test as an
   argument.  The test-list syntax element provides a way of grouping
   tests.

   Example:  if anyof (not exists ["From", "Date"],
                   header :contains "from" "[e-mail]") {
                discard;
             }

2.6.     Arguments

   In order to specify what to do, most commands take arguments.  There
   are three types of arguments: positional, tagged, and optional.

2.6.1.   Positional Arguments

   Positional arguments are given to a command which discerns their
   meaning based on their order.  When a command takes positional
   arguments, all positional arguments must be supplied, and must be in
   the order prescribed.





Showalter                 Expire in Six Months                 [Page 15]

Internet DRAFT                   Sieve                    March 29, 1999


2.6.2.   Tagged Arguments

   This document provides for tagged arguments in the style of
   CommonLISP.  These are also similar to flags given to commands in
   most command-line systems.

   A tagged argument is an argument for a command that begins with ":",
   and consists of a tag naming the argument, such as ":contains".  This
   argument means that zero or more of the next tokens have some
   particular meaning, depending on the argument.  These next tokens may
   be numbers or strings, but are never blocks.

   So tagged arguments are similar to positional arguments, except that
   instead of the meaning being derived from the command, it is derived
   from the tag.

   Tagged arguments must appear before positional arguments, but they
   may appear in any order.  For convenience, this is not expressed in
   the syntax definitions with commands, but they still may be reordered
   arbitrarily provided they appear before positional arguments.  Tagged
   arguments may be mixed with optional arguments.

   To keep the language simple, tagged arguments should not take tagged
   arguments as arguments.

2.6.3.   Optional Arguments

   Optional arguments are exactly like tagged arguments except that they
   may be left out, in which case a default value is implied.  Because
   optional arguments tend to result in shorter scripts, they have been
   used far more than tagged arguments.

   One particularly noteworthy case is the ":comparator" argument, which
   allows the user to specify which [ACAP] comparator will be used to
   compare two strings, since different languages may impose different
   orderings on UTF-8 [UTF-8] characters.

2.6.4.   Types of Arguments

   Abstractly, arguments may be literal data, tests, or blocks of
   commands.  In this way, an "if" control structure is merely a command
   that happens to take a test and a block as arguments and may execute
   the block of code.

   However, this abstraction is ambiguous from a parsing standpoint.
   The grammar in section 9.2 presents a parsable version of this:
   arguments are string-lists, numbers, and tags, which may be followed
   by a test or a test-list, which may be followed by a block of



Showalter                 Expire in Six Months                 [Page 16]

Internet DRAFT                   Sieve                    March 29, 1999


   commands.  No more than one test or test list, nor more than one
   block of commands, may be used, and commands that end with blocks of
   commands do not end with semicolons.

2.7.     String Comparison

   When matching one string against another, there are a number of ways
   of performing the match.  These are accomplished with three types of
   matches:  exact match, a substring match, and a wildcard glob-style
   match.  In order to provide for matches between character sets and
   case insensitivity, Sieve borrows ACAP's comparator registry.

   However, when a string is represents the name of a header, the
   comparator is never user-specified.  Header comparisons are always
   done in a case-insensitive manner, since this is the way things are
   defined in the message specification [IMAIL].  That is, header-name
   comparisons are always done with the "i;ascii-casemap" comparator.

2.7.1.   Match Type

   There are three allowed match types describing the allowed match in
   this draft: they are ":is", ":contains", and ":matches".  Match type
   are supplied to those commands which allow them to specify whether
   the match is to be a complete match or not.

   These are used as tagged arguments to tests that perform string
   comparison.  Exactly one of them is necessary for a command.

   The ":contains" match type describes a substring match.  If the value
   argument contains the key argument as a substring, the match is true.
   For instance, the string "frobnitzm" contains "frob" and "nit", but
   not "fbm".  The null key ("") is contained in all values.

   The ":is" match type describes an absolute match; if the contents of
   the first string are absolutely the same as the contents of the
   second string, they match.  Only the string "frobnitzm" is the string
   "frobnitzm".  The null key only ":is" the null value.

   The ":matches" version specifies a wildcard match using the
   characters "*" and "?".  "*" matches zero or more characters, and "?"
   matches a single character.  "?" and "*" may be escaped as "\?" and
   "\*" in strings to match against themselves.

   In order to specify what type of match is supposed to happen,
   commands that support matching take optional tagged arguments
   ":matches", ":is", and ":contains".  Commands default to using ":is"
   matching.  Note that these modifiers may interact with comparators;
   in particular, some comparators are not suitable for matching with



Showalter                 Expire in Six Months                 [Page 17]

Internet DRAFT                   Sieve                    March 29, 1999


   ":contains" or ":matches".  It is an error to use a comparator with
   ":contains" or ":matches" that is not compatible with it.

   For convenience, the "MATCH-TYPE" syntax element is defined  here  as
   follows:

   Syntax:   ":is" / ":contains" / ":matches"


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.

   If implementations fail to support the above behavior, they MUST
   conform to the following:

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

2.7.3.   Comparators

   In order to allow for language-independent, case-independent matches,
   the match type may be coupled with a comparator name.  Comparators
   are described for [ACAP]; a registry is defined for ACAP, and this
   specification uses that registry.

   ACAP defines multiple comparator types.  Only equality types are used
   in this specification.

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

   Some comparators may not be usable with substring matches; that is,
   they may only work with ":is".  It is an error to try and use a
   comparator with ":matches" or ":contains" that is not compatible with
   it.



Showalter                 Expire in Six Months                 [Page 18]

Internet DRAFT                   Sieve                    March 29, 1999


   A comparator is specified with commands that support matching by the
   ":comparator" option.  This option is followed by a string providing
   the name of the comparator to be used.  For convenience, the syntax
   of a comparator is abbreviated to "COMPARATOR", and (repeated in
   several tests) is as follows:

   Syntax:   ":comparator" <comparator-name: string>

   So in this example,

   Example:  if header :contains :comparator "i;octet" "Subject"
                "MAKE MONEY FAST" {
                   discard;
             }


   would discard any message with subjects like "You can MAKE MONEY
   FAST", but not "You can Make Money Fast", since the comparator used
   is case-sensitive.

   If a comparator is not known to an implementation, it is treated in
   the same way as an error.

   Both ":matches" and ":contains" match type are compatible with the
   "i;octet" and "i;ascii-casemap" comparators and may be used with
   them.

2.7.4.   Comparisons Against Addresses

   Addresses are probably one of the most frequent things represented as
   strings.  These are structured, and being able to compare against the
   local-part or the domain of an address is useful, so some tests that
   act exclusively on addresses take an additional optional argument
   that specifies what the test acts on.

   These optional arguments are ":localpart", ":domain", and ":all",
   which act on the local-part (left-side), the domain part (right-
   side), and the whole address.

   The kind of comparison done, such as whether or not the test done is
   case-insensitive, is specified as a comparator argument to the test.

   If an optional address-part is omitted, the default of ":all".

   For convenience, the "ADDRESS-PART" syntax element is defined here as
   follows:

   Syntax:   ":localpart" / ":domain" / ":all"



Showalter                 Expire in Six Months                 [Page 19]

Internet DRAFT                   Sieve                    March 29, 1999


2.8.     Blocks

   Blocks are sets of commands enclosed within curly braces.  Blocks are
   supplied to commands so that the commands can implement control
   commands.

   A control structure is a command that happens to take a test and a
   block as one of its arguments; depending on the result of the test
   supplied as another argument, it runs the code in the block some
   number.

   Note that by the commands supplied in the specification, there are no
   loops, so the control structures supplied--if, elsif, and else--run a
   block either once or not at all.  In this case, there are two
   arguments, the test and the control structure.

2.9.     Commands

   Sieve scripts are sequences of commands.  Commands can take any of
   the tokens above as arguments, and arguments may be either tagged or
   positional arguments.  Not all commands take all arguments.

   There are three kinds of commands: test commands, action commands,
   and control commands.

   The simplest is an action command.  An action command is an
   identifier followed by zero or more arguments, terminated by a
   semicolon.  Action commands do not take tests or blocks as arguments.

   A control command is similar, but it takes a test as an argument, and
   ends with a block instead of a semicolon.

   A test command is used as part of a control command.  It is used to
   specify whether or not the block of code given to the control command
   is executed.

2.10.    Evaluation














Showalter                 Expire in Six Months                 [Page 20]

Internet DRAFT                   Sieve                    March 29, 1999


2.10.1.  Action Interaction

   Some actions cannot be used with other actions because the result
   would be absurd.  These restrictions are noted throughout this memo.

   Extension actions MUST state how they interact with actions defined
   in this specification.

2.10.2.  Implicit Keep

   Previous experience with filtering systems suggests that cases tend
   to be missed in scripts.  To prevent massive errors, Sieve has an
   "implicit keep".

   An implicit keep is performed if a message is not written to a
   mailbox, redirected to a new address, or explicitly thrown out.  That
   is, if a fileinto, a keep, a redirect, or a discard is performed, an
   implicit keep is not.

   For instance, with any of the short messages offered above, the
   following script produces no actions.

   Example:  if size :over 500K { discard; }

   As a result, the implicit keep is taken.

2.10.3.  Message Uniqueness in a Mailbox

   Implementations SHOULD NOT deliver a message to the same mailbox more
   than once, even if a script explicitly asks for a message to be
   written to a mailbox twice.

   The test for equality of two messages is not defined by this memo.

2.10.4.  Limits on Numbers of Actions

   Site policy may limit numbers of actions taken.  In the event that a
   policy limits the number of actions taken on a particular message, an
   error occurs.

   Implementations MUST prohibit more than one reject.

   Implementations MUST allow at least one keep or one fileinto.  If
   fileinto is not implemented, implementations MUST allow at least one
   keep.






Showalter                 Expire in Six Months                 [Page 21]

Internet DRAFT                   Sieve                    March 29, 1999


2.10.5.  Extensions and Optional Features

   Because of the differing capabilities of many mail systems, several
   features of this specification have been specified as optional.
   Before any of these extensions can be used, they must be declared
   with the "require" action.

   If an extension is not enabled with "require", implementations MUST
   treat it as if they did not support it at all.

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

   Note: The reason for this restriction is that prior experiences with
         languages such as LISP and Tcl suggest that this is a workable
         way of noting that a given script uses an extension.

         Experience with PostScript suggests that mechanisms that allow
         a script to work around missing extensions are not used in
         practice.

2.10.6.  Errors

   In any programming language, there are compile-time and run-time
   errors.

   Compile-time errors are ones in syntax that are detectable if a
   syntax check is done.

   Run-time errors are not detectable until the script is run.  This
   includes disk full conditions, but also includes issues like invalid
   combinations of actions, for instance, reject + fileinto.

   When an error occurs in a Sieve script, all processing stops.

   Implementations MAY choose to do a full parse, then evaluate the
   script, then do all actions.  Implementations might even go so far as
   to ensure that actions are atomic, and either all actions happen or
   none of them do, like a database might.

   Other implementatons may choose to parse and run at the same time.
   Such implementations are simpler, but have issues with partial
   failure (some actions happen, others don't).

   Perhaps implementations might even go so far as to ensure that
   scripts can never execute an invalid set of actions (e.g., reject +
   fileinto), although this could involve solving the Halting Problem.




Showalter                 Expire in Six Months                 [Page 22]

Internet DRAFT                   Sieve                    March 29, 1999


   This specification allows any of these approaches.

   When an error happens, implementations MUST notify the user that an
   error occurred, which actions (if any) were taken, and do an implicit
   keep.

3.      Control Commands

   In order for a script to do more than one set of actions, control
   structures are needed.

3.1.    If

   There are three pieces to if: "if", "elsif", and "else".  Each is
   actually a seperate command in terms of the grammar.  However, an
   elsif MUST follow an if, and an else MUST follow either an if or an
   elsif, or an error occurs.

   Syntax:   if <test1: test> <block1: block>

   Syntax:   elsif <test2: test> <block2: block>

   Syntax:   else <block>

   The semantics are similar to any other programming language this
   appears in.  When the interpreter sees an "if", it evaluates the test
   associated with it.  If the test is true, it executes the block
   associated with it.

   If the test of the "if" is false, it evaluates the test of the first
   "elsif" (if any).  If the test of "elsif" is true, it runs the
   elsif's block.  An elsif may be followed by an elsif, in which case,
   the interpreter repeats this process until it runs out of elsifs.

   When the interpreter runs out of elsifs, there may be an "else" case.
   If there is, and none of the if or elsif tests were true, the
   interpreter runs the else case.

   This provides a way of performing exactly one of the blocks in the
   chain.











Showalter                 Expire in Six Months                 [Page 23]

Internet DRAFT                   Sieve                    March 29, 1999


   In the following example, both Message A and B are dropped.

   Example:  require "fileinto";
             if header :contains "from" "coyote" {
                discard;
             } elsif header :contains ["subject"] ["$$$"] {
                discard;
             } else {
                fileinto "INBOX";
             }


   In the script below, when run over message A, redirects  the  message
   to  [e-mail];  message  B,  to [e-mail]; any
   other message is redirected to [e-mail].

   Example:  if header :contains ["From"] ["coyote"] {
                redirect "[e-mail]";
             } elsif header :contains "Subject" "$$$" {
                redirect "[e-mail]";
             } else {
                redirect "[e-mail]";
             }

   Note that this definition prohibits the "... else if ..." sequence
   used by C.  This is intentional, because this construct produces a
   shift-reduce conflict.

3.2.     Control Structure 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.5.  Multiple capabilities can be declared
   with a single require.

   The require command, if present, must be used before anything other
   than a require can be used.  An error occurs if a require occurs
   after something else.

   Example:  require ["fileinto", "reject"];


3.3.     Control Structure Stop

   Syntax:   stop




Showalter                 Expire in Six Months                 [Page 24]

Internet DRAFT                   Sieve                    March 29, 1999


   The "stop" action ends all processing.  If no actions have been
   executed, then the keep action is taken.

4.      Action Commands

   This document supplies five actions that may be taken on a message:
   keep, fileinto, redirect, reject, and discard.

4.1.     Action reject

   Syntax:   reject <reason: string>

   The optional "reject" action resends the message to the sender,
   wrapping it in a "reject" form, noting that it was rejected by the
   recipient.  In the following script, message A is rejected and
   returned to the sender.

   Example:  require "reject";
             if header :contains "from" "[e-mail]" {
                reject "I am not taking mail from you, and I don't want
                your birdseed, either!";
             }

   A reject message MUST take the form of a failure DSN as specified  by
   [DSN].    The  human-readable  portion  of  the  message,  the  first
   component of the DSN, contains the human readable message  describing
   the  error,  although  it SHOULD contain additional text alerting the
   original sender that mail was refused by a filter.  This part of  the
   DSN might appear as follows:

   ------------------------------------------------------------
   Message was refused by recipient's mail filtering program.
   Reason given was as follows:

   I am not taking mail from you, and I don't want your
   birdseed, either!
   ------------------------------------------------------------

   The action-value field as defined in the DSN specification MUST be
   "failed".

   A rejected message may not be filed, redirected, or kept.

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





Showalter                 Expire in Six Months                 [Page 25]

Internet DRAFT                   Sieve                    March 29, 1999


4.2.     Action fileinto

   Syntax:   fileinto <folder: string>

   The "fileinto" action delivers the message into the specified folder.
   Implementations SHOULD support fileinto, but in some environments
   this may be impossible.

   The capability string for use with the require command is "fileinto".

   In the following script, message A is filed into folder
   "INBOX.harassment".

   Example:  require "fileinto";
             if header :contains ["from"] "coyote" {
                fileinto "INBOX.harassment";
             }

4.3.     Action redirect

   Syntax:   redirect <address: string>

   The "redirect" action is used to send the message to another user at
   a supplied address, as a mail forwarding feature does.  The
   "redirect" action makes no changes to the message body or headers,
   and only modifies the envelope recipient.

   The redirect command performs an MTA-style "forward"--that is, what
   you get from a .forward file using sendmail under UNIX.  The address
   on the SMTP envelope is replaced with the one on the redirect command
   and the message is sent back out.  (This is not an MUA-style forward,
   which creates a new message with a different sender and message ID,
   wrapping the old message in a new one.)

   A simple script can be used for redirecting:

   Example:  redirect "[e-mail]";


   Implementations SHOULD take measures to implement loop control,
   possibly including adding headers to the message or counting received
   headers.  If an implementation detects a loop, it causes an error.

4.4.     Action keep

   Syntax:   keep

   The "keep" action is whatever action is taken in lieu of all other



Showalter                 Expire in Six Months                 [Page 26]

Internet DRAFT                   Sieve                    March 29, 1999


   actions, if no filtering happens at all; generally, this simply means
   to file the message into the user's main mailbox.  This command
   provides a way to execute this action without needing to know the
   name of the user's main mailbox, providing a way to call it without
   needing to understand the user's setup, or the underlying mail
   system.

   Example:  if size :under 1M { keep; } else { discard; }

4.5.     Action discard

   Syntax:   discard

   Discard is used to silently throw away the message.  It does so by
   simply cancelling the implicit keep.  If discard is used with other
   actions, the other actions still happen.  Discard is compatible with
   all other actions.  (For instance fileinto+discard is equivalent to
   fileinto.)  Discard is the only action that can be used with reject.

   Discard MUST be silent; that is, it MUST NOT return a non-delivery
   notification of any kind.

   In the following script, any mail from "[e-mail]" is
   thrown out.

   Example:  if header :contains ["from"] ["[e-mail]"] {
                discard;
             }


   While an important part of this language, "discard" has the potential
   to create serious problems for users: a student leaving themselves
   logged in to a machine in a computer lab may find their script
   changed to just "discard".  In order to protect users in this
   situation (along with similar situations), implementations MAY keep
   messages destroyed by a script for an indefinite period, and MAY
   disallow scripts that throw out all mail.

5.      Test Commands

   Tests are used in conditionals to decide which part(s) of the
   conditional to execute.

5.1.     Test address

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




Showalter                 Expire in Six Months                 [Page 27]

Internet DRAFT                   Sieve                    March 29, 1999


   The address test matches Internet addresses out of structured headers
   that contain addresses.  It returns true if any header contains any
   key in the specified part of the address, as modified by the
   comparator and the match keyword.

   Like envelope and header, this test returns true if any combination
   of the header-list and key-list arguments match.

   Internet email addresses [IMAIL] have the somewhat awkward
   characteristic that the mailbox-part to the left of the at-sign is
   considered case sensitive, and the domain-part to the right of the
   at-sign is case insensitive.  The "address" command does not deal
   with this itself, but provides the ADDRESS-PART argument for allowing
   users to deal with it.

   The address primitive never acts on the phrase part of an email
   address, nor on comments within that address.  It also never acts on
   group names, although it does act on the addresses within the group
   construct.

   Implementations MUST restrict the address test to headers that
   contain addresses, but MUST include at least From, To, Cc, Bcc,
   Sender, Resent-From, Resent-To, and SHOULD include any other header
   that utilizes an "address-list" structured header body.


   Example:  if address :is :all "from" "[e-mail]" {
                discard;

5.2.     Test allof

   Syntax:   allof <tests: test-list>

   The allof test preforms a logical AND on the tests supplied to it.

   Example:  allof (false, false)  =>   false
             allof (false, true)   =>   false
             allof (true,  true)   =>   true

   The allof test takes as its argument a test-list.











Showalter                 Expire in Six Months                 [Page 28]

Internet DRAFT                   Sieve                    March 29, 1999


5.3.     Test anyof

   Syntax:   anyof <tests: test-list>

   The anyof test preforms a logical OR on the tests supplied to it.

   Example:  anyof (false, false)  =>   false
             anyof (false, true)   =>   true
             anyof (true,  true)   =>   true

5.4.     Test envelope

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


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

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

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

   The envelope-part is a string list and may contain both "from" and
   "to", in which case the strings specified in the key-list are matched
   against both parts of the envelope.

   Like address and header, this test returns true if any combination of
   the envelope-part and key-list arguments is true.

   All tests against envelopes MUST drop source routes.

   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:  require "envelope";
             if envelope :all :is "from" "[e-mail]" {
                discard;
             }




Showalter                 Expire in Six Months                 [Page 29]

Internet DRAFT                   Sieve                    March 29, 1999


5.5.     Test exists

   Syntax:   exists <header-names: string-list>

   The "exists" test is true if the headers listed in the header-names
   argument exist within the message.  All of the headers must exist or
   the test is false.

   The following example throws out mail that doesn't have a From header
   and a Date header.

   Example:  if not exists ["From","Date"] {
                discard;
             }

5.6.     Test false

   Syntax:   false

   The "false" test always evaluates to false.
5.7.     Test header

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

   The "header" test evaluates to true if the any header name matches
   any key.  The type of match is specified by the optional match
   argument, which defaults to ":is" if not specified, as specified in
   section 2.6.

   Like address and envelope, this test returns true if any combination
   of the string-list and key-list arguments match.

   If a header listed in the header-names argument exists,  it  contains
   the  null  key ("").  However, if the named header is not present, it
   does not contain the null key. So if a message contained the header

           X-Caffeine: C8H10N4O2

   these tests on that header evaluate as follows:

           header :is ["X-Caffeine"] [""]         => false
           header :contains ["X-Caffeine"] [""]   => true

5.8.     Test not

   Syntax:   not <test>




Showalter                 Expire in Six Months                 [Page 30]

Internet DRAFT                   Sieve                    March 29, 1999


   The "not" test takes some other test as an argument, and yields the
   opposite result.

5.9.     Test size

   Syntax:   size <":over" / ":under"> <limit: number>

   The "size" test deals with the size of a message.  It takes either a
   tagged argument of ":over" or ":under", followed by a number
   representing the size of the message.

   If the argument is ":over", and the size of the message is greater
   than the number provided, the test is true; otherwise, it is false.

   If the argument is ":under", and the size of the message is less than
   the number provided, the test is true; otherwise, it is false.

   One of ":over" or ":under" must be specified.

   The size of a message is defined to be the number of octets from the
   initial header until the last character in the message body.

5.10.    Test true

   Syntax:   true

   The "true" test always evaluates to true.

6.      Extensibility

   New control structures, actions, and tests can be added to the
   language.  Sites must make these features known to their users; this
   document does not define a way to discover the list of extensions
   supported by the server.

   Any extensions to this language MUST define a capability string that
   uniquely identifies that extension.  If a new version of an extension
   changes the functionality of a previously defined extension, it MUST
   use a different name.

   In a situation where there is a submission protocol and an extension
   advertisement mechanism aware of the details of this language,
   scripts submitted can be checked against the mail server to prevent
   use of an extension that the server does not support.

   Extensions MUST state how they interact with constraints defined in
   section 2.10, e.g., whether they cancel the implicit keep, and which
   actions they are compatible and incompatible with.



Showalter                 Expire in Six Months                 [Page 31]

Internet DRAFT                   Sieve                    March 29, 1999


6.1.     Capability String

   Capability strings are typically short strings describing what
   capabilities are supported by the server.

   Capability strings beginning with "vnd." represent vendor-defined
   extensions.  Such extensions are not defined by Internet standards or
   RFCs, but are still registered with IANA in order to prevent
   conflicts.  Extensions starting with "vnd." SHOULD be followed by the
   name of the vendor and product, such as "vnd.acme.rocket-sled".

   The following capability strings are defined by this document:

   envelope    The string "envelope" indicates that the implementation
               supports the "envelope" command.

   fileinto    The string "fileinto" indicates that the implementation
               supports the "fileinto" command.

   reject      The string "reject" indicates that the implementation
               supports the "reject" command.

   comparator- The string "comparator-elbonia" is provided if the
               implementation supports the "elbonia" comparator.
               Therefore, all implementations have at least the
               "comparator-i;octet" and "comparator-i;ascii-casemap"
               capabilities.

6.2.     IANA Considerations

   In order to provide a standard set of extensions, a registry is
   provided by IANA.  Capability names may be registered on a first-
   come, first-served basis.  Extensions designed for interoperable use
   SHOULD be defined as standards track or IESG approved experimental
   RFCs.

   To: [e-mail]
   Subject: Registration of new Sieve extension

   Capability name:
   Capability keyword:
   Capability arguments:
   Standards Track/IESG-approved experimental RFC number:
   Person and email address to contact for further information:







Showalter                 Expire in Six Months                 [Page 32]

Internet DRAFT                   Sieve                    March 29, 1999


6.3.     Capability Transport

   As the range of mail systems that this draft is intended to apply to
   is quite large, a method of advertising which capabilities an
   implementation supports is difficult due to the wide range of
   possible implementations.  Such a mechanism, however, should have the
   following properties.

   (1)  The implementation can advertise the complete set of extensions
        that it supports.


7.      Transmission

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

   The registration of this type for RFC 2048 requirements is as
   follows:

        Subject: Registration of MIME media type application/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 is 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 [e-mail].
        Intended usage:
           COMMON
        Author/Change controller:
           See Author information in RFC XXXX.







Showalter                 Expire in Six Months                 [Page 33]

Internet DRAFT                   Sieve                    March 29, 1999


8.      Parsing

   The Sieve grammar is seperated into tokens and a seperate grammar as
   most programming languages are.

8.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:
           - identifiers
           - tags
           - numbers
           - quoted strings
           - multi-line strings
           - other separators

   Blanks, horizonal tabs, newlines, formfeeds, and comments ("white
   space") are ignored except as they separate tokens.  Some white space
   is required to separate otherwise adjacent tokens and in specific
   places in the multi-line strings.

   The other separators are single individual characters, and are
   mentioned explicitly in the grammar.

   The lexical structure of sieve is defined in the following BNF (as
   described in [ABNF]):

   CHAR-NOT-DOT = (%x01-2d / %x2f-%xff)

   CHAR-NOT-CRLF = (%x01-09 / %x0b-%x0c / %x0e-%xff)

   comment = "#" *CHAR-NOT-CRLF CRLF

   identifier = (ALPHA / "_") *(ALPHA DIGIT "_")

   tag = ":" identifier

   number = 1*DIGIT [QUANTIFIER]

   QUANTIFIER = "K" / "M" / "G"

   quoted-string = DQUOTE *CHAR DQUOTE
           ;; in general,  CHAR inside a string maps to CHAR
           ;; so
           ;; note that newlines and other characters are all allowed strings




Showalter                 Expire in Six Months                 [Page 34]

Internet DRAFT                   Sieve                    March 29, 1999


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

   white-space = 1*(SP / CRLF / HTAB) / comment

8.2.     Grammar

   The following is the grammar of Sieve after it has been lexical
   interpreted.  No white space or comments appear below.  The start
   symbol is "start".

   argument = string-list / number / tag

   arguments = *argument [test / test-list]

   block = "{" commands "}"

   command = identifier arguments ( ";" / block )

   commands = *command

   start = commands

   string = quoted-string / multi-line

   string-list = "[" string *("," string) "]" / string         ;; if
   there is only a single string, the brackets are optional

   test = identifier arguments

   test-list = "(" test *("," test) ")"

9.      Extended Example

   The following is an extended example of a Sieve script.  Note that it
   does not make use of the implicit keep.

   #
   # Example Sieve Filter
   # Declare any optional features or extension used by the script
   #
   require ["fileinto", "reject"];





Showalter                 Expire in Six Months                 [Page 35]

Internet DRAFT                   Sieve                    March 29, 1999


   #
   # Reject any large messages
   #
   if size :over 1M
           {
           reject text:
   Please do not send me large attachments.
   Put your file on a server and send me the URL.
   Thank you.
   .
   ;
           stop;
           }

   #
   # Handle messages from known mailing lists
   # Move messages from IETF filter discussion list to filter folder
   #
   if header :is "Sender" "[e-mail]"
           {
           fileinto "filter";  # move to "filter" folder
           }
   #
   # Keep all messages to or from people in my company
   #
   elsif anyof address :domain :is ["From", "To"] "company.com"
           {
           keep;               # keep in "In" folder
           }
   #
   # Try and catch unsolicited email.  If a message is not to me,
   # or it contains a subject known to be spam, file it away.
   #
   elsif anyof (not address :all :contains
                  ["To", "Cc", "Bcc"] "[e-mail]",
                header :matches "subject"
                  ["*make*money*fast*", "*university*dipl*mas*"])
           {
           # If message header does not contain my address,
           # it's from a list.
           fileinto "spam";   # move to "spam" folder
           }
   else
           {
           # Move all other (non-company) mail to "personal"
           # folder.
           fileinto "personal";
           }



Showalter                 Expire in Six Months                 [Page 36]

Internet DRAFT                   Sieve                    March 29, 1999


10.     Security Considerations

   Users must get their mail.  It is imperative that whatever method
   implementations use to store the user-defined filtering scripts be
   secure.

   It is equally important that implementations sanity-check the user's
   scripts, and not allow users to create on-demand mailbombs.  For
   instance, an implementation that allows a user to reject or redirect
   multiple times to a single message might also allow a user to create
   a mailbomb triggered by mail from a specific user.


   Several commands, such as "discard", "redirect", and "fileinto" allow
   for actions to be taken that are potentially very dangerous.

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

11.     Acknowledgments

   I am very thankful to Chris Newman for his support and his ABNF
   syntax checker, to John Myers and Steve Hole for outlining the
   requirements for the original drafts, to Larry Greenfield for nagging
   me about the grammar and finally fixing it, to Greg Sereda for
   repeatedly fixing and providing examples, and to Rob Earhart for an
   early implementation and a great deal of help.  I am also indebted to
   all of the readers of the [e-mail] mailing list.

12.     Author's Address

   Tim Showalter
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   E-Mail: [e-mail]














Showalter                 Expire in Six Months                 [Page 37]

Internet DRAFT                   Sieve                    March 29, 1999


Appendix A.  References

   [ABNF] Crocker,  D.,  and  P.  Overell,  "Augmented  BNF  for  Syntax
   Specifications:   ABNF", Internet Mail Consortium, RFC 2234, November
   1997.

   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format  for
   Delivery Status Notifications", RFC 1894, January 1996.

   [FLAMES] Borenstein, N, and C. Thyberg,  "Power,  Ease  of  Use,  and
   Cooperative  Work  in a Practical Multimedia Message System", Int. J.
   of Man-Machine Studies, April, 1991.  Reprinted in Computer-Supported
   Cooperative  Work  and  Groupware,  Saul  Greenberg, editor, Harcourt
   Brace Jovanovich, 1991.   Reprinted  in  Readings  in  Groupware  and
   Computer-Supported  Cooperative  Work, Ronald Baecker, editor, Morgan
   Kaufmann, 1993.

   [KEYWORDS] Bradner, S., "Key  words  for  use  in  RFCs  to  Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997.

   [IMAP] Crispin, M.,  "Internet  Message  Access  Protocol  -  version
   4rev1", RFC 2060, University of Washington, December 1996.

   [IMAIL] Crocker, D., "Standard for the Format of ARPA  Internet  Text
   Messages", STD 11, RFC 822, University of Delaware, August 1982.

   [MIME] Freed, N., and  N.  Borenstein,  "Multipurpose  Internet  Mail
   Extensions  (MIME)  Part One: Format of Internet Message Bodies", RFC
   2045, Innosoft and First Virtual, November 1996.

   [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC  821,
   USC/Information Sciences Institute, August 1982.

   [UTF-8] Yergeau, F. "UTF-8, a transformation format  of  Unicode  and
   ISO 10646", RFC 2044, Alis Technologies, October 1996.
















Showalter                 Expire in Six Months                 [Page 38]

Internet DRAFT                   Sieve                    March 29, 1999


Appendix B.  Full Copyright Statement

   Copyright (C) The Internet Society 1999. All Rights Reserved.

   This document and translations of it may be copied and  furnished  to
   others,  and derivative works that comment on or otherwise explain it
   or assist in its implementation may be  prepared,  copied,  published
   and  distributed,  in  whole  or  in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included  on  all  such  copies  and derivative works.  However, this
   document itself may not be modified in any way, such as  by  removing
   the  copyright  notice or references to the Internet Society or other
   Internet  organizations,  except  as  needed  for  the   purpose   of
   developing  Internet  standards  in  which  case  the  procedures for
   copyrights  defined  in  the  Internet  Standards  process  must   be
   followed,  or  as  required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will  not  be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on  an
   "AS  IS"  basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS  OR  IMPLIED,  INCLUDING
   BUT  NOT  LIMITED  TO  ANY  WARRANTY  THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS  OR  ANY  IMPLIED  WARRANTIES  OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Showalter                 Expire in Six Months                 [Page 39]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20432 for ietf-mta-filters-bks; Fri, 26 Mar 1999 13:39:25 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20428 for <[e-mail]>; Fri, 26 Mar 1999 13:39:23 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA02095; Fri, 26 Mar 1999 16:46:44 -0500 (EST)
Date: 26 Mar 1999 16:47:04 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: Ft. Meade smuggle Treasury assassination World Trade Center plutonium explosion
To: [e-mail]
Subject: errors language for your approval
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am adding the following text on errors to the draft.  Feedback is
appreciated.

--==--
In any programming language, there are compile-time and run-time errors.

Compile-time errors are ones in syntax that are detectable if a syntax check
is done.

Run-time errors are not detectable until the script is run.  This includes
disk full conditions, but also includes issues like invalid combinations of
actions, for instance, reject + fileinto.

When an error occurs in a Sieve script, all processing stops.

Implementations MAY choose to do a full parse, then evaluate the script, then
do all actions.  Implementations might even go so far as to ensure that
actions are atomic, and either all actions happen or none of them do, like a
database might.

Other implementatons may choose to parse and run at the same time.  Such
implementations are simpler, but have issues with partial failure (some
actions happen, others don't).

Perhaps implementations might even go so far as to ensure that scripts can
never execute an invalid set of actions (e.g., reject + fileinto), although
this could involve solving the Halting Problem.

This specification allows any of these approaches.

When an error happens, implementations MUST notify the user that an error
occurred, which actions (if any) were taken, and do an implicit keep.

--==--

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA20202 for ietf-mta-filters-bks; Fri, 26 Mar 1999 13:12:35 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20198 for <[e-mail]>; Fri, 26 Mar 1999 13:12:34 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA00085; Fri, 26 Mar 1999 16:19:54 -0500 (EST)
Date: 26 Mar 1999 16:20:15 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: cryptographic munitions [Hello to all my fans in domestic surveillance] spy White Water North Korea FBI
To: [e-mail]
Subject: reject can take a MIME part?
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Do we want reject to be able to take a MIME part?  (That appears to be
the implication from Barry's notes, but somehow I was thinking that was
just a vacation thing.)

Is this a good thing?

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA19986 for ietf-mta-filters-bks; Fri, 26 Mar 1999 12:46:47 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA19982 for <[e-mail]>; Fri, 26 Mar 1999 12:46:45 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA28556; Fri, 26 Mar 1999 15:54:05 -0500 (EST)
Date: 26 Mar 1999 15:54:25 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: Serbian Uzi bomb Treasury colonel Bosnia DES
To: [e-mail]
Subject: sieve vacation draft
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: multipart/mixed; boundary="Multipart_Fri_Mar_26_15:54:25_1999-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Multipart_Fri_Mar_26_15:54:25_1999-1
Content-Type: text/plain; charset=US-ASCII

This is a Sieve vacation draft.  I would like to get the nits out of it
before submitting it as an Internet-Draft, which I am likely to do early 
next week.

Thanks.

Tim

-- 
Tim Showalter <[e-mail]>

--Multipart_Fri_Mar_26_15:54:25_1999-1
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: attachment; filename="sieve-vacation.txt"
Content-Transfer-Encoding: 7bit







Network Working Group                                       T. Showalter
Internet Draft: Sieve: Vacation Extension                Carnegie Mellon
Document: draft-showalter-sieve-vacation-01.txt           March 26, 1999
Expire in six months


                       Sieve: Vacation Extension


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or using this
   protocol are STRONGLY URGED to get in touch with the author before
   embarking on such a project.

Copyright

   Copyright (C) The Internet Society 1999.  All Rights Reserved.

Abstract

   This document describes an extension to the Sieve mail filtering
   language for an autoresponder similar to that of the Unix "vacation"
   command for replying to messages with certain safety features to
   prevent problems.






Showalter                 Expire in Six Months                  [Page 1]

Internet DRAFT         Sieve: Vacation Extension          March 26, 1999


0. Meta-information on this draft

   This information is intended to facilitate discussion.  It will be
   removed when this document leaves the Internet-Draft stage.

0.1. Discussion

   This draft is intended to be an extension to the Sieve mail filtering
   language, avaliable from the Internet-Drafts repository as
   <ftp://ftp.ietf.org/internet-drafts/draft-showalter-sieve-07.txt>
   (where 07 is the version number, which is actually currently 07).

   This draft and the Sieve language itself are being discussed on the
   MTA Filters mailing list at <[e-mail]>.  Subscription
   requests can be sent to <[e-mail]> (send an
   email message with the word "subscribe" in the body).  More
   information on the mailing list along with a WWW archive of back
   messages is available at <http://www.imc.org/ietf-mta-filters/>.

1. Introduction

   This is an extension to the Sieve language defined by [SIEVE] for
   notification that messages will not be immediately answered.

   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS].

2. Capability Identifier

   Sieve implementations that implement vacation have an identifier of
   "vacation" for use with the capability mechanism.

3. Vacation Action

   Syntax:   vacation [":days" number] [":addresses" string-list]
             [":subject" string] [":mime"] <reason: string>

   The "vacation" action implements a vacation autoresponder similar to
   the vacation command  available under many versions of Unix.  Its
   purpose is to provide correspondents with notification that the user
   is away for an extended period of time and that they should not
   expect quick responses.

   "Vacation" is used to respond to a message with another message.
   Vacation's messages are always addressed to the Return-Path address
   (that is, the envelope from address) of the message being responded
   to.




Showalter                 Expire in Six Months                  [Page 2]

Internet DRAFT         Sieve: Vacation Extension          March 26, 1999


3.1. Days Parameter

   The ":days" argument is used to specify the period in which addresses
   are kept and are not responded to, and is always specified in days.
   The minimum value used for this parameter is 1.  Sites MAY define a
   different minimum value.  Sites MAY also define a maximum days value,
   which MUST be greater than 7, and SHOULD be greater than 30.

   If ":days" is omitted, the default value is 7, or the minimum value
   (as defined above), whichever is greater.

   If the parameter given to ":days" is less than the minimum value,
   then the minimum value is used instead.

   If ":days" exceeds the site-defined maximum, the site-defined maximum
   is used instead.

3.2. Previous Response Tracking

   "Vacation" keeps track of all of the addresses that it has responded
   to in some period (as specified by the :days optional argument).  If
   vacation has not previously responded to this address within that
   time period, it sends the "reason" argument to the Return-Path
   address of the message that is being responded to.

   Vacation responses are not just per address, but are per address per
   vacation command.  For instance, If coyote@desert sends mail to
   roadrunner@acme, once with the subject "Cyrus bug" and once with the
   subject "come over for dinner", and roadrunner@acme has the script
   below, coyote@desert would receive two responses, once with the first
   message, once with the second.

   Example:  require "vacation";
             if subject :contains "cyrus" {
                        vacation "I'm out -- send mail to cyrus-bugs";
             } else {
                        vacation "I'm out -- call me at 304 555 1212";
             }


   Note that coyote@desert gets the second message despite having gotten
   the first one because separate vacation responses have been
   triggered.  This behavior is REQUIRED.

   If a sieve script changes, implementations MAY reset the records of
   who has been responded to and when they have been responded to.
   Alternatively, scripts can store records of who has received which
   message, and never send a message to someone twice.



Showalter                 Expire in Six Months                  [Page 3]

Internet DRAFT         Sieve: Vacation Extension          March 26, 1999


3.3. Subject Parameter

   Users can specify the subject of the reply with the ":subject"
   parameter.  If the :subject parameter is not supplied, then the
   subject is generated as follows: The subject is set to the characters
   "Re: " followed by the original subject with all leading occurrence
   of the characters "Re: " stripped off.

3.4. MIME Parameter

   The ":mime" parameter, if supplied, specifies that the reason string
   is, in fact, a MIME part, including MIME headers.  This implies that
   the reason string is not necessarily UTF-8 string, that character set
   information is as per MIME, and that the part need not even be plain
   text.

   The purpose of this flag is to allow for parts to be other things
   than plain UTF-8 text.

   If the optional :mime parameter is not supplied, the reason string is
   considered to be a UTF-8 string.

3.5. In-Reply-To

   Replies must have the In-Reply-To field set to the Message-ID of the
   original message.

3.6. Address Parameter and Limiting Replies to Personal Messages

   "Vacation" never responds to a message unless the user's email
   address is in the "To" or "Cc" line of the original message.
   Implementations are assumed to know the user's email address, but
   users may have additional addresses beyond the control of the local
   mail system.

   Users can supply additional mail addresses that are theirs with the
   ":addresses" argument, which takes a string-list listing additional
   addresses that a user might have.  These addresses are considered in
   addition to the addresses that the implementation knows.

3.7. Restricting Replies to Automated Processes

   Implementations MUST have a list of addresses that "vacation" MUST
   NOT send mail to.  However, the contents of this list are
   implementation defined.  The purpose of this list is to stop mail
   from going to addresses used by system daemons that would not care if
   the user is actually reading her mail.




Showalter                 Expire in Six Months                  [Page 4]

Internet DRAFT         Sieve: Vacation Extension          March 26, 1999


   Implementations are encouraged, however, to include well-known
   addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other
   addresses typically used only by automated systems.  Additionally,
   addresses ending in "-request" or beginning in "owner-", i.e.,
   reserved for mailing list software, are also suggested.

   Implementors may take guidance from [MAILBOXNAMES], but should be
   careful.  Some addresses, like "POSTMASTER", are generally actually
   managed by people, and people do care if the user is going to be
   unavailable.

3.8. Interaction with Other Sieve Actions

   Vacation does not affect the implicit keep.

   Vacation can only be used  once  per  script.   Implementations  MUST
   consider vacation used with itself an error.

   Implementations MUST consider vacation used with reject an error.

   Implementations MUST NOT consider vacation used with  discard,  keep,
   fileinto, or redirect an error.

3.9. Examples

   Here is a simple use of vacation.

   Example:  require "vacation";
             vacation :days 23
                :addresses ["[e-mail]", "[e-mail]"]
                "I'm away until October 19.
                If it's an emergency, call 911, I guess." ;

   By mingling vacation with other rules, users can  do  something  more
   selective.

   Example:  require "vacation";
             if header :contains "from" "[e-mail]" {
                redirect "[e-mail]";
             } else {
                vacation "Sorry, I'm away, I'll read your message
                   when I get around to it.";
             }

4. Security Considerations
   It is critical that implementations correctly implement the
   limitations described above.  Replies MUST NOT be sent out in
   response to messages not sent directly to the user, and replies MUST



Showalter                 Expire in Six Months                  [Page 5]

Internet DRAFT         Sieve: Vacation Extension          March 26, 1999


   NOT be sent out more often than the :days argument states.

5. Author's Address

   Tim Showalter
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   E-Mail: [e-mail]









































Showalter                 Expire in Six Months                  [Page 6]

Internet DRAFT         Sieve: Vacation Extension          March 26, 1999


Appendix A.  References

   [KEYWORDS] Bradner, S., "Key  words  for  use  in  RFCs  to  Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997.

   [MAILBOXNAMES] Crocker, D. "Mailbox Names for Common Services, Roles,
   and Functions", RFC 2142, Internet Mail Consortium, May, 1997.

   [MIME] Freed, N., and  N.  Borenstein,  "Multipurpose  Internet  Mail
   Extensions  (MIME)  Part One: Format of Internet Message Bodies", RFC
   2045, Innosoft and First Virtual, November 1996.

   [SIEVE] Showalter, T.,  "Sieve: A Mail Filtering Language",  Carnegie
   Mellon, Work in Progress.

Appendix B. Full Copyright Statement

   Copyright (C) The Internet Society 1999. All Rights Reserved.

   This document and translations of it may be copied and  furnished  to
   others,  and derivative works that comment on or otherwise explain it
   or assist in its implementation may be  prepared,  copied,  published
   and  distributed,  in  whole  or  in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included  on  all  such  copies  and derivative works.  However, this
   document itself may not be modified in any way, such as  by  removing
   the  copyright  notice or references to the Internet Society or other
   Internet  organizations,  except  as  needed  for  the   purpose   of
   developing  Internet  standards  in  which  case  the  procedures for
   copyrights  defined  in  the  Internet  Standards  process  must   be
   followed,  or  as  required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will  not  be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on  an
   "AS  IS"  basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS  OR  IMPLIED,  INCLUDING
   BUT  NOT  LIMITED  TO  ANY  WARRANTY  THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS  OR  ANY  IMPLIED  WARRANTIES  OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



This document will expire before 31 Oct 1999.





Showalter                 Expire in Six Months                  [Page 7]



--Multipart_Fri_Mar_26_15:54:25_1999-1--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA09168 for ietf-mta-filters-bks; Wed, 24 Mar 1999 19:53:45 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA09164 for <[e-mail]>; Wed, 24 Mar 1999 19:53:43 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id XAA21806 for <[e-mail]>; Wed, 24 Mar 1999 23:00:23 -0500 (EST)
Received: from att.com (<unknown.domain>[135.197.86.178](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990325040023un115466mee>; Thu, 25 Mar 1999 04:00:26 +0000
Message-ID: <[e-mail]>
Date: Wed, 24 Mar 1999 21:59:28 -0500
From: Tony Hansen <[e-mail]>
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Discard vs. DSN
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Gregory Sereda wrote:
> My preference would be stronger than SHOULD NOT but not quite
> MUST NOT.  I guess that means stating the discard SHOULD NOT
> generate a NDN.  Perhaps, with text stressing that the usefulness
> of discard is greatly disminished by implementations that generate
> a NDNs.  The developer should try very hard to implement discard
> correctly.
> 
> I think there is still value in a sieve implementation that
> cannot implement discard without a NDN, but users of the
> implementation would just have to live with its limitations.

If discard generates NDN, I think it's a broken implementation. My
feeling is that it should be a STRONG MUST NOT generate NDN.

	Tony Hansen
	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA19808 for ietf-mta-filters-bks; Wed, 24 Mar 1999 07:08:33 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA19802 for <[e-mail]>; Wed, 24 Mar 1999 07:08:32 -0800 (PST)
Received: from galileo.esys.ca (dhcp198-58.esys.ca [198.161.92.58]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id XAA01544; Wed, 24 Mar 1999 23:24:23 -0700
From: Steve Hole <[e-mail]>
Date: Wed, 24 Mar 1999 08:15:31 -0700
To: Tim Showalter <[e-mail]>
Subject: Re: Discard vs. DSN
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Execmail for Win32 Version 5.0 pc5 Build (37)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"; name="ipm.txt"
Content-Disposition: inline; filename="ipm.txt"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 23 Mar 1999 15:27:02 -0500 Tim Showalter <[e-mail]> wrote:

> Let me ask this: if discard sends a DSN, how is it meaningfully
> different from reject?  Reject seems to present a strict superset of
> discard functionality as you've described it (you get to tell the sender
> where to go in addition to refusing the message).
> 
> I'd like discard so, say, I can ignore certain people.  I don't want to
> reject their mail, I just want to ignore it.

This is very well said and I agree with it completely.   The functionality
difference seems both clear and useful to me.     Discard shouldn't be 
optional and it should silently throw away the message.

Cheers.

---  
Steve Hole                           
Execmail Inc.
Mailto:[e-mail] 
Phone: [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA19658 for ietf-mta-filters-bks; Wed, 24 Mar 1999 06:56:10 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA19654 for <[e-mail]>; Wed, 24 Mar 1999 06:56:09 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id KAA19088 for <[e-mail]>; Wed, 24 Mar 1999 10:02:49 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990324150301un115466rje>; Wed, 24 Mar 1999 15:03:01 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 24 Mar 1999 10:03:43 -0500
To: Randall Gellens <[e-mail]>, Pete Resnick <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: Discard vs. DSN
Cc: Randall Gellens <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 02:43 PM 3/23/99 -0800, Randall Gellens wrote:
>So which is it that I haven't implemented: 'discard' or 'reject'? 

I think you have implemented neither discard nor reject.  Some have
stated that a discard that generates a NDN is really reject.  But
while the reject action is optional, the reason text on the reject
action is not.  The user supplied reason must appear in the NDN,
or else it is not reject.  Otherwise, the sender will just see a
generic failure to deliver system error.

Greg Sereda


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14809 for ietf-mta-filters-bks; Tue, 23 Mar 1999 14:46:27 -0800 (PST)
Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14804 for <[e-mail]>; Tue, 23 Mar 1999 14:46:24 -0800 (PST)
Received: from 129.46.158.108 (randy-mac.qualcomm.com [129.46.158.108]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA25828; Tue, 23 Mar 1999 14:52:29 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v04204b0ab31dc792eecd@129.46.158.108>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Tue, 23 Mar 1999 14:43:46 -0800
To: Pete Resnick <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Discard vs. DSN
Cc: Randall Gellens <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b11
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:56 PM -0600 3/23/99, Pete Resnick wrote:

>>The problem arises if an implementation cannot implement discard 
>>without generating a NDN.
>
>Then it hasn't implemented discard; it has implemented reject. As 
>far as my reading of the draft goes, reject = discard + DSN and 
>discard =
>fileinto "/dev/null". The inability to implement discard without DSN 
>is a failure to implement properly.

I was reading 'reject' as delete & generate DSN with user-specified 
text.  If honoring the user-specified text is optional, then the only 
difference between 'reject' and 'discard' is indeed that 'discard' 
does not generate a DSN.

>Randy, maybe you can explain why your implementation can't implement 
>either reject - DSN or fileinto "/dev/null". I would like to prevent 
>DSNs with discards at all costs.

I didn't say my implementation couldn't.  I said in one environment 
in which my implementation runs this is difficult.  In this 
particular environment, my Sieve implementation operates as a 
delivery-time plug-in.  If the plug-in tells the mail system not to 
deliver the message, it generates a standard DSN.  This means I can't 
add the user-supplied text to the DSN, or avoid the DSN generation 
(unless the script causes delivery into a server 'trash' mailbox, 
which is what I do in my own personal script, which filters all my 
mail).

So which is it that I haven't implemented: 'discard' or 'reject'?  I 
was assuming I had implemented 'discard' and not 'reject', but 
perhaps it is the other way around.

If the consensus is  that this particular implementation and 
environment combination just isn't Sieve compliant, I can live with 
that.  I don't know how common or uncommon the constraints of this 
environment are.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14704 for ietf-mta-filters-bks; Tue, 23 Mar 1999 14:36:16 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14700 for <[e-mail]>; Tue, 23 Mar 1999 14:36:14 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id RAA01780 for <[e-mail]>; Tue, 23 Mar 1999 17:42:52 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990323224305un115466c1e>; Tue, 23 Mar 1999 22:43:05 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 23 Mar 1999 17:43:35 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: Discard vs. DSN
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 04:52 PM 3/23/99 -0500, Tim Showalter wrote:
>I would rather have discard be optional than this.  If discard is
>equivalent to reject, it is not discard anymore.  Having two meanings
>for discard is as bad as two meanings for fileinto.

I agree with Matt Wall, discard must be required.  Since reject
is optional, we might see a sieve implementation that supports
neither discard nor reject, unless we state that at least one
of them must be supported.  Making discard optional also creates
havoc with seive script compatibility.  I think we want discard
to mean "do your best to get rid of this message".

Making the user change their seive scripts from "discard" to "reject"
does not help the user at all, they still don't have discard.  Though,
it might make the language purists feel better.

Perhaps, we are trying too hard to cut this supposed "plug-in"
implememtation some slack.  We all seem to agree that it is
very important that a discard does not generate a NDN.  Lets
make it: discard is required and MUST NOT generate a NDN.

This puts the onus on the developer of the "plug-in" to
explain to their users why their sieve implementation is
not quite sieve.

Greg Sereda


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14335 for ietf-mta-filters-bks; Tue, 23 Mar 1999 14:03:38 -0800 (PST)
Received: from playground.sun.com (playground.Sun.COM [192.9.5.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14331 for <[e-mail]>; Tue, 23 Mar 1999 14:03:37 -0800 (PST)
Received: from opal.eng.sun.com (sun-barr.Sun.COM [192.9.9.1]) by playground.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16694; Tue, 23 Mar 1999 14:10:44 -0800 (PST)
Received: from clavinova.eng.sun.com (clavinova.Eng.Sun.COM [129.146.84.240]) by opal.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA82385; Tue, 23 Mar 1999 14:10:43 -0800 (PST)
Received: from clavinova.eng.sun.com (clavinova.eng.sun.com [129.146.84.240]) by clavinova.eng.sun.com (8.8.4/951213.2) with SMTP id OAA05879; Tue, 23 Mar 1999 14:10:37 -0800 (PST)
Date: Tue, 23 Mar 1999 14:10:36 -0800 (PST)
From: "Carl S. Gutekunst" <[e-mail]>
Reply-To: "Carl S. Gutekunst" <[e-mail]>
Subject: Re: Discard vs. DSN
To: Pete Resnick <[e-mail]>
Cc: [e-mail]
In-Reply-To: "Your message with ID" <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >The problem arises if an implementation cannot implement discard 
> >without generating a NDN.
> 
> Then it hasn't implemented discard; it has implemented reject.

I agree emphatically; thanks for the consise statement.

We seem to be stuck between the following two mutually exclusive positions:

1) Discard is a vital service, and MUST be supported even if it cannot be
   supported correctly.

	or:

2) A Discard MUST NOT generate a DSN; if the implementation has no way to
   silently dispose of a message, than it does not support Discard.

I'm voting for #2. To me it makes no sense for the semantics of discard to
vary in different implementations, no matter how well documented. If I try to
give a SIEVE script to an implementation that always generates a DSN, I *want*
'discard' to return a syntax error.

<csg>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14218 for ietf-mta-filters-bks; Tue, 23 Mar 1999 13:49:56 -0800 (PST)
Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14214 for <[e-mail]>; Tue, 23 Mar 1999 13:49:53 -0800 (PST)
Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 2.2); Tue, 23 Mar 1999 15:56:45 -0600
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: [e-mail]
Message-Id: <[e-mail]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
X-Mailer: Eudora [Macintosh version 4.2b74-4.99]
Date: Tue, 23 Mar 1999 15:56:40 -0600
To: [e-mail]
From: Pete Resnick <[e-mail]>
Subject: Re: Discard vs. DSN
Cc: Randall Gellens <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 3/23/99 at 4:09 PM -0500, Gregory Sereda wrote:

>I agree that discard MUST NOT generate a NDN.

So do I. I think more strongly than other people.

>The problem arises if an implementation cannot implement discard 
>without generating a NDN.

Then it hasn't implemented discard; it has implemented reject. As far 
as my reading of the draft goes, reject = discard + DSN and discard = 
fileinto "/dev/null". The inability to implement discard without DSN 
is a failure to implement properly.

Randy, maybe you can explain why your implementation can't implement 
either reject - DSN or fileinto "/dev/null". I would like to prevent 
DSNs with discards at all costs.

pr
-- 
Pete Resnick <mailto:[e-mail]>
Eudora Engineering - QUALCOMM Incorporated
Ph: [phone] or [phone], Fax: [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14162 for ietf-mta-filters-bks; Tue, 23 Mar 1999 13:45:01 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14154 for <[e-mail]>; Tue, 23 Mar 1999 13:45:00 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA01938; Tue, 23 Mar 1999 16:52:05 -0500 (EST)
Date: 23 Mar 1999 16:52:12 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: Kennedy SEAL Team 6 militia Qaddafi White Water strategic Mena
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Discard vs. DSN
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Tue, 23 Mar 1999 16:09:57 -0500
> From: Gregory Sereda <[e-mail]>

> My preference would be stronger than SHOULD NOT but not quite
> MUST NOT.  I guess that means stating the discard SHOULD NOT
> generate a NDN.  Perhaps, with text stressing that the usefulness
> of discard is greatly disminished by implementations that generate
> a NDNs.  The developer should try very hard to implement discard
> correctly.

Perhaps we need to consider adding REALLY to the KEYWORDS document
(REALLY REALLY SHOULD NOT).

Wonder if that can be written up for next Thursday...

> I think there is still value in a sieve implementation that
> cannot implement discard without a NDN, but users of the
> implementation would just have to live with its limitations.

I would rather have discard be optional than this.  If discard is
equivalent to reject, it is not discard anymore.  Having two meanings
for discard is as bad as two meanings for fileinto.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA13993 for ietf-mta-filters-bks; Tue, 23 Mar 1999 13:29:36 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13989 for <[e-mail]>; Tue, 23 Mar 1999 13:29:35 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA01236; Tue, 23 Mar 1999 16:36:40 -0500 (EST)
Date: 23 Mar 1999 16:36:47 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: jihad Qaddafi Panama Serbian Rule Psix radar Albania
To: [e-mail]
Subject: vacation limitations
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So at the Sieve BOF meeting, we discussed the text that says, in effect, 
"don't reply to MAILER-DAEMON".  The requirement is that you have some
list of addresses that you never reply to, but that the list isn't
specific so that we can tweak it.

Here is my text as a change to vacation.  Note that [MAILBOXNAMES]
refers to RFC 2142.  Please excuse the nroff formatting.

.xx "4. Limitations on Addresses to be Replied To"

Implementations MUST restrict mail to certain well-known addresses that never
want vacation addresses.

replied to.  This list is expected to contain patterns of addresses that are
never to be replied to, even when the user is on the To or CC lines of the
message.  This list is implementation defined, but MAY include the
following.

.RS
.IP o 2
Common implementation-dependant mailbox names like "MAILER-DAEMON"
.IP o 2
Standard mailbox names as described in [MAILBOXNAMES]
.IP o 2
Mailing list addresses, also described in [MAILBOXNAMES] (i.e., those with
local-parts ending in "-request")
.RE

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA13914 for ietf-mta-filters-bks; Tue, 23 Mar 1999 13:23:40 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13910 for <[e-mail]>; Tue, 23 Mar 1999 13:23:39 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id QAA21700 for <[e-mail]>; Tue, 23 Mar 1999 16:30:38 -0500 (EST)
Date: Tue, 23 Mar 1999 16:33:31 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
Subject: Re: Discard vs. DSN
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tue, Mar 23, 1999 4:09 PM -0500 the entity known as Gregory Sereda
<[e-mail]> wrote:


>	 - Or say discard SHOULD NOT generate NDN?
> 
> My preference would be stronger than SHOULD NOT but not quite
> MUST NOT.  I guess that means stating the discard SHOULD NOT
> generate a NDN. 

To which Matthew Wall offers this response on Tue, 23 Mar 1999 16:27:56
-0500:

according to the logic of [KEYWORDS], this seems like the solomonic
compromise, short of splitting the baby in two. We'd probably want to add a
line or two in the document explaining the circumstances under which it
might be good to generate (as Greg suggests), with appropriately poisonous
adjectives to otherwise discourage it. 

But Discard must be mandatory; it's fundamentally useful.

I agree with the model, fwiw, of 'discard' as an automated delete button.

- mw 







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA13896 for ietf-mta-filters-bks; Tue, 23 Mar 1999 13:22:22 -0800 (PST)
Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13892 for <[e-mail]>; Tue, 23 Mar 1999 13:22:21 -0800 (PST)
Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.9.3/8.9.3) with ESMTP id QAA127294 for <[e-mail]>; Tue, 23 Mar 1999 16:29:27 -0500
Received: from aspen.watson.ibm.com (aspen.watson.ibm.com [9.2.3.31]) by mailhub.watson.ibm.com (8.8.7/Feb-20-98) with SMTP id QAA07602 for <[e-mail]>; Tue, 23 Mar 1999 16:29:27 -0500
Received: from mars.watson.ibm.com by aspen.watson.ibm.com (IBM OS/2 SENDMAIL VERSION 2.0/ISSC1.0) id QAA002.90; Tue, 23 Mar 1999 16:29:25 -0500
From: Barry Leiba <[e-mail]>
Date: Tue, 23 Mar 1999 16:29:25 -0500
To: [e-mail]
Subject: Draft notes from Sieve BOF
Message-ID: <[e-mail]>
X-Mailer: Execmail for Win32 Version 5.0 Build (41)
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"; name="ipm.txt"
Content-Disposition: inline; filename="ipm.txt"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here's a draft of my slightly edited notes from the Sieve BOF last week.  
Comments about what I missed or misrepresented are welcome; post 'em here.

Barry


Notes
-----------------------------------------------
Matt says to kick Ned's ass when they see him, because he's late.
Matt reviews mailing list addresses, etc.
Matt reviews agenda.
- Don't want working group.
- Have draft charter, just in case.
- Want to get consensus at end of BOF about WG.

Tim explains syntax briefly.
Tim reviews open issues.
- Vacation in base spec or extension?
  reason for base: it's important -- to some, the very reason for having Sieve
  reason for extension: it's a long section; it provides a prototype for
    writing extensions
  consensus: do it as an extension
- Action interaction
  e.g. reject vs. keep/fileinto
  Proposal:
    discard is compatible with everything -- just cancels the default keep
    reject is incompatible with all but discard
    keep == fileinto "inbox"
  Discussion:
    add to spec: extensions should discuss incompatible actions
    discussion about extensions having to refer to other extensions, easy
       to get out of hand.
    discuss on mailing list for resolution
- Site limits on actions (number of forward addresses, for instance)
  Proposal:
    multiple reject MUST NOT
    at least one fileinto/keep MUST
    at least one redirect MUST
  Discussion
    redirect: no, remove
    exceeding limit causes a script error
- Require must be at beginning of script
- User-specified charset on outgoing msg
  Discussion:
    text may be MIME object?
    OK... put in switch: text or MIME
- Text will be added talking about errors in script

Other Discussion:
- Discussion about adding headers in redirect
  Want to add loop detection and received headers
  What about resent headers?
    Some say it's not user-initiated.
    Some consider that it *is* user-initiated.
  Consensus... Eliminate text about not adding headers
- Discussion about discarding messages, what to do with DSNs
  Take to mailing list
  
- Vacation extension
  Proposal:
    Vacation incompatible with reject & vacation.
    Does not cancel implicit keep.
    Remembering who was responded to is not just per address, but per 
       address per vacation command.
    If script changes, implementations MAY reset response memory.
  
  Also:
    Add req't for impl dependent list of addresses that vacation never 
       replies to,  List MUST include POSTMASTER, SHOULD include others.
  Discussion:
    Remove specific addresses, replace with general advice, refer to RFCs.
    Request to be very explicit about this, to avoid loops & annoyances
       calendar in vacation?  -- out of scope
    
Matt:
Proposes getting revision out in 3 weeks, for IETF last call (4 weeks).
Includes base & vacation.  Call for WG... unanimous: no.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA13877 for ietf-mta-filters-bks; Tue, 23 Mar 1999 13:21:05 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13873 for <[e-mail]>; Tue, 23 Mar 1999 13:21:04 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id QAA10136 for <[e-mail]>; Tue, 23 Mar 1999 16:27:40 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990323212753un1154669ee>; Tue, 23 Mar 1999 21:27:53 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 23 Mar 1999 16:28:23 -0500
To: [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: vacation response tracking
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Filter list members,

I have heard the current thinking on vacation is to track the
response interval for each vacation action.  Thus, a person
may receive more than 1 vacation response in a given interval
if their messages were to cause different vacations actions
to be executed in a sieve script.

My understanding is that vacations actions would be considered
the same if they contained the same response string, even though
they may be different statements within the script.  It was suggested
that a hash code of the response string could be computed to reduce
the storage requirements.  The hash code was equal, the vacation
string and action are assumed to be the same.

This requirement increases the burden on the implementation, which
has to save the address and time of each vacation response, now
has to save also the hash code of the vacation text.

This is another trade off between MUST and SHOULD.  I would prefer
a statement like...

Sieve implementations SHOULD track vacation response times for
each vacation action based on the text string.  Vacation actions
with the same text are treated as the same.  Some implementations,
due to constraints, MAY treat all vacation actions, regardless of
the text, as the same.

Do we really want to make this MUST?

Greg Sereda


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA13677 for ietf-mta-filters-bks; Tue, 23 Mar 1999 13:02:40 -0800 (PST)
Received: from ckgppxy1.proxy.att.com (ckgppxy1.att.com [12.20.58.148]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA13673 for <[e-mail]>; Tue, 23 Mar 1999 13:02:39 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99]) by ckgppxy1.proxy.att.com (AT&T/IPNS/GW-1.0) with ESMTP id QAA20856 for <[e-mail]>; Tue, 23 Mar 1999 16:09:15 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990323210928un1154668se>; Tue, 23 Mar 1999 21:09:28 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 23 Mar 1999 16:09:57 -0500
To: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>
From: Gregory Sereda <[e-mail]>
Subject: Re: Discard vs. DSN
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:31 PM 3/23/99 -0800, Ned Freed wrote:
>Exactly right. In my experience being able to ignore messages is one of most
>commonly requested features, if not *the* most requested feature, for filters
>to be able to do. 
>
>This is why I'm strongly opposed to making it optional.

I agree that discard MUST NOT generate a NDN.  The needed functionality
is an automated way to press the delete button.  There was no failure
to delivery, only the user's decision to delete it, automated via
a sieve script.

The problem arises if an implementation cannot implement discard
without generating a NDN.  Do we say:

	- The implemenation is not sieve compatible?
	- Or give some wiggle room and say discard is optional?
	- Or say discard SHOULD NOT generate NDN?

My preference would be stronger than SHOULD NOT but not quite
MUST NOT.  I guess that means stating the discard SHOULD NOT
generate a NDN.  Perhaps, with text stressing that the usefulness
of discard is greatly disminished by implementations that generate
a NDNs.  The developer should try very hard to implement discard
correctly.

I think there is still value in a sieve implementation that
cannot implement discard without a NDN, but users of the
implementation would just have to live with its limitations.

Greg


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13421 for ietf-mta-filters-bks; Tue, 23 Mar 1999 12:27:11 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13417 for <[e-mail]>; Tue, 23 Mar 1999 12:27:09 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <[e-mail]> for [e-mail]; Tue, 23 Mar 1999 12:33:11 PST
Date: Tue, 23 Mar 1999 12:31:11 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Discard vs. DSN
In-reply-to: "Your message dated Tue, 23 Mar 1999 15:27:02 -0500" <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I'd like discard so, say, I can ignore certain people.  I don't want to
> reject their mail, I just want to ignore it.

Exactly right. In my experience being able to ignore messages is one of most
commonly requested features, if not *the* most requested feature, for filters
to be able to do. 

This is why I'm strongly opposed to making it optional.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA13366 for ietf-mta-filters-bks; Tue, 23 Mar 1999 12:19:58 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13361 for <[e-mail]>; Tue, 23 Mar 1999 12:19:57 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA28814; Tue, 23 Mar 1999 15:26:57 -0500 (EST)
Date: 23 Mar 1999 15:27:02 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: DES SEAL Team 6 Kennedy quiche Vince Foster strategic Peking
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Discard vs. DSN
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >> [Randy:]
> >> If 'discard' MUST NOT cause failure DSN generation, this could be
> >> difficult in certain plug-in environments (such as one of the
> >> platforms where my Sieve implementation runs).
> >> 
> >> We can either (1) make 'discard' optional, (2) say that 'discard'
> >> SHOULD NOT cause failure DSN generation, or (3) say this is just
> >> Too Bad.
> >
> >[Tim:]
> >I am in favor of (3).  Generating DSNs in some cases, most specifically
> >spam, is not a good idea.
> 
> [Randy:]
> I don't understand this.
> 
> In one particular environment where my Sieve implementation runs, 'discard'
> causes the same action as if the message is undeliverable for any other
> reason (a failure DSN for 'other' is generated).  Why is this bad
> specifically in the case of spam?

Because the message is probably undeliverable, so a failure notice has
to be sent.  This is inconvienent if the failure can be considered
permenant, but is worse if the domain is valid and fails with a
temporary failure somewhere and just hangs around for five days in the
queue.  (Consider what might happen if a shared filter was in use at CMU
and someone spammed our passwd file.)

Does this help?

> How does a requirement for silent discard follow from purposes for Sieve
> other than message disposition?  Discard *is* message disposition,
> regardless of any other uses for Sieve (and I use Sieve for message
> annotation as well as disposition).

I don't follow this at all.  Perhaps my statement was poorly worded or
poorly thought out.

My thought is that your implementation seems to only control where a
message gets sent, in addition to actions that may be unrelated to
delivery.  This annoys me because it seems to limit both discard and
multiple fileinto, things well-known existing systems (say, procmail)
are capable of and that I consider useful.


Let me ask this: if discard sends a DSN, how is it meaningfully
different from reject?  Reject seems to present a strict superset of
discard functionality as you've described it (you get to tell the sender
where to go in addition to refusing the message).

I'd like discard so, say, I can ignore certain people.  I don't want to
reject their mail, I just want to ignore it.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA08980 for ietf-mta-filters-bks; Wed, 17 Mar 1999 20:06:18 -0800 (PST)
Received: from mail2.qualcomm.com (mail2.qualcomm.com [129.46.2.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA08976 for <[e-mail]>; Wed, 17 Mar 1999 20:06:17 -0800 (PST)
Received: from S43948.qualcomm.com (ra5399b-port15.qualcomm.com [129.46.55.35]) by mail2.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id UAA25159; Wed, 17 Mar 1999 20:12:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@randy-nt4.qualcomm.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 17 Mar 1999 20:10:24 -0800
To: Tim Showalter <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Discard vs. DSN
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 02:51 PM 3/17/99 -0500, Tim Showalter wrote:
>> Date: Tue, 16 Mar 1999 12:29:24 -0800
>> From: Randall Gellens <[e-mail]>
>> 
>> If 'discard' MUST NOT cause failure DSN generation, this could be difficult
>> in certain plug-in environments (such as one of the platforms where my
>> Sieve implementation runs).
>> 
>> We can either (1) make 'discard' optional, (2) say that 'discard' SHOULD
>> NOT cause failure DSN generation, or (3) say this is just Too Bad.
>
>I am in favor of (3).  Generating DSNs in some cases, most specifically
>spam, is not a good idea.

I don't understand this.

In one particular environment where my Sieve implementation runs, 'discard'
causes the same action as if the message is undeliverable for any other
reason (a failure DSN for 'other' is generated).  Why is this bad
specifically in the case of spam?  It doesn't indicate the address is
valid, since there are several reasons why the server might have accepted
the message (such as being an MX for another host).


>I guess this comes down to a model of what Sieve does.  Randy sees it as 
>modifying disposition of a message; I see it as a good deal more
>general.

How does a requirement for silent discard follow from purposes for Sieve
other than message disposition?  Discard *is* message disposition,
regardless of any other uses for Sieve (and I use Sieve for message
annotation as well as disposition).

>(1) is a very unexpected choice, but if I can't get (3), I think I like
>it as much as (2).  At least the behavior is consistant.

(1) is what was suggested at the Sieve BOF when I mentioned the issue.  I'm
not especially fond of it.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA00942 for ietf-mta-filters-bks; Wed, 17 Mar 1999 14:22:49 -0800 (PST)
Received: from THOR.INNOSOFT.COM ([e-mail] [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA00938 for <[e-mail]>; Wed, 17 Mar 1999 14:22:48 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-32 #30494) id <[e-mail]> for [e-mail]; Wed, 17 Mar 1999 14:28:20 PST
Date: Wed, 17 Mar 1999 14:26:41 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Discard vs. DSN
In-reply-to: "Your message dated Wed, 17 Mar 1999 14:51:49 -0500" <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > If 'discard' MUST NOT cause failure DSN generation, this could be difficult
> > in certain plug-in environments (such as one of the platforms where my
> > Sieve implementation runs).

> > We can either (1) make 'discard' optional, (2) say that 'discard' SHOULD
> > NOT cause failure DSN generation, or (3) say this is just Too Bad.

> I am in favor of (3).  Generating DSNs in some cases, most specifically
> spam, is not a good idea.

I also favor (3) over the alternatives.

> I guess this comes down to a model of what Sieve does.  Randy sees it as
> modifying disposition of a message; I see it as a good deal more
> general.

> (1) is a very unexpected choice, but if I can't get (3), I think I like
> it as much as (2).  At least the behavior is consistant.

Again I agree; I don't like either (1) or (2) much, but if I had to have one
of them I don't particularly care which one I'd get.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29464 for ietf-mta-filters-bks; Wed, 17 Mar 1999 11:41:18 -0800 (PST)
Received: from hitchhiker.adsl.net.cmu.edu (host132.44IETF.MR.Net [209.32.92.132]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29456 for <[e-mail]>; Wed, 17 Mar 1999 11:41:10 -0800 (PST)
Received: from hitchhiker.adsl.net.cmu.edu (localhost.localdomain [127.0.0.1]) by hitchhiker.adsl.net.cmu.edu (Postfix) with SMTP id E11591CB1A; Wed, 17 Mar 1999 14:51:49 -0500 (EST)
Date: 17 Mar 1999 14:51:49 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: White Water arrangements Ft. Bragg ammunition Bosnia munitions Albania
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Discard vs. DSN
References: <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Date: Tue, 16 Mar 1999 12:29:24 -0800
> From: Randall Gellens <[e-mail]>
> 
> If 'discard' MUST NOT cause failure DSN generation, this could be difficult
> in certain plug-in environments (such as one of the platforms where my
> Sieve implementation runs).
> 
> We can either (1) make 'discard' optional, (2) say that 'discard' SHOULD
> NOT cause failure DSN generation, or (3) say this is just Too Bad.

I am in favor of (3).  Generating DSNs in some cases, most specifically
spam, is not a good idea.

I guess this comes down to a model of what Sieve does.  Randy sees it as 
modifying disposition of a message; I see it as a good deal more
general.

(1) is a very unexpected choice, but if I can't get (3), I think I like
it as much as (2).  At least the behavior is consistant.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25628 for ietf-mta-filters-bks; Tue, 16 Mar 1999 12:24:09 -0800 (PST)
Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25624 for <[e-mail]>; Tue, 16 Mar 1999 12:24:08 -0800 (PST)
Received: from S43948.qualcomm.com (ra5399-port41.qualcomm.com [129.46.55.91]) by illyana.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id MAA27293 for <[e-mail]>; Tue, 16 Mar 1999 12:30:04 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 16 Mar 1999 12:29:24 -0800
To: [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Discard vs. DSN
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If 'discard' MUST NOT cause failure DSN generation, this could be difficult
in certain plug-in environments (such as one of the platforms where my
Sieve implementation runs).

We can either (1) make 'discard' optional, (2) say that 'discard' SHOULD
NOT cause failure DSN generation, or (3) say this is just Too Bad.

Personally, I suggest (2).


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA20283 for ietf-mta-filters-bks; Fri, 12 Mar 1999 16:34:09 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA20279 for <[e-mail]>; Fri, 12 Mar 1999 16:34:07 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id TAA29321; Fri, 12 Mar 1999 19:40:13 -0500 (EST)
Date: Fri, 12 Mar 1999 19:42:53 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Keith Moore <[e-mail]>, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
Subject: Sieve Working Group Charter [just in case]
Message-ID: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Attached below, for argument's sake, is a version of a hypothetical
proposed charter for a working group that might exist in a parallel
universe where we don't get enough done at the BOF to move Sieve to
proposed standard and actually need future IETF meeting agenda time.

Need I repeat -- this is presented just as a CONTINGENCY, and I am not at
this time seriously proposing submitting this for Area Director review/IESG
approval.

However, Sieve really is sufficiently developed (imho) that we need to move
things along, and this BOF next week will be our second -- and last allowed
under current procedures. 

Thus, if we want to use up meeting time and/or have the imprimatur of a
standard-in-progress, one of the following must happen:

  ==> we wrap up the current spec and submit it to the IESG in a timely
manner, as per our current plan. I suggest at this point that a 'timely
manner' is May at the latest.

  ==> we have sufficient push-back from the participants of the BOF and/or
the Area Directors that we adopt a somewhat delayed schedule but within the
current scope, but without the assumption of needing to meet again, which
would suggest a fall completion date after appropriate work on the list.

  ==> if there's a lot more work to be done than anybody anticipates, or
the scope gets broadened by one of the above, then we'll have to get formal
working group status -- hence the charter below, just in case.

(A default alternative, of course, is to lay down the work. Ptooey on that
idea, I say.)

I whipped this up in the event we end up deciding at the BOF and/or on the
list that we need to go to WG status, just so we have something in hand to
discuss. I took a minimalist approach to the charter in terms of scope. 

Again: just for reference at this point, I see no point in discussing this
until the BOF (if even then).

- Matt


====

SIEVE WORKING GROUP * CHARTER PROPOSAL

NAME: RFC822 Message Filtering Language WG 
Short name: Sieve

CHAIR: TBD. Proposed: 

Ned Freed <[e-mail]>
Matt Wall <[e-mail]>

Applications Area Director(s): 

Keith Moore <[e-mail]>
Patrik Faltstrom <[e-mail]>

Applications Area Advisor: 

TBD.

Mailing Lists: 

General Discussion: [e-mail]
To Subscribe: [e-mail]
Archive: http://www.imc.org/ietf-mta-filters/mail-archive/

Description of Working Group: 

The goal of this working group is to develop a standard language for the
filtering of RFC822[bis] messages.

This language must be minimally sufficient to provide basic filtering
capabilities for messages at time of final delivery. The language must be
appropriate for processing by an engine associated with or in conjunction
with an RFC821[bis] MTA and should be appropriate for processing by an
RFC822[bis] MUA. An extension mechanism must be included as part of the
base specification. 
Additionally, the working group will produce documents specifying the
following extensions to the basic language: (1) vacation-style
auto-processing of messages (2) [nothing else just yet...].

The working group will specifically NOT establish any independent protocol
for the transport of the scripts of such language. However, the working
group will endeavour to make scripts in the proposed language amenable to
transport via likely application-layer transport protocols. The working
group should issue an informational document, or incorporate within the
base specification, any relevant parameters or security concerns with
respect to transport of scripts. The working group will register an
appropriate MIME type for MIME transport of MTA filtering data, however.

The documents produced by this working group will be submitted to the IESG
as proposed standards.

Goals and Milestones:

June 1999        Eighth revised version of Sieve Specification
August 1999      Third revised version of Vacation Spec
November 1999    Meet at Washington, DC
February 2000    Submit final versions of Internet Drafts to IESG for 
                 consideration as Internet Standards




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA19624 for ietf-mta-filters-bks; Fri, 12 Mar 1999 15:21:56 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA19618 for <[e-mail]>; Fri, 12 Mar 1999 15:21:55 -0800 (PST)
Received: from pasargadae.cyrusoft.com (pasargadae.cyrusoft.com [206.31.218.209]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id SAA29065; Fri, 12 Mar 1999 18:28:00 -0500 (EST)
Date: Fri, 12 Mar 1999 18:30:40 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>
Subject: Last minute pre-IETF stuff
Message-ID: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Howdy,

First off, a reminder that the Sieve session for Minneapolis is this coming
Tuesday morning from 0900 to 1000. It conflicts with IP Fax and the
Internet Print Protocol, so no excuses from you for not attending 8-).
We're in the "Duluth Room".

Note we've got ONE HOUR, so will have to be efficient!

If you missed the agenda, here it is:

http://www.ietf.org/ietf/99mar/sieve-agenda-99mar.txt

I don't anticipate major changes, but we'll do an agenda-check on-site.

Secondly, a final request that everybody review the following:

-- Version 007 of the Sieve draft.

-- Tim's posting on this list a few days ago of open issues, etc.

and come PREPARED to the meeting. If you've got additional issues that you
know need to go on the agenda and/or Tim's list, please post to the list
and/or send Tim, Ned, and myself a note ASAP.

If we can slog through the issues list, I think we'll be in a better
position to get this straight-to-proposed and skip the usually gruesome
Charter Discussion.

In particular, if you can focus your brain on potential 'show stoppers' or
'niggling details that may be critical path items' -- those are the things
(if they indeed exist) that would be good to deal with in face to face
time. By all means, though, bring nits to pick as well - just prioritize
8-).

I'm also going to ask at the start of the meeting for a quick show of hands
about who's done an implementation of some sort. 

I will make an effort to post results of this session back to the list ASAP
so that those of you who can't make the meeting know what's up.

- Matt
  [e-mail]






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA05069 for ietf-mta-filters-bks; Wed, 10 Mar 1999 13:13:45 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA05065 for <[e-mail]>; Wed, 10 Mar 1999 13:13:44 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA01136; Wed, 10 Mar 1999 16:19:45 -0500 (EST)
Date: 10 Mar 1999 16:19:45 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: White Water bomb SEAL Team 6 SDI radar class struggle COSCO
To: [e-mail]
Subject: sieve-07 & sieve-vacation-01 availible at an i-d mirror near you
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm sorry for not having had the announcement sent here, but the new
Sieve spec (07) and the Vacation extension (01) are avalible at an
Internet-Draft mirror near you.

URLs for these documents are

  ftp://ftp.ietf.org/internet-drafts/draft-showalter-sieve-07.txt
  ftp://ftp.ietf.org/internet-drafts/draft-showalter-sieve-vacation-01.txt

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA04151 for ietf-mta-filters-bks; Wed, 10 Mar 1999 11:23:39 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04147 for <[e-mail]>; Wed, 10 Mar 1999 11:23:38 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id OAA17214; Wed, 10 Mar 1999 14:29:36 -0500 (EST)
Date: 10 Mar 1999 14:29:39 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: KGB strategic Mossad North Korea Ruby Ridge Semtex spy
To: [e-mail]
Subject: issues list for SIEVE BOF
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here's my unabridged issues list for the SIEVE BOF meeting.  Please send 
corrections, additions, arguments and flames to the list.

** sieve

Clarifications:

 * Site limits on actions: 

   actions encountered in scripts first are the ones executed?  (Scripts
   guaranteed to execute left-to-right, top-to-bottom.)

   - But what happens if limits on numbers of actions are exceeded?  Which
     ones are executed?  (Likely resolution: Clarify that the answer is the
     ones that are encountered first.)

 * Action interaction:

   What actions are legal with other actions?  Larry Greenfield and I tried to
   come up with a clean way of describing this, but failed; actions are just
   very different, and every new action we came up with suggested a different
   set of semantics.

   Proposal:
     - Discard is compatible with *everything* and is defined solely as
       cancelling the implicit keep.  (keep; discard; ==> keep;)
     - Reject is incompatible with everything except discard.

     Notes: 
       - Keep === fileinto "inbox".
       - Randy's demand for limitations are handled solely by the site limits
         on actions stuff; he just has a really low limit on stuff he can do.

 * Implicit keep

   We'd like to have some relation between action interactions and implicit
   keep, but couldn't come up with anything.  All basic actions and extensions 
   have to define what they do with the implicit keep.

   - Actions that cancel the implicit keep: reject, discard, fileinto, keep.
   - Actions that don't: vacation, redirect.
   - stop and require aren't considered actions.

 * Spec'ed minimums:
   - no more than one reject.
   - at least one fileinto or keep (if fileinto is supported)
   - at least one redirect must be allowed.

 * When is aborting out of a require that fails done, before or during
   execution?  (Likely resolution: whatever)

 * charset.  We are requiring decoding charsets to Unicode, but what about
   messages that are sent out (reject, vacation)?

   Proposal: Allow degrading to well-known character sets at the
   implementation's whim (if it's just an ASCII message, send ASCII; if it's
   not, implementations are permitted to degrade to ISO-8859 charsets if they
   so desire).

   Language tagging is handled for the Unicode case, which is really the
   interesting case.

 * Errors: what to say?

 * Move vacation into base spec?

 * Editorial:
   - stop and require moved to control actions section.

** sieve-vacation

 * Action interaction: vacation compatible with everything except reject.
 * Vacation DOES NOT cancel the implicit keep.

Vacation response monitoring: Not just per user (being responded to), but per
user, per message supplied in the script.  If message in the script changes,
delay is reset.

 * Is this okay?  (It could be rather expensive.)
 * Implementations MAY forget all about previous responses if the script
   containing the vacation call is changed?

 * Add requirement for implementation-dependant list of addresses that
   vacation never replies to, which MUST contain the address POSTMASTER (case
   insensitive) and may have other addresses?



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21051 for ietf-mta-filters-bks; Tue, 2 Mar 1999 09:47:35 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA21047 for <[e-mail]>; Tue, 2 Mar 1999 09:47:34 -0800 (PST)
Received: from creamofwheat-54.slip.andrew.cmu.edu (CREAMOFWHEAT-54.SLIP.ANDREW.CMU.EDU [128.2.120.54]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id MAA07511; Tue, 2 Mar 1999 12:52:30 -0500 (EST)
Date: Tue, 02 Mar 1999 12:53:36 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Tim Showalter <[e-mail]>
Subject: Re: BOF Request, Minneapolis
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.1, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tue, Mar 2, 1999 11:45 AM -0500 the entity known as Sam Silberman
<[e-mail]> wrote:


> At 11:27 AM 3/1/99 -0800, J.D. Falk wrote:
> Yes.
> 
> http://www.ietf.org/ietf/99mar/sieve-agenda-99mar.txt
> 
> Sieve Mail Filtering Language BOF (sieve)
> 
> Tuesday, March 16 at 0900-1000
> ==============================
> 
> Chairs: Matthew Wall <[e-mail]>
>         Ned Freed <[e-mail]>
> 
> 

To which Matthew Wall offers this response on Tue, 02 Mar 1999 12:49:58
-0500:


Note we only have an hour, so we're going to have to be fairly expeditious
about the course of the meeting. The good news is there doesn't appear to
be anything significant by way of conflicts at that hour.

Tim's preparing a list of residual issues, and I'd like to pound on it as
much as people have time for over the next two weeks; we ought to resolve
the course of Sieve's status, and if there are just too many little things
to go over, we'll have to charter a WG. I don't think this will be
necessary, but it's time to get this puppy out the door.

- mw





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA20115 for ietf-mta-filters-bks; Tue, 2 Mar 1999 08:40:54 -0800 (PST)
Received: from mta1biz.mailsrvcs.net ([207.115.143.35]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20111 for <[e-mail]>; Tue, 2 Mar 1999 08:40:53 -0800 (PST)
Received: from swcpq26 ([10.64.5.67]) by mta1biz.mailsrvcs.net with SMTP id <19990302164715.BLFV772.mta1biz@swcpq26>; Tue, 2 Mar 1999 10:47:15 -0600
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 02 Mar 1999 11:45:26 -0500
To: "J.D. Falk" <[e-mail]>, [e-mail]
From: Sam Silberman <[e-mail]>
Subject: Re: BOF Request, Minneapolis
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:27 AM 3/1/99 -0800, J.D. Falk wrote:
>On 02/22/99, Matthew Wall <[e-mail]> wrote: 
>
>> We (Ned Freed and myself, on behalf of the mta-filters mailing list) would
>> like to formally request a BOF for Minneapolis for Sieve (MTA-Filters).
>
>	Any word on scheduling of this?
>

Yes.

http://www.ietf.org/ietf/99mar/sieve-agenda-99mar.txt

Sieve Mail Filtering Language BOF (sieve)

Tuesday, March 16 at 0900-1000
==============================

Chairs: Matthew Wall <[e-mail]>
        Ned Freed <[e-mail]>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13210 for ietf-mta-filters-bks; Mon, 1 Mar 1999 11:22:40 -0800 (PST)
Received: from fillmore.criticalpath.net (fillmore.paix.cp.net [209.228.15.40]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA13206 for <[e-mail]>; Mon, 1 Mar 1999 11:22:39 -0800 (PST)
Received: (cpmta 20215 invoked from network); 1 Mar 1999 11:27:56 -0800
Received: from ihnj.ops.cp.net (209.228.9.22) by smtp.criticalpath.net with SMTP; 1 Mar 1999 11:27:56 -0800
X-Sent: 1 Mar 1999 19:27:56 GMT
Received: (from jdfalk@localhost) by ihnj.ops.cp.net (8.8.8/8.8.8/JDF/9811.02) id LAA00652; Mon, 1 Mar 1999 11:27:56 -0800 (PST) (envelope-from jdfalk)
Message-ID: <[e-mail]>
Date: Mon, 1 Mar 1999 11:27:56 -0800
From: "J.D. Falk" <[e-mail]>
To: [e-mail]
Subject: Re: BOF Request, Minneapolis
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <[e-mail]>; from Matthew Wall on Mon, Feb 22, 1999 at 07:05:27PM -0500
X-Editor: nvi
X-Comment: Stop e-mail spam for good!  http://www.cauce.org/
X-IPO: filed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On 02/22/99, Matthew Wall <[e-mail]> wrote: 

> We (Ned Freed and myself, on behalf of the mta-filters mailing list) would
> like to formally request a BOF for Minneapolis for Sieve (MTA-Filters).

	Any word on scheduling of this?

-- 
J.D. Falk <[e-mail]>                     "We don't want our customers
Special Agent In Charge (Abuse Issues)         to lose their marbles."
Critical Path, Inc.                                   -- Dave Rand, AboveNet