Re: Support for the vacation extension

[Tim Showalter <[e-mail]>]

> Date: Fri, 29 Jan 1999 18:54:57 +0100
> From: Michael Salmon <[e-mail]>
> 
> +----- On 28 Jan 1999 18:54:46 EST, Tim Showalter writes:
> | Does the language of vacation's reply text need to be (optionally)
> | specified?
> 
> I think so, or at least the character set should be specified, especially 
> if the subject line can be set.

I would really like to limit everything to UTF-8 if that's feasible.

> In the original draft there was an if statement around the vacation,
> that seems redundant if you are going to include that check in vacation
> itself.

And they've been remvoed in my working version, which I will probably
post soon.

I have a strong preference for this.  It makes scripts more portable and 
more idiot-proof.

> How should +mailboxes to be handled?

You mean which mailbox to write to?  Vacation is a command that does not
modify the delivery status, so presumably, there's an implicit keep...

> I think that that is very important, all of the users in Ericsson have 
> 2 addresses, some several more. Without the ability to specify the 
> aliases I don't think that sieve's vacation will be used here.

We have that feature too.  I'd like to mandate that vacation is smart
about it, but provide ways of clueing it in to more stuff.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16778 for ietf-mta-filters-bks; Fri, 29 Jan 1999 14:12:32 -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 OAA16774 for <[e-mail]>; Fri, 29 Jan 1999 14:12:31 -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 RAA21476; Fri, 29 Jan 1999 17:15:12 -0500 (EST)
Date: 29 Jan 1999 17:15:23 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Semtex Ruby Ridge ammunition terrorist Bosnia Cocaine plutonium
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Support for the vacation extension 
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: Fri, 29 Jan 1999 18:54:57 +0100
> From: Michael Salmon <[e-mail]>
> 
> +----- On 28 Jan 1999 18:54:46 EST, Tim Showalter writes:
> | Does the language of vacation's reply text need to be (optionally)
> | specified?
> 
> I think so, or at least the character set should be specified, especially 
> if the subject line can be set.

I would really like to limit everything to UTF-8 if that's feasible.

> In the original draft there was an if statement around the vacation,
> that seems redundant if you are going to include that check in vacation
> itself.

And they've been remvoed in my working version, which I will probably
post soon.

I have a strong preference for this.  It makes scripts more portable and 
more idiot-proof.

> How should +mailboxes to be handled?

You mean which mailbox to write to?  Vacation is a command that does not
modify the delivery status, so presumably, there's an implicit keep...

> I think that that is very important, all of the users in Ericsson have 
> 2 addresses, some several more. Without the ability to specify the 
> aliases I don't think that sieve's vacation will be used here.

We have that feature too.  I'd like to mandate that vacation is smart
about it, but provide ways of clueing it in to more stuff.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14922 for ietf-mta-filters-bks; Fri, 29 Jan 1999 10:46:23 -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 KAA14918 for <[e-mail]>; Fri, 29 Jan 1999 10:46:21 -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 NAA23477 for <[e-mail]>; Fri, 29 Jan 1999 13:48:30 -0500 (EST)
Received: from att.com (hansenpc.bl-els.att.com[135.25.111.58](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990129184839un1157207de>; Fri, 29 Jan 1999 18:48:39 +0000
Message-ID: <[e-mail]>
Date: Fri, 29 Jan 1999 13:48:54 -0500
From: Tony Hansen <[e-mail]>
Reply-To: [e-mail]
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.07 [en] (Win98; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Multiple actions in Sieve script.
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>

Tim Showalter wrote:
> 
> > What's wrong with saying that some actions affect delivery status,
> > and other actions don't?
> 
> If you're having these things in a UI, it doesn't matter what we say, we
> can (we have to) assume the UI will just get it right.
> 
> But for the people designing the UI, and the people implementing scripts
> using a text editor, the fewer special cases, the better.
> 
> It is much easier to explain this:
>   "A message that generates no actions gets filed into your INBOX."
> 
> than this:
>   "A mesasge that generates no delivery actions gets filed into your
>   INBOX.  Delivery actions are ones which change the disposition of the
>   message, and they are reject, forward, and fileinto."

I personally think that adding this distinction NOW will vastly simplify
future additions to the language. I can think of several possible
extensions which definitely should not affect the delivery decisions
that are made elsewhere within the script. By saying that these new
actions must affect the delivery status without having a way of saying
that they don't, or having a model for such actions in the future, we
are going to make life more difficult in the future.

Consider vacation. Does it affect delivery or not? I'd say it shouldn't.
Wouldn't it be far simpler for the vacation draft to just say "The
vacation verb is not a delivery action." than to add verbiage saying
that it doesn't.

How about an extension that says "I want this message to be
cross-indexed in a fast search engine." I'd like such an extension to
also say "this action does not define a delivery action."

How about an alerting extension that says "notify my pager about this
message." The fact that a notification is sent shouldn't affect how the
message is otherwise filed.

So, yes I do think it is simpler, in the long run, to use the latter
definition you specify above.

	Tony Hansen
	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA14479 for ietf-mta-filters-bks; Fri, 29 Jan 1999 09:52:18 -0800 (PST)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA14475 for <[e-mail]>; Fri, 29 Jan 1999 09:52:16 -0800 (PST)
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.44.44]) by penguin.wise.edt.ericsson.se (8.9.0/8.9.0/WIREfire-1.2) with ESMTP id SAA27175 for <[e-mail]>; Fri, 29 Jan 1999 18:54:55 +0100 (MET)
Received: from uabs78c65.uab.ericsson.se (uabs78c65.uab.ericsson.se [134.138.201.115]) by ms.uab.ericsson.se (8.8.8/8.8.8/uab-1.34) with ESMTP id SAA26286 for <[e-mail]>; Fri, 29 Jan 1999 18:54:58 +0100 (MET)
Received: from uabs78c65 by uabs78c65.uab.ericsson.se (8.8.8/client-1.3uab1) id SAA24490; Fri, 29 Jan 1999 18:54:58 +0100 (MET)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: Re: Support for the vacation extension 
In-reply-to: Your message of "28 Jan 1999 18:54:46 EST." <[e-mail]> 
X-Reply-To: [e-mail]
X-uri: http://www.elfi.adbkons.se/~mesa
X-pgp-fingerprint: DD 6A DD AE 7D 37 C2 92  9D 2A 1D 26 0E 7D 25 86
X-Face: %"f^~cZ#`qgIYZ:xm95*9;YDUM)2,!]kETwVGx>1[h?{Y:MuarA9uj0j `{avD3^1apqS7P~1Gib%0#tn"aqV;GfhXJ"1?ZPn|]xc[$:03Q%?k3"#PGh| `^{^-LRX]UB^}+,TY~EETpLrQiG"4}I-gdj=l!c)W;_R:X;qO#dpL#Y77J:; PTyjqj'/Nx*3&@@p]LISmtWlDIMprRgA%pMGy9M:NB>}e{0+)s(ZGM|PK}V" 0XW:FQ)%L&o\E''v'RWg.fZ$_s1jLhE>;JzHR:Yb
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 29 Jan 1999 18:54:57 +0100
From: Michael Salmon <[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 28 Jan 1999 18:54:46 EST, Tim Showalter writes:
| Does the language of vacation's reply text need to be (optionally)
| specified?

I think so, or at least the character set should be specified, especially 
if the subject line can be set.

| Obviously the vacation extension has some dependance on resolution of
| multiple-commands questions.
| 
| I want to add this text to the vacation extension (with many more
| obvious revisions):
| 
| "Vacation" never responds to a message unless the user's email address
| is in the "To" or "Cc" line of the original message.

In the original draft there was an if statement around the vacation,
that seems redundant if you are going to include that check in vacation
itself. How should +mailboxes to be handled?

| I want to also add an optional argument allowing additional email
| addresses to be specified.  The rationale is that I want to prohibit the 
| obvious problem with vacation commands (that they tend to send lots of
| mail out for users who subscribe to mailing lists), and as long as we
| limit it to user-specified and user-supplied addresses, we're fine (it's 
| responding to mailing list mail that I'm worried about).

I think that that is very important, all of the users in Ericsson have 
2 addresses, some several more. Without the ability to specify the 
aliases I don't think that sieve's vacation will be used here.

/Michael



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA12108 for ietf-mta-filters-bks; Fri, 29 Jan 1999 06:56:31 -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 GAA12104 for <[e-mail]>; Fri, 29 Jan 1999 06:56:26 -0800 (PST)
Received: from gallileo.esys.ca (dhcp198-44.esys.ca [198.161.92.44]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id HAA03311; Fri, 29 Jan 1999 07:59:07 -0700
From: Steve Hole <[e-mail]>
Date: Fri, 29 Jan 1999 07:58:22 -0700
To: Tim Showalter <[e-mail]>
Subject: Re: Support for the vacation extension
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 pc4 Build (33)
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 28 Jan 1999 18:54:46 -0500 Tim Showalter <[e-mail]> wrote:

> Does the language of vacation's reply text need to be (optionally)
> specified?
> 
> Obviously the vacation extension has some dependance on resolution of
> multiple-commands questions.
> 
> I want to add this text to the vacation extension (with many more
> obvious revisions):
> 
>  "Vacation" never responds to a message unless the user's email address
>  is in the "To" or "Cc" line of the original message.

I like that.

> I want to also add an optional argument allowing additional email
> addresses to be specified.  The rationale is that I want to prohibit the 
> obvious problem with vacation commands (that they tend to send lots of
> mail out for users who subscribe to mailing lists), and as long as we
> limit it to user-specified and user-supplied addresses, we're fine (it's 
> responding to mailing list mail that I'm worried about).

I think that is reasonable.

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA11735 for ietf-mta-filters-bks; Fri, 29 Jan 1999 06:26:12 -0800 (PST)
Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA11730 for <[e-mail]>; Fri, 29 Jan 1999 06:26:09 -0800 (PST)
Received: from langeland (LANGELAND.maxware.no [10.128.1.242]) by dokka.maxware.no (8.8.7/8.8.7) with SMTP id PAA29828; Fri, 29 Jan 1999 15:28:40 +0100
Message-ID: <016101be4b93$d36463c0$[e-mail]>
From: "Harald Alvestrand (outlook)" <[e-mail]>
To: "Tim Showalter" <[e-mail]>, <[e-mail]>
Subject: Re: Language for conflicting actions
Date: Fri, 29 Jan 1999 15:29:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA11732
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually I've found the queueing up of actions until the end a VERY
desirable feature.
The only sieve language I ever designed did this; it also did set manipulation
on the set of languages at the end of its run, to do actions like:

- If it's filed into the same mailbox for multiple reasons, file it once.
- If it's filed into "Inbox (High Priority)", don't bother to file it into "Inbox (General)"
- If it's from list "Idiot Configured Listserver", don't put it into Inbox even though
  it's got my name in the To: field

It's probably the wrong time to wish for the Sieve language to be like this.
But it sure was nice to have; I miss it.

(No, I never published it. It was a Perl hack on MH mailboxes.)

                                           Harald A




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA05523 for ietf-mta-filters-bks; Thu, 28 Jan 1999 15:52:04 -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 PAA05518 for <[e-mail]>; Thu, 28 Jan 1999 15:52:03 -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 SAA05823; Thu, 28 Jan 1999 18:54:40 -0500 (EST)
Date: 28 Jan 1999 18:54:46 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Kennedy Rule Psix Semtex Albania explosion CIA radar
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Support for the vacation extension
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>

Does the language of vacation's reply text need to be (optionally)
specified?

Obviously the vacation extension has some dependance on resolution of
multiple-commands questions.

I want to add this text to the vacation extension (with many more
obvious revisions):

 "Vacation" never responds to a message unless the user's email address
 is in the "To" or "Cc" line of the original message.

I want to also add an optional argument allowing additional email
addresses to be specified.  The rationale is that I want to prohibit the 
obvious problem with vacation commands (that they tend to send lots of
mail out for users who subscribe to mailing lists), and as long as we
limit it to user-specified and user-supplied addresses, we're fine (it's 
responding to mailing list mail that I'm worried about).

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA04909 for ietf-mta-filters-bks; Thu, 28 Jan 1999 14:57:59 -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 OAA04905 for <[e-mail]>; Thu, 28 Jan 1999 14:57:58 -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 SAA03046; Thu, 28 Jan 1999 18:00:36 -0500 (EST)
Date: 28 Jan 1999 18:00:40 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Honduras colonel Clinton Soviet World Trade Center class struggle Rule Psix
To: [e-mail]
In-reply-to: <v04104307b2d696d62ef2@129.46.219.133>
Subject: Re: Language for conflicting actions
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: Thu, 28 Jan 1999 14:43:20 -0800
> From: Randall Gellens <[e-mail]>

> > Note that I'm not saying you can't run the script before parsing it.
> > I'm saying you have to queue up actions before doing any.  That's pretty
> > easy to implement, even if you sprinkle in the evaluation code in with
> > the parser -- you just save up a list of all the stuff you're gonna do
> > and sanity check it before running it.
> 
> You can prevent mutually exclusive actions by keeping a flag as to 
> which ones you've done; you don't need to queue them all.  So you 
> could parse the script first, for example, then while executing it 
> hit a "forward" statement and do it (and set the "forwarded" flag), 
> then later on hit a "reject" and issue a run-time error/warning that 
> it was ignored.

This isn't very good.  The best that you can do is do whatever happens
first, and I don't consider that to be desirable.

> Saving up a list of everything you're going to do could force an 
> implementation to use more memory or have scaling problems, 
> potentially.

I don't buy that at all.  I cannot imagine how a list of actions (which
will typically be one per message and seldom more than five per message)
could cause massive scaling problems even on the largest of central
servers.

The cost of running Sieve in the first place will be orders of magnitude
higher than queueing up actions.

> If a script executes multiple forwards, or replies 
> (assuming that is accepted as an extension), the execution agent 
> could be forced to dynamically allocate a potentially unbounded 
> amount of memory to keep all the actions (including text).

This is not very important, really.  After all, if the number of headers 
is large, an implementation could be forced to allocate a potentially
unbounded amount of space for that, too.  Same goes for length of
the script.

As a server programmer, I don't see an implementation problem here at
all.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA04727 for ietf-mta-filters-bks; Thu, 28 Jan 1999 14:39:58 -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 OAA04723 for <[e-mail]>; Thu, 28 Jan 1999 14:39:57 -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 RAA27715; Thu, 28 Jan 1999 17:42:33 -0500 (EST)
Date: 28 Jan 1999 17:42:38 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: strategic FBI spy PLO Ruby Ridge fissionable genetic
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Support for the vacation extension
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>

> From: Steve Hole <[e-mail]>
> Date: Thu, 28 Jan 1999 09:36:14 -0700

> Yes.    I have been meaning to talk about this for awhile and keep 
> forgetting.     I claim that we *really* need a vacation extension or 
> direct support for vacation in this protocol from day one.      I believe 
> this to be at least as important a feature as the fileinto action ... 
> perhaps more so because it is absolutely useful to any distributed mail 
> client.
> 
> The semantics of the original "reply" operation were half of what is 
> needed to provide vacation support, the other have being the reply policy 
> bits to meter automatic responses.      Someone, somewhere had posted a 
> draft that I no longer have that described the functionality.
> 
> I really think that we need to address this issue.

I posted the original vacation extension and will be happy to revise
it.  It is, however, very out of date, but won't have to be as complex.

The hitch is that in order to properly do vacation, you have to have the 
user's email address(es) so that you can prevent them from sending mail
to mailing lists announcing their vacation.

The addition of optional arguments should make vacation much nicer.

Anyway, for curiosity's sake, I'll post a copy of the draft at the end
of this message.  Please note that it needs a rewrite because of grammar 
changes, some of which really help with this sort of thing.

Tim

-- 
Tim Showalter <[e-mail]>







Network Working Group                                       T. Showalter
Internet Draft: Sieve Vacation                           Carnegie Mellon
Document: draft-showalter-sieve-vacation-00beta.txt         January 1998
Expire in six months (31 Jun 1998)


                      Sieve -- Vacation Extension


Status of this memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   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 1998.  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.  The extension is offered in the hopes of making frequently
   used commands availible (and discouraging users from implementing it
   themselves).








Showalter                 Expires 31-Jun-1998                   [Page 1]

Internet DRAFT             Sieve -- Vacation                January 1998


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 compared with the Sieve mail filtering
   language, an Internet-Draft 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 <reason-string>

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

   Vacation is similar to reply as defined in [SIEVE].  Like reply in
   that document and Unix vacation, the reply goes to the address
   specified by the return-path header (the envelope "MAIL FROM"
   address), not to the addresses in the From header.

   There are a few differences:

   "Vacation" keeps track of all of the addresses that it has responded
   to in the past seven (7) days and MUST NOT respond to them a second



Showalter                 Expires 31-Jun-1998                   [Page 4]

Internet DRAFT             Sieve -- Vacation                January 1998


   time within this period.  The "vacation" action may send out
   notifications less frequently, but should not send them out more
   frequently.

   Vacation is used like this:

   Example:
             if header ("to", "cc") contains ("[e-mail]") {
               vacation
               "I'm away until Octber 19.
             If it's an emergency, call 911, I guess." ;
             }

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

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

   However, it is important that users check for their email address in
   the To and CC lines of the input message so that the script only
   responds to mail sent to them.

4. Interaction with Other Sieve Actions

   Sieve actions sometimes prohibit each other in order to make
   filtering scripts less likely to cause serious problems.  Vacation
   has exactly the same semantics as reply, as it is strictly less
   likely to cause problems -- vacation sometimes sends out a message,
   whereas reply always does.

5. Security Considerations

   It is important that implementations correctly implement the seven-
   day limit on messages and reply to the envelope from address, not the
   From line address.









Showalter                 Expires 31-Jun-1998                   [Page 5]

Internet DRAFT             Sieve -- Vacation                January 1998


6. Formal Grammar

   The grammar used in this section is the same as the ABNF described in
   [ABNF].

   action =/ vacation         ;; "vacation" is now a legal action

   vacation = vacation WSP string

7. Author's Address

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

   E-Mail: [e-mail]


































Showalter                 Expires 31-Jun-1998                   [Page 6]

Internet DRAFT             Sieve -- Vacation                January 1998


Appendices

Appendix A.  References

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

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

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

Appendix B. Full Copyright Statement

   Copyright (C) The Internet Society 1997. 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 will expire before June 31, 1998.














Showalter                 Expires 31-Jun-1998                   [Page 7]





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA04720 for ietf-mta-filters-bks; Thu, 28 Jan 1999 14:39:38 -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 OAA04716 for <[e-mail]>; Thu, 28 Jan 1999 14:39:37 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA08248; Thu, 28 Jan 1999 14:41:37 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v04104307b2d696d62ef2@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 28 Jan 1999 14:43:20 -0800
To: Tim Showalter <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Language for conflicting actions
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b7
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:20 PM -0500 1/27/99, Tim Showalter wrote:


> Well, here's the problem.  Reject and forward are mutually exclusive
> (or, IMHO, should be, because I have a very hard time with the idea that
> a standards-track document should provide for bogus DSNs.)
>
> If you reject a message, you have to throw it away; the DSN says you
> did so.
>
> It was decided some time ago that reject+keep was an absurd thing to do
> and should not be allowed, right?




At 11:22 PM -0500 1/27/99, Tim Showalter wrote:


> Note that I'm not saying you can't run the script before parsing it.
> I'm saying you have to queue up actions before doing any.  That's pretty
> easy to implement, even if you sprinkle in the evaluation code in with
> the parser -- you just save up a list of all the stuff you're gonna do
> and sanity check it before running it.


You can prevent mutually exclusive actions by keeping a flag as to 
which ones you've done; you don't need to queue them all.  So you 
could parse the script first, for example, then while executing it 
hit a "forward" statement and do it (and set the "forwarded" flag), 
then later on hit a "reject" and issue a run-time error/warning that 
it was ignored.


Saving up a list of everything you're going to do could force an 
implementation to use more memory or have scaling problems, 
potentially.  If a script executes multiple forwards, or replies 
(assuming that is accepted as an extension), the execution agent 
could be forced to dynamically allocate a potentially unbounded 
amount of memory to keep all the actions (including text).  Yes, you 
could get around this by instead keeping pointers to the statements, 
but that's still no business of the spec, I say.


Why should the standard force an implementation?  It seems wrong.


If we want to state that certain actions are mutually exclusive, OK. 
But let's not dictate implementation methods.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01216 for ietf-mta-filters-bks; Thu, 28 Jan 1999 08:42:29 -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 IAA01212 for <[e-mail]>; Thu, 28 Jan 1999 08:42:28 -0800 (PST)
Received: from gallileo.esys.ca (dhcp198-44.esys.ca [198.161.92.44]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id JAA01385; Thu, 28 Jan 1999 09:44:36 -0700
From: Steve Hole <[e-mail]>
Date: Thu, 28 Jan 1999 09:43:53 -0700
To: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Cc: [e-mail]
In-Reply-To: <v04104201b2d4007f1b70@129.46.219.133>
References: <v04104201b2d4007f1b70@129.46.219.133> "Your message dated Tue, 26 Jan 1999 14:39:35 -0800"   <v04104207b2d3f38202e3@129.46.219.133>   <[e-mail]>   <v04104204b2d2cff4aa15@129.46.219.133>   <[e-mail]>   
Message-ID: <[e-mail]>
X-Mailer: Execmail for Win32 Version 5.0 pc4 Build (33)
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 Tue, 26 Jan 1999 15:39:38 -0800 Randall Gellens <[e-mail]> 
wrote:

> Personally, I think it would be counterintuitive and dangerous to 
> make this the position, but I also feel that not being clear is much 
> worse.

I agree.
 
> I think a clear and safe way of phrasing this is: Message are 
> delivered unless an action is performed which explicitly prevents 
> delivery (such as "reject").

That seems to me to be the best way to handle it.    Specify that delivery
will occur subsequent to any action (or collection of actions) unless one 
or more of the actions specifically overrides that (like reject).    
Presumably there is smallish subset of actions that would prevent 
subsequent delivery.
 
> We can separately talk about the default delivery mailbox: The 
> default mailbox for delivery is "INBOX" on an IMAP server, the 
> maildrop on a POP server.  If FileInto is supported, this can be used 
> to alter the delivery mailbox.

Just call it the metaphorical sieve INBOX.   It is the place where mail 
goes normally if there was no sieve script in the way.    This is an 
implementation dependent location. 

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 IAA01170 for ietf-mta-filters-bks; Thu, 28 Jan 1999 08:34:36 -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 IAA01166 for <[e-mail]>; Thu, 28 Jan 1999 08:34:35 -0800 (PST)
Received: from gallileo.esys.ca (dhcp198-44.esys.ca [198.161.92.44]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id JAA01369 for <[e-mail]>; Thu, 28 Jan 1999 09:36:56 -0700
From: Steve Hole <[e-mail]>
Date: Thu, 28 Jan 1999 09:36:14 -0700
To: [e-mail]
Subject: Support for the vacation extension
Message-ID: <[e-mail]>
X-Mailer: Execmail for Win32 Version 5.0 pc4 Build (33)
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>

Tim Showalter said:

> Reply is not in draft 06, 05, or 04, because in LA, it was decided that
> reply was dangerous without some sort of vacation-style protection
> (limit number of replies in a single time period).
> 
> (I wouldn't mind having a vacation command that also implied a keep, but 
> that's not what we're talking about here.)

Yes.    I have been meaning to talk about this for awhile and keep 
forgetting.     I claim that we *really* need a vacation extension or 
direct support for vacation in this protocol from day one.      I believe 
this to be at least as important a feature as the fileinto action ... 
perhaps more so because it is absolutely useful to any distributed mail 
client.

The semantics of the original "reply" operation were half of what is 
needed to provide vacation support, the other have being the reply policy 
bits to meter automatic responses.      Someone, somewhere had posted a 
draft that I no longer have that described the functionality.

I really think that we need to address this issue.

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 UAA00359 for ietf-mta-filters-bks; Wed, 27 Jan 1999 20:20:23 -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 UAA00353 for <[e-mail]>; Wed, 27 Jan 1999 20:20:22 -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 XAA21290; Wed, 27 Jan 1999 23:22:55 -0500 (EST)
Date: 27 Jan 1999 23:22:57 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Serbian KGB Qaddafi counter-intelligence Khaddafi SEAL Team 6 Noriega
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Language for conflicting actions
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: 27 Jan 1999 23:20:17 -0500
> From: Tim Showalter <[e-mail]>
> 
> > Date: Mon, 25 Jan 1999 18:20:00 -0800
> > From: Randall Gellens <[e-mail]>
> 
> > > Command Interactions
> > >
> > > It is possible for two or more actions to be executed by a script.  A
> > > script MUST NOT perform any action before finishing execution, and
> > > MUST check that the actions are consistent (according the the
> > > following chart).
> > 
> > When we discussed parsing before executing (to trap syntax errors), 
> > it was decided that this was a quality of implementation issue, not a 
> > Sieve requirement.  Why should this be any different?
> 
> Well, here's the problem.  Reject and forward are mutually exclusive
> (or, IMHO, should be, because I have a very hard time with the idea that 
> a standards-track document should provide for bogus DSNs.)
> 
> If you reject a message, you have to throw it away; the DSN says you
> did so.
> 
> It was decided some time ago that reject+keep was an absurd thing to do
> and should not be allowed, right?

Note that I'm not saying you can't run the script before parsing it.
I'm saying you have to queue up actions before doing any.  That's pretty
easy to implement, even if you sprinkle in the evaluation code in with
the parser -- you just save up a list of all the stuff you're gonna do
and sanity check it before running it.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29785 for ietf-mta-filters-bks; Wed, 27 Jan 1999 20:17:44 -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 UAA29776 for <[e-mail]>; Wed, 27 Jan 1999 20:17:43 -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 XAA21169; Wed, 27 Jan 1999 23:20:15 -0500 (EST)
Date: 27 Jan 1999 23:20:17 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: clones Waco, Texas colonel Albania Saddam Hussein fissionable ammunition
To: [e-mail]
In-reply-to: <v04104207b2d2d3848041@129.46.219.133>
Subject: Re: Language for conflicting actions
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: Mon, 25 Jan 1999 18:20:00 -0800
> From: Randall Gellens <[e-mail]>

> > Command Interactions
> >
> > It is possible for two or more actions to be executed by a script.  A
> > script MUST NOT perform any action before finishing execution, and
> > MUST check that the actions are consistent (according the the
> > following chart).
> 
> When we discussed parsing before executing (to trap syntax errors), 
> it was decided that this was a quality of implementation issue, not a 
> Sieve requirement.  Why should this be any different?

Well, here's the problem.  Reject and forward are mutually exclusive
(or, IMHO, should be, because I have a very hard time with the idea that 
a standards-track document should provide for bogus DSNs.)

If you reject a message, you have to throw it away; the DSN says you
did so.

It was decided some time ago that reject+keep was an absurd thing to do
and should not be allowed, right?

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA19236 for ietf-mta-filters-bks; Tue, 26 Jan 1999 15:57:49 -0800 (PST)
Received: from main (main.demo.ru [194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA19232 for <[e-mail]>; Tue, 26 Jan 1999 15:57:47 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 27 Jan 1999 03:01:47 +0300
Message-ID: <[e-mail]>
Date: Wed, 27 Jan 1999 02:59:40 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: Multiple actions in Sieve script.
References: <[e-mail]>
Content-Type: text/plain; charset=koi8-r
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>

Tim Showalter wrote:

> > Date: Wed, 27 Jan 1999 01:07:57 +0300
> > From: Alexey Melnikov <[e-mail]>
> > CC: Tim Showalter <[e-mail]>, [e-mail]
> >
> > Randall Gellens wrote:
> >
> > > At 3:45 AM +0300 1/26/99, Alexey Melnikov wrote:
> > >
> > > > 1). How to treat multiple FileInto - additive or selective
> > > > (first/last)?  my opinion: Additive, if server supports multiple
> > > > FileInto. Otherwise file into last.
> > >
> > > This reduces interoperability.  The script must be tailored to
> > > different environments.
> >
> > I am not insisting. I just want to hear consensus.  I really meant :
> > "Server MAY treat multiple FileInto additive, if it support multiple
> > FileInto. Otherwise file into last."  (I prefer file into last because
> > for me it is easier to redefine target mailbox later in a script).
>
> I oppose any meaning assigned to fileinto that is ambiguous depending on
> whether the implementation in question can handle multiple fileintos.
> In this part, I agree with Randy -- this really screws interoperability.
> Fileinto should be one way or the other, not both.

You are right, I forgot that there is currently no way to discover SIEVE
interpreter behaviour.

--
Best Regards,
Alexey Melnikov
+----------------------------------------------------+
|SMTP/POP3/IMAP4/ACAP  | Epsylon Technologies, Russia|
|servers creation team |     http://www.taxxi.com    |
|----------------------------------------------------|
|Imap Development Kit (my own product)               |
|http://194.87.43.111/homerus/mail/idk/index.htm     |
|----------------------------------------------------|
|Fax (in San Diego, California): 1 (619) 8393837     |
+----------------------------------------------------+





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA19038 for ietf-mta-filters-bks; Tue, 26 Jan 1999 15:35:42 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.2.74]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA19034 for <[e-mail]>; Tue, 26 Jan 1999 15:35:41 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA10252; Tue, 26 Jan 1999 15:37:36 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v04104201b2d4007f1b70@129.46.219.133>
In-Reply-To: <[e-mail]>
References: "Your message dated Tue, 26 Jan 1999 14:39:35 -0800" <v04104207b2d3f38202e3@129.46.219.133> <[e-mail]> <v04104204b2d2cff4aa15@129.46.219.133> <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Tue, 26 Jan 1999 15:39:38 -0800
To: Ned Freed <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Cc: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b7
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:11 PM -0800 1/26/99, Ned Freed wrote:

>> What's wrong with saying that some actions affect delivery status,
>> and other actions don't?  Actions that affect delivery status are:
>> keep, discard, forward, reject.  Actions that don't are: reply, mark
>> (if this extension is supported).
>
> The issue isn't so much with the present collection of actions (although
> I suppose we could go back and forth quite a bit about whether or
> not a reply implies reply and discard), but with future ones. Do we
> really want to allow each action someone adds to say whether or not
> it affects delivery status?
>
> If so, I guess I can live with it. But I'm dubious as to whether or
> not the complexity (remember, you're opposed to complexity ;-) is warranted.

I agree the issue is really with extensions.

My point is that we need some consistent basis for determining the 
default delivery status.  Even if we choose to ignore it, we really 
do have two classes of actions: those that explicitly affect delivery 
(that is, cause it or prevent it), and those that do not.  If we 
really want to say that delivery happens by default only if no action 
whatsoever is specified, what we are saying is that all actions which 
do not explicitly cause delivery implicitly cause non-delivery.  If 
this is really what we mean, than we need to state it.  Otherwise it 
is ambiguous and implementation-dependent. 

Personally, I think it would be counterintuitive and dangerous to 
make this the position, but I also feel that not being clear is much 
worse.

I think a clear and safe way of phrasing this is: Message are 
delivered unless an action is performed which explicitly prevents 
delivery (such as "reject").

We can separately talk about the default delivery mailbox: The 
default mailbox for delivery is "INBOX" on an IMAP server, the 
maildrop on a POP server.  If FileInto is supported, this can be used 
to alter the delivery mailbox.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18954 for ietf-mta-filters-bks; Tue, 26 Jan 1999 15:28:51 -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 PAA18950 for <[e-mail]>; Tue, 26 Jan 1999 15:28:50 -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 SAA03353; Tue, 26 Jan 1999 18:31:17 -0500 (EST)
Date: 26 Jan 1999 18:31:18 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: DES Serbian Soviet Clinton ammunition Semtex arrangements
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
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: 26 Jan 1999 17:59:24 -0500
> From: Tim Showalter <[e-mail]>
> 
> > Date: Tue, 26 Jan 1999 14:39:35 -0800
> > From: Randall Gellens <[e-mail]>
> 
> > At 10:30 PM -0800 1/25/99, Ned Freed wrote:
> > 
> > > I have a far bigger problem with the notion that somebody advanced
> > > of having multiple keeps deliver multiple copies of a message. This
> > > is unimplementable more often than not, as quite a few delivery
> > > schemes do duplicate address elimination, duplicate message
> > > elimination, or both. I cannot support such semantics, and I doubt
> > > I'm alone in this.
> > 
> > I don't think it makes sense (it isn't desirable) for multiple keeps 
> > to be different than a single keep.
> 
> Ned's saying it isn't possible.  That rules out desirability.
> 
> Is there any case where writing a message to a single mailbox twice is
> useful?

Please ignore this part of my message.  I appear to have gotten very
confused.  My apologies to both Randy and Ned for missing this point.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18922 for ietf-mta-filters-bks; Tue, 26 Jan 1999 15:27:08 -0800 (PST)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18918 for <[e-mail]>; Tue, 26 Jan 1999 15:27:08 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA12523; Tue, 26 Jan 1999 15:28:32 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v04104200b2d3fdbe758b@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04104207b2d3f38202e3@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Tue, 26 Jan 1999 15:23:36 -0800
To: Tim Showalter <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b7
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:59 PM -0500 1/26/99, Tim Showalter wrote:

>
>> I don't think it makes sense (it isn't desirable) for multiple keeps
>> to be different than a single keep.
>
> Ned's saying it isn't possible.  That rules out desirability.

Yes, we are in violent agreement that multiple keep = single keep.

>
> Is there any case where writing a message to a single mailbox twice is
> useful?

As you said, if it isn't possible it doesn't matter if it is useful.

>
>> > I do agree that the rule needs to be that the default is only 
>> taken when no
>> > other action of any sort, not just ones on a short list, has been.
>>
>> So if a script only does a reply, is the message kept or discarded?
>> Neither is specified, so one has to be the default action.
>
> Reply is not in draft 06, 05, or 04, because in LA, it was decided that
> reply was dangerous without some sort of vacation-style protection
> (limit number of replies in a single time period).
>
> However, "no other action of any sort" would imply that it is discarded.

OK, let's assume for the sake of argument that "mark" or "reply" or 
"foo" is a supported extension.  If a script does one of these and 
nothing else, is the message kept or discarded?  If we say it is 
discarded, that means discard is the default delivery state.  There 
is no such thing as no default delivery state.  There has to be one, 
because the code must either deliver the message or not.

>
> (I wouldn't mind having a vacation command that also implied a keep, but
> that's not what we're talking about here.)
>
>> What's wrong with saying that some actions affect delivery status,
>> and other actions don't?
>
> If you're having these things in a UI, it doesn't matter what we say, we
> can (we have to) assume the UI will just get it right.
>
> But for the people designing the UI, and the people implementing scripts
> using a text editor, the fewer special cases, the better.
>
> It is much easier to explain this:
>   "A message that generates no actions gets filed into your INBOX."
>
> than this:
>   "A mesasge that generates no delivery actions gets filed into your
>   INBOX.  Delivery actions are ones which change the disposition of the
>   message, and they are reject, forward, and fileinto."

Is it easier to explain?  Your simple statement doesn't answer the 
question "What happens if a script does 'foo' and nothing else?" 
This question does not go away, and it always has an answer.  Either 
we state the answer, or it is implementation dependent, which I think 
is a Bad Thing.

>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18914 for ietf-mta-filters-bks; Tue, 26 Jan 1999 15:26:47 -0800 (PST)
Received: from main (main.demo.ru [194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18910 for <[e-mail]>; Tue, 26 Jan 1999 15:26:45 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 27 Jan 1999 02:30:45 +0300
Message-ID: <[e-mail]>
Date: Wed, 27 Jan 1999 02:28:39 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: MTA filtering mailing list <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Content-Type: text/plain; charset=koi8-r
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>

Tim Showalter wrote:

> > > I do agree that the rule needs to be that the default is only taken when no
> > > other action of any sort, not just ones on a short list, has been.
> >
> > So if a script only does a reply, is the message kept or discarded?
> > Neither is specified, so one has to be the default action.
>
> Reply is not in draft 06, 05, or 04, because in LA, it was decided that
> reply was dangerous without some sort of vacation-style protection
> (limit number of replies in a single time period).
>
> However, "no other action of any sort" would imply that it is discarded.
>
> (I wouldn't mind having a vacation command that also implied a keep, but
> that's not what we're talking about here.)
>
> > What's wrong with saying that some actions affect delivery status,
> > and other actions don't?
>
> If you're having these things in a UI, it doesn't matter what we say, we
> can (we have to) assume the UI will just get it right.
>
> But for the people designing the UI, and the people implementing scripts
> using a text editor, the fewer special cases, the better.
>
> It is much easier to explain this:
>   "A message that generates no actions gets filed into your INBOX."
>
> than this:
>   "A message that generates no delivery actions gets filed into your
>   INBOX.  Delivery actions are ones which change the disposition of the
>   message, and they are reject, forward, and fileinto."

I agree in general, but IMHO standards are written for people who are
supposed to
read them.
It is not a big deal to add few additional checkbox or whatever.

--
Best Regards,
Alexey Melnikov
+----------------------------------------------------+
|SMTP/POP3/IMAP4/ACAP  | Epsylon Technologies, Russia|
|servers creation team |     http://www.taxxi.com    |
|----------------------------------------------------|
|Imap Development Kit (my own product)               |
|http://194.87.43.111/homerus/mail/idk/index.htm     |
|----------------------------------------------------|
|Fax (in San Diego, California): 1 (619) 8393837     |
+----------------------------------------------------+



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18846 for ietf-mta-filters-bks; Tue, 26 Jan 1999 15:19:48 -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 PAA18842 for <[e-mail]>; Tue, 26 Jan 1999 15:19:48 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-31 #30494) id <[e-mail]> for [e-mail]; Tue, 26 Jan 1999 15:21:03 PST
Date: Tue, 26 Jan 1999 15:11:24 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
In-reply-to: "Your message dated Tue, 26 Jan 1999 14:39:35 -0800" <v04104207b2d3f38202e3@129.46.219.133>
To: Randall Gellens <[e-mail]>
Cc: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
References: <[e-mail]> <v04104204b2d2cff4aa15@129.46.219.133> <[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>

> At 10:30 PM -0800 1/25/99, Ned Freed wrote:

> > [M]y problem is more with people assuming that fileinto is even possible

> FileInto is optional.  (It has to be, for example, for POP environments.)

Exactly. My point was that the implicit assumption behind all thie fileinto
discussion seems to be that it will be commonly if not universally available. I
don't think that's the case.

> > I have a far bigger problem with the notion that somebody advanced of having
> > multiple keeps deliver multiple copies of a message. This is unimplementable
> > more often than not, as quite a few delivery schemes do duplicate address
> > elimination, duplicate message elimination, or both. I cannot support such
> > semantics, and I doubt I'm alone in this.

> I don't think it makes sense (it isn't desirable) for multiple keeps
> to be different than a single keep.

Exactly my point as well.

> > As for the notion of removing keep as a default action, been there, done that.
> > The first mail filtering language I ever did started out this way. Simply put,
> > it was an unmitigated disaster. Default actions may be grotty, but they are an
> > essential safety net that the language has to have.

> > I do agree that the rule needs to be that the default is only taken when no
> > other action of any sort, not just ones on a short list, has been.

> So if a script only does a reply, is the message kept or discarded?
> Neither is specified, so one has to be the default action.

I can argue this either way. In some cases a reply really is all you want.

All I can say is that in the past I've treated generation of replies as
an action that overrides the default, and nobody has complained. Quite
different from when there was no default action, I assure you.

> What's wrong with saying that some actions affect delivery status,
> and other actions don't?  Actions that affect delivery status are:
> keep, discard, forward, reject.  Actions that don't are: reply, mark
> (if this extension is supported).

The issue isn't so much with the present collection of actions (although
I suppose we could go back and forth quite a bit about whether or
not a reply implies reply and discard), but with future ones. Do we
really want to allow each action someone adds to say whether or not
it affects delivery status?

If so, I guess I can live with it. But I'm dubious as to whether or
not the complexity (remember, you're opposed to complexity ;-) is warranted.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA18570 for ietf-mta-filters-bks; Tue, 26 Jan 1999 14:59:07 -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 OAA18566 for <[e-mail]>; Tue, 26 Jan 1999 14:59:06 -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 SAA03690; Tue, 26 Jan 1999 18:01:33 -0500 (EST)
Date: 26 Jan 1999 18:01:45 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Honduras Craig Livingstone BATF Albania White Water colonel Serbian
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
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: Wed, 27 Jan 1999 01:07:57 +0300
> From: Alexey Melnikov <[e-mail]>
> CC: Tim Showalter <[e-mail]>, [e-mail]
> 
> Randall Gellens wrote:
> 
> > At 3:45 AM +0300 1/26/99, Alexey Melnikov wrote:
> >
> > > 1). How to treat multiple FileInto - additive or selective
> > > (first/last)?  my opinion: Additive, if server supports multiple
> > > FileInto. Otherwise file into last.
> >
> > This reduces interoperability.  The script must be tailored to
> > different environments.
> 
> I am not insisting. I just want to hear consensus.  I really meant :
> "Server MAY treat multiple FileInto additive, if it support multiple
> FileInto. Otherwise file into last."  (I prefer file into last because
> for me it is easier to redefine target mailbox later in a script).

I oppose any meaning assigned to fileinto that is ambiguous depending on 
whether the implementation in question can handle multiple fileintos.
In this part, I agree with Randy -- this really screws interoperability.
Fileinto should be one way or the other, not both.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA18530 for ietf-mta-filters-bks; Tue, 26 Jan 1999 14:56:46 -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 OAA18525 for <[e-mail]>; Tue, 26 Jan 1999 14:56:45 -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 RAA03578; Tue, 26 Jan 1999 17:59:13 -0500 (EST)
Date: 26 Jan 1999 17:59:24 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Kibo spy Vince Foster NORAD Rule Psix FSF plutonium
To: [e-mail]
In-reply-to: <v04104207b2d3f38202e3@129.46.219.133>
Subject: Re: Multiple actions in Sieve script.
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, 26 Jan 1999 14:39:35 -0800
> From: Randall Gellens <[e-mail]>

> At 10:30 PM -0800 1/25/99, Ned Freed wrote:
> 
> > I have a far bigger problem with the notion that somebody advanced
> > of having multiple keeps deliver multiple copies of a message. This
> > is unimplementable more often than not, as quite a few delivery
> > schemes do duplicate address elimination, duplicate message
> > elimination, or both. I cannot support such semantics, and I doubt
> > I'm alone in this.
> 
> I don't think it makes sense (it isn't desirable) for multiple keeps 
> to be different than a single keep.

Ned's saying it isn't possible.  That rules out desirability.

Is there any case where writing a message to a single mailbox twice is
useful?

> > I do agree that the rule needs to be that the default is only taken when no
> > other action of any sort, not just ones on a short list, has been.
> 
> So if a script only does a reply, is the message kept or discarded? 
> Neither is specified, so one has to be the default action.

Reply is not in draft 06, 05, or 04, because in LA, it was decided that
reply was dangerous without some sort of vacation-style protection
(limit number of replies in a single time period).

However, "no other action of any sort" would imply that it is discarded.

(I wouldn't mind having a vacation command that also implied a keep, but 
that's not what we're talking about here.)

> What's wrong with saying that some actions affect delivery status, 
> and other actions don't?

If you're having these things in a UI, it doesn't matter what we say, we 
can (we have to) assume the UI will just get it right.

But for the people designing the UI, and the people implementing scripts 
using a text editor, the fewer special cases, the better.

It is much easier to explain this:
  "A message that generates no actions gets filed into your INBOX."

than this:
  "A mesasge that generates no delivery actions gets filed into your
  INBOX.  Delivery actions are ones which change the disposition of the
  message, and they are reject, forward, and fileinto."

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA18389 for ietf-mta-filters-bks; Tue, 26 Jan 1999 14:42:50 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA18385 for <[e-mail]>; Tue, 26 Jan 1999 14:42:49 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA12593; Tue, 26 Jan 1999 14:44:38 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v04104207b2d3f38202e3@129.46.219.133>
In-Reply-To: <[e-mail]>
References: "Your message dated Mon, 25 Jan 1999 22:56:44 -0500" <[e-mail]> <v04104204b2d2cff4aa15@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Tue, 26 Jan 1999 14:39:35 -0800
To: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b7
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:30 PM -0800 1/25/99, Ned Freed wrote:

> [M]y problem is more with people assuming that fileinto is even possible

FileInto is optional.  (It has to be, for example, for POP environments.)

> I have a far bigger problem with the notion that somebody advanced of having
> multiple keeps deliver multiple copies of a message. This is unimplementable
> more often than not, as quite a few delivery schemes do duplicate address
> elimination, duplicate message elimination, or both. I cannot support such
> semantics, and I doubt I'm alone in this.

I don't think it makes sense (it isn't desirable) for multiple keeps 
to be different than a single keep.

> As for the notion of removing keep as a default action, been there, 
> done that.
> The first mail filtering language I ever did started out this way. 
> Simply put,
> it was an unmitigated disaster. Default actions may be grotty, but 
> they are an
> essential safety net that the language has to have.
>
> I do agree that the rule needs to be that the default is only taken when no
> other action of any sort, not just ones on a short list, has been.

So if a script only does a reply, is the message kept or discarded? 
Neither is specified, so one has to be the default action.

What's wrong with saying that some actions affect delivery status, 
and other actions don't?  Actions that affect delivery status are: 
keep, discard, forward, reject.  Actions that don't are: reply, mark 
(if this extension is supported).

Then, we can say that the default delivery status is keep.

>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA18381 for ietf-mta-filters-bks; Tue, 26 Jan 1999 14:42:44 -0800 (PST)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA18377 for <[e-mail]>; Tue, 26 Jan 1999 14:42:42 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA12572; Tue, 26 Jan 1999 14:44:29 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v04104206b2d3f30ee7c0@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04104204b2d2cff4aa15@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Tue, 26 Jan 1999 14:34:22 -0800
To: Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b10
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:56 PM -0500 1/25/99, Tim Showalter wrote:

> I thought that the way I would use Sieve is that I would file an
> incoming message into *all* mailboxes that it matched, based on to/cc
> headers.  So if there was a message to imap, ietf-mta-filters, and and
> tjs, I'd file the message into inbox.imap, inbox.mta-filters, and inbox,
> allowing Cyrus to kill the duplicates.

Thanks for explaining this.  It does make sense, assuming you have an 
environment where a message can be delivered into multiple mailboxes 
simultaneously and duplicates are automatically deleted.  If either 
of these is lacking, you'd have a problem.  My environments lack both.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA18147 for ietf-mta-filters-bks; Tue, 26 Jan 1999 14:09:00 -0800 (PST)
Received: from main (main.demo.ru [194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA18142 for <[e-mail]>; Tue, 26 Jan 1999 14:08:58 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 27 Jan 1999 01:10:46 +0300
Message-ID: <[e-mail]>
Date: Wed, 27 Jan 1999 01:08:35 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Lawrence Greenfield <[e-mail]>
CC: [e-mail]
Subject: Re: Multiple actions in Sieve script.
References: <[e-mail]> <[e-mail]> <[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>

Lawrence Greenfield wrote:

> [...]
>    2). Can FileInto have multiple parameters? How treat them if the
>    answer is yes?
>
>    my opinion: Yes. Treat FileInto with multiple parameters as atomic
>    operation [as Matthew proposed] (the alternative is to treat it as
>    multiple operations).
>
> I'm against treating a fileinto with multiple parameters as an atomic
> operation.  My implementation allows such a construct (it treats it
> identically to multiple fileinto actions) and it would be a
> substantial burden to have to lock mailboxes, verify that a fileinto
> can be done to all of them, perform the delivery, and unlock
> mailboxes.  This could be very expensive on many implementations.

After thinking more about this I think you are right.
However "atomic multiple FileInto" may be interesting as a SIEVE
extension.

--
Best Regards,
Alexey Melnikov
+----------------------------------------------------+
|SMTP/POP3/IMAP4/ACAP  | Epsylon Technologies, Russia|
|servers creation team |     http://www.taxxi.com    |
|----------------------------------------------------|
|Imap Development Kit (my own product)               |
|http://194.87.43.111/homerus/mail/idk/index.htm     |
|----------------------------------------------------|
|Fax (in San Diego, California): 1 (619) 8393837     |
+----------------------------------------------------+





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA18143 for ietf-mta-filters-bks; Tue, 26 Jan 1999 14:08:59 -0800 (PST)
Received: from main (main.demo.ru [194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA18138 for <[e-mail]>; Tue, 26 Jan 1999 14:08:56 -0800 (PST)
Received: FROM taxxi.com ([194.87.43.61]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 27 Jan 1999 01:10:15 +0300
Message-ID: <[e-mail]>
Date: Wed, 27 Jan 1999 01:07:57 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Randall Gellens <[e-mail]>
CC: Tim Showalter <[e-mail]>, [e-mail]
Subject: Re: Multiple actions in Sieve script.
References: <[e-mail]> <v04104205b2d2d28b45d3@129.46.219.133>
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>

Randall Gellens wrote:

> At 3:45 AM +0300 1/26/99, Alexey Melnikov wrote:
>
> > 1). How to treat multiple FileInto - additive or selective (first/last)?
> > my opinion: Additive, if server supports multiple FileInto. Otherwise file
> > into last.
>
> This reduces interoperability.  The script must be tailored to
> different environments.

I am not insisting. I just want to hear consensus.
I really meant : "Server MAY treat multiple FileInto additive, if it support
multiple FileInto. Otherwise file
into last."
(I prefer file into last because for me it is easier to redefine target mailbox
later in a script).

> > 2). Can FileInto have multiple parameters? How treat them if the answer is
> > yes?
> > my opinion: Yes. Treat FileInto with multiple parameters as atomic operation
> > [as Matthew proposed] (the alternative is to treat it as multiple
> > operations).
>
> (Same comment).
> >
> > 3). What to do if fileinto fails?
>
> File into default mailbox.  That is the safest action.

Right. I didn't answer this question because Matthew was talking about FileInto
that does "all or nothing". I have no strong opinion.

--
Best Regards,
Alexey Melnikov
+----------------------------------------------------+
|SMTP/POP3/IMAP4/ACAP  | Epsylon Technologies, Russia|
|servers creation team |     http://www.taxxi.com    |
|----------------------------------------------------|
|Imap Development Kit (my own product)               |
|http://194.87.43.111/homerus/mail/idk/index.htm     |
|----------------------------------------------------|
|Fax (in San Diego, California): 1 (619) 8393837     |
+----------------------------------------------------+





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA06756 for ietf-mta-filters-bks; Mon, 25 Jan 1999 22:51:57 -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 WAA06752 for <[e-mail]>; Mon, 25 Jan 1999 22:51:56 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.2-31 #30494) id <[e-mail]> for [e-mail]; Mon, 25 Jan 1999 22:53:13 PST
Date: Mon, 25 Jan 1999 22:30:19 -0800 (PST)
From: Ned Freed <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
In-reply-to: "Your message dated Mon, 25 Jan 1999 22:56:44 -0500" <[e-mail]>
To: Tim Showalter <[e-mail]>
Cc: Randall Gellens <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
References: <v04104204b2d2cff4aa15@129.46.219.133>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Date: Mon, 25 Jan 1999 18:01:03 -0800
> > From: Randall Gellens <[e-mail]>

> > If we instead define a FileInto which takes multiple mailboxes, or
> > has any other semantics, we gain some power but reduce either
> > interoperability or deployability.

> I guess this is the central point of contention.  Other than Randy, is
> there anyone else who sees a problem with this?  I know Larry's having
> to do hacking on deliver, but it wasn't much of an issue for us.

I have something of a problem with it. However, my problem is more with people
assuming that fileinto is even possible, and less with whether it will only
work once. I support a broad range of mailboxes formats and delivery methods.
Plenty of them make it effectively impossible to implement fileinto at all,
ever. Of those where fileinto is possible, there's only one case where it will
only work once, and I think I see a way to fix it.

I have a far bigger problem with the notion that somebody advanced of having
multiple keeps deliver multiple copies of a message. This is unimplementable
more often than not, as quite a few delivery schemes do duplicate address
elimination, duplicate message elimination, or both. I cannot support such
semantics, and I doubt I'm alone in this.

As for the notion of removing keep as a default action, been there, done that.
The first mail filtering language I ever did started out this way. Simply put,
it was an unmitigated disaster. Default actions may be grotty, but they are an
essential safety net that the language has to have.

I do agree that the rule needs to be that the default is only taken when no
other action of any sort, not just ones on a short list, has been.

				Ned


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA25688 for ietf-mta-filters-bks; Mon, 25 Jan 1999 19:54:14 -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 TAA25681 for <[e-mail]>; Mon, 25 Jan 1999 19:54:13 -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 WAA22473; Mon, 25 Jan 1999 22:56:36 -0500 (EST)
Date: 25 Jan 1999 22:56:44 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Mossad [Hello to all my fans in domestic surveillance] Craig Livingstone radar Khaddafi class struggle Honduras
To: Randall Gellens <[e-mail]>
Cc: [e-mail]
In-reply-to: <v04104204b2d2cff4aa15@129.46.219.133>
Subject: Re: Multiple actions in Sieve script.
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: Mon, 25 Jan 1999 18:01:03 -0800
> From: Randall Gellens <[e-mail]>

> If we instead define a FileInto which takes multiple mailboxes, or 
> has any other semantics, we gain some power but reduce either 
> interoperability or deployability.

I guess this is the central point of contention.  Other than Randy, is
there anyone else who sees a problem with this?  I know Larry's having
to do hacking on deliver, but it wasn't much of an issue for us.

> > I guess that if I write my scripts well I will typically file on
> > Return-Path, so it can be dealt with.
> 
> I don't understand this comment.
> 
> I use Sieve to process all my incoming mail at work.  The Sieve 
> script is close to 300 lines, and files mostly based on envelope 
> return-path. 
> 
> How does this affect the need for multiple FileInto?

I thought that the way I would use Sieve is that I would file an
incoming message into *all* mailboxes that it matched, based on to/cc
headers.  So if there was a message to imap, ietf-mta-filters, and and
tjs, I'd file the message into inbox.imap, inbox.mta-filters, and inbox,
allowing Cyrus to kill the duplicates.  That way, since messages that
have to bounce off a majordomo or a sendmail get bogged down, I may get
messages in the right place very quickly.

If I don't have multiple fileinto, I can't do that.  I have to split
mail based on the return-path (and hope that I don't get too many weird
things from mailers that use variable return-paths).

So here's an obscure case where multiple fileinto is useful.  Sendmail
has this "MeToo" option, right?  If a message goes to an alias that
expands to contain an address (say tjs@andrew) AND tjs@andrew is on the
To line, unless MeToo is set, sendmail will just send one copy of the
message.  This isn't very relavant most of the time (only when the
initial MTA is also the MTA expanding the alias) and such behavior is
not standards compliant, but it does happen.

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA22698 for ietf-mta-filters-bks; Mon, 25 Jan 1999 19:38:16 -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 TAA22694 for <[e-mail]>; Mon, 25 Jan 1999 19:38:15 -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 WAA22523; Mon, 25 Jan 1999 22:40:37 -0500 (EST)
Date: 25 Jan 1999 22:40:45 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Rule Psix DES Ft. Bragg strategic North Korea PLO class struggle
To: [e-mail]
In-reply-to: <v04104207b2d2d3848041@129.46.219.133>
Subject: Re: Language for conflicting actions
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: Mon, 25 Jan 1999 18:20:00 -0800
> From: Randall Gellens <[e-mail]>

> Every argument for adding this tweak or allowing that extra behavior 
> hurts the prime goal.  Is this what we want?

I have assumed since the beginning that multiple fileintos were no
problem whatsoever.  I was rather surprised that you don't believe this
is the case.

> > I'm opposed to adding more commands to the language that have nearly
> > identical semantics to fileinto.  Regardless, we're going to have to
> > deal with multiple fileinto's being executed.
> 
> Please, let's go with something simple to understand and implement. 
> To me, that is one FileInto per message. 

It is *not* simple to understand.  We *will* get users asking "Why
doesn't this work?"  If I tell the MTA to do two things and it does one,
how is it easier to understand?

I don't consider the implementation complexity to be that great.

> > Two "keep"'s cause a message to be delivered multiple times to the
> > default location.  Two "fileinto"'s cause a message to be filed into
> > the specified folders.  Two "redirect"'s cause a message to be
> > forwarded to multiple addresses.
> 
> Now we're getting fancy, and in addition I'm not sure these semantics 
> are desirable.  I can see Sieve scripts which execute multiple 
> "keep"s, for different tests, with the intent that the message be 
> kept, not duplicated.  Of what use is duplicating the message, 
> especially into the same mailbox?

I'm not particularly sure that two "keeps" should deposit the message
into the main mailbox; I don't believe that writing one message to a
mailbox twice should ever actually do that.  But I do believe that
multiple redirects are not much of a problem.

> We're adding complexity and reducing interoperability and/or 
> deployability.  For what gain?
> 
> > The implicit keep is only performed when no actions were executed by
> > the script.
> 
> So a script that does only a "Reply" causes the message to be 
> discarded?  Does a DSN get generated?  Very odd to get a reply and a 
> failure DSN for the same message.

No, a DSN should not be generated.  That's what reject is for.  Is that
not clear in the spec?  (Should I fix it?)

If we're going to have an implicit keep, the only way it's going to make 
sense is if it happens when zero other actions are done.  If you don't
want an implicit keep, do a discard.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA22303 for ietf-mta-filters-bks; Mon, 25 Jan 1999 19:35:13 -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 TAA22294 for <[e-mail]>; Mon, 25 Jan 1999 19:35:11 -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 WAA21541; Mon, 25 Jan 1999 22:37:35 -0500 (EST)
Date: 25 Jan 1999 22:37:42 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Clinton NSA assassination Treasury SEAL Team 6 radar Cocaine
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
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, 26 Jan 1999 03:45:10 +0300
> From: Alexey Melnikov <[e-mail]>

> >> Incidentially, I really think we should dump implicit keep. If this is
> >> not the case, I'd really like to know it now.
> >
> >What does that mean?  Surely the default action must still be keep.
> 
> I agree.  I still think it is quite clear when implicit keep will be
> performed (no action or run-time failure).

The current draft doesn't say no action, it says no fileinto, keep, or
reject.  I wish it said no action.

Actually, that's a bug in the draft that I missed: as written, an
implicit keep happens even if there's a discard.

The wording as specified will interact poorly with extensions, but it
may not be unworkable.

> As I understand we are trying to solve few different problems:
> 
> 1). How to treat multiple FileInto - additive or selective (first/last)?
> my opinion: Additive, if server supports multiple FileInto. Otherwise file
> into last.

This is inherently ambiguous, and a bad idea.  If we have to allow
non-multiple fileinto, we should split it into yet another action.
(No, I don't like the idea.)

> 2). Can FileInto have multiple parameters? How treat them if the
> answer is yes?  my opinion: Yes. Treat FileInto with multiple
> parameters as atomic operation [as Matthew proposed] (the alternative
> is to treat it as multiple operations).

Atomic operations raise the implementation complexity very
significantly.  I believe we have already punted on this.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA15338 for ietf-mta-filters-bks; Mon, 25 Jan 1999 18:16:09 -0800 (PST)
Received: from emrys.qualcomm.com (emrys.qualcomm.com [129.46.2.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15334 for <[e-mail]>; Mon, 25 Jan 1999 18:15:58 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by emrys.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id SAA16732; Mon, 25 Jan 1999 18:17:45 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v04104207b2d2d3848041@129.46.219.133>
In-Reply-To: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Mon, 25 Jan 1999 18:20:00 -0800
To: Lawrence Greenfield <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Language for conflicting actions
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b7
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 getting a sinking feeling that we are heading towards a train 
wreck.  Sieve is getting more complicated the longer these 
discussions go on, and that means more problems.

I really thought our prime goal was to specify something simple 
enough to solve a good chunk of the problem and get it standardized 
NOW.

Every argument for adding this tweak or allowing that extra behavior 
hurts the prime goal.  Is this what we want?

At 8:29 PM -0500 1/25/99, Lawrence Greenfield wrote:

> I'm opposed to adding more commands to the language that have nearly
> identical semantics to fileinto.  Regardless, we're going to have to
> deal with multiple fileinto's being executed.

Please, let's go with something simple to understand and implement. 
To me, that is one FileInto per message. 

If Sieve gets fancy, your script won't run on my servers.  If that's 
OK, why do we need Sieve at all?  Just let each server implement 
whatever script rules it likes.

> Tied into this discussion is error messages.  One suggestion here at
> CMU was to have the Sieve agent modify a header in a default-delivery
> message to indicate a problem in a Sieve script...  Another
> possibility is to send a DSN to the person.

I'd rather not discuss error messages at this stage.  Every time this 
has come up before, we have punted.  I still think we can defer this 
until we have base RFC.

>
> ---
> Command Interactions
>
> It is possible for two or more actions to be executed by a script.  A
> script MUST NOT perform any action before finishing execution, and
> MUST check that the actions are consistent (according the the
> following chart).

When we discussed parsing before executing (to trap syntax errors), 
it was decided that this was a quality of implementation issue, not a 
Sieve requirement.  Why should this be any different?

(My implementation does a full parse before executing anything, but I 
don't hold actions.  I could do so, and it would be really easy for 
things like FileInto where I only honor the last one anyway, but that 
gets complicated when multiple Forwards and such are done.)

> Two "keep"'s cause a message to be delivered multiple times to the
> default location.  Two "fileinto"'s cause a message to be filed into
> the specified folders.  Two "redirect"'s cause a message to be
> forwarded to multiple addresses.

Now we're getting fancy, and in addition I'm not sure these semantics 
are desirable.  I can see Sieve scripts which execute multiple 
"keep"s, for different tests, with the intent that the message be 
kept, not duplicated.  Of what use is duplicating the message, 
especially into the same mailbox?

We're adding complexity and reducing interoperability and/or 
deployability.  For what gain?

> The implicit keep is only performed when no actions were executed by
> the script.

So a script that does only a "Reply" causes the message to be 
discarded?  Does a DSN get generated?  Very odd to get a reply and a 
failure DSN for the same message.


>
> ---
> Run-time Errors
>
> It is impossible to prevent run-time errors from occuring.
> Implementations are encouraged to statically check Sieve scripts
> upon submission to minimize the chances of errors during run-time.
>
> Errors may include:
> - quota or ACL problems
> - incompatible actions
> - too many actions (too many redirects by site policy)
>
> If a run-time error occurs, the implementation should attempt to
> perform a "keep" (disregarding any other actions) and should send a
> message to the user, either via electronic mail or another
> communication channel.

Let's not specify how the user is to be notified.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA15149 for ietf-mta-filters-bks; Mon, 25 Jan 1999 18:03:25 -0800 (PST)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15145 for <[e-mail]>; Mon, 25 Jan 1999 18:03:24 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id SAA17611; Mon, 25 Jan 1999 18:04:57 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v04104205b2d2d28b45d3@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Mon, 25 Jan 1999 18:03:10 -0800
To: Alexey Melnikov <[e-mail]>, Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b7
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:45 AM +0300 1/26/99, Alexey Melnikov wrote:

> 1). How to treat multiple FileInto - additive or selective (first/last)?
> my opinion: Additive, if server supports multiple FileInto. Otherwise file
> into last.

This reduces interoperability.  The script must be tailored to 
different environments.

>
> 2). Can FileInto have multiple parameters? How treat them if the answer is
> yes?
> my opinion: Yes. Treat FileInto with multiple parameters as atomic operation
> [as Matthew proposed] (the alternative is to treat it as multiple 
> operations).

(Same comment).
>
> 3). What to do if fileinto fails?

File into default mailbox.  That is the safest action.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA15140 for ietf-mta-filters-bks; Mon, 25 Jan 1999 18:02:46 -0800 (PST)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15136 for <[e-mail]>; Mon, 25 Jan 1999 18:02:45 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id SAA17341; Mon, 25 Jan 1999 18:04:37 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v04104204b2d2cff4aa15@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04103e02b2ced9522cb0@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Mon, 25 Jan 1999 18:01:03 -0800
To: Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b7
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 7:03 PM -0500 1/25/99, Tim Showalter wrote:

> I understand your position, but I don't like it.  I don't mean to make
> this sound like a flame, but I'm really not happy about arbitrary limits
> on numbers of actions, especially ones like FileInto which can be
> considered to be harmless.  I don't know how common this problem is
> going to be, but I really thought it was nonexistant until you brought
> it up.

I thought the goal of Sieve was a language that was powerful enough 
to be useful, and simple enough to be safe and easily implemented.

I have one working Sieve implementation, and another in development 
(same core code) that use a plug-in API model.  The Sieve agent is 
called during (but before) final delivery.  It is passed the incoming 
message, including envelope.  Sieve gets to reject the message or 
alter the mailbox into which it will be filed.  (It can also forward 
or reply, but those actions do not effect message disposition as far 
as the plug-in API is concerned.)

I doubt this environment is unique.

If we define a FileInto action which takes one mailbox name as a 
parameter and causes the message to be delivered into that mailbox 
instead of the default, we have something that can be implemented 
very widely.

If we instead define a FileInto which takes multiple mailboxes, or 
has any other semantics, we gain some power but reduce either 
interoperability or deployability.

How important is the ability to simultaneously deliver into multiple 
mailboxes?  If we don't absolutely have to have it, I say we leave it 
for an extension.  If it is so vital as to justify delay and reduced 
interoperability or deployability, please explain why, because I just 
don't see it.

>
> I guess that if I write my scripts well I will typically file on
> Return-Path, so it can be dealt with.

I don't understand this comment.

I use Sieve to process all my incoming mail at work.  The Sieve 
script is close to 300 lines, and files mostly based on envelope 
return-path. 

How does this affect the need for multiple FileInto?




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA14767 for ietf-mta-filters-bks; Mon, 25 Jan 1999 17:38:12 -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 RAA14763 for <[e-mail]>; Mon, 25 Jan 1999 17:38:11 -0800 (PST)
Received: from pounce.cc.cmu.edu (POUNCE.CC.CMU.EDU [128.2.36.181]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id UAA16397; Mon, 25 Jan 1999 20:40:33 -0500 (EST)
Date: 25 Jan 1999 20:40:36 -0500
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.1
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.106)
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>

[...]
   2). Can FileInto have multiple parameters? How treat them if the
   answer is yes?

   my opinion: Yes. Treat FileInto with multiple parameters as atomic
   operation [as Matthew proposed] (the alternative is to treat it as
   multiple operations).

I'm against treating a fileinto with multiple parameters as an atomic
operation.  My implementation allows such a construct (it treats it
identically to multiple fileinto actions) and it would be a
substantial burden to have to lock mailboxes, verify that a fileinto
can be done to all of them, perform the delivery, and unlock
mailboxes.  This could be very expensive on many implementations.

Larry



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA14599 for ietf-mta-filters-bks; Mon, 25 Jan 1999 17:27:11 -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 RAA14594 for <[e-mail]>; Mon, 25 Jan 1999 17:27:10 -0800 (PST)
Received: from pounce.cc.cmu.edu (POUNCE.CC.CMU.EDU [128.2.36.181]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id UAA15792; Mon, 25 Jan 1999 20:29:32 -0500 (EST)
Date: 25 Jan 1999 20:29:34 -0500
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.1
To: [e-mail]
Subject: Language for conflicting actions
Mime-Version: 1.0 (generated by tm-edit 7.106)
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 opposed to adding more commands to the language that have nearly
identical semantics to fileinto.  Regardless, we're going to have to
deal with multiple fileinto's being executed.

Tied into this discussion is error messages.  One suggestion here at
CMU was to have the Sieve agent modify a header in a default-delivery
message to indicate a problem in a Sieve script...  Another
possibility is to send a DSN to the person.

---
Command Interactions

It is possible for two or more actions to be executed by a script.  A
script MUST NOT perform any action before finishing execution, and
MUST check that the actions are consistent (according the the
following chart).

An implementation MAY choose to support multiple compatible actions.
If so, it should either execute all actions or none (barring error
conditions outside the control of the Sieve interpreter).  If the
implementation cannot execute all actions, it should treat it as a
run-time error.

For instance, an implementation may choose to support "redirect" and
"fileinto" together, but not multiple "fileinto" actions.  In that
case, any script that attempts multiple "fileinto" actions causes a
run-time error.

	   keep      fileinto    redirect   discard    reject

keep       compat.   compat.     compat.    no         no

fileinto   compat.   compat.     compat.    no         no

redirect   compat.   compat.     compat.    no         no

discard    no        no          no         yes        no

reject     no        no          no         no         no

Two "keep"'s cause a message to be delivered multiple times to the
default location.  Two "fileinto"'s cause a message to be filed into
the specified folders.  Two "redirect"'s cause a message to be
forwarded to multiple addresses.

The implicit keep is only performed when no actions were executed by
the script.

---
Run-time Errors

It is impossible to prevent run-time errors from occuring.
Implementations are encouraged to statically check Sieve scripts
upon submission to minimize the chances of errors during run-time.

Errors may include:
- quota or ACL problems
- incompatible actions
- too many actions (too many redirects by site policy)

If a run-time error occurs, the implementation should attempt to
perform a "keep" (disregarding any other actions) and should send a
message to the user, either via electronic mail or another
communication channel.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA13862 for ietf-mta-filters-bks; Mon, 25 Jan 1999 16:43:28 -0800 (PST)
Received: from baikonur.demo.ru (www.demo.ru [194.87.43.111]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA13858 for <[e-mail]>; Mon, 25 Jan 1999 16:43:25 -0800 (PST)
Received: from taxxi.com ([194.87.43.88]) by baikonur.demo.ru (Netscape Messaging Server 3.6)  with ESMTP id 146; Tue, 26 Jan 1999 03:45:59 +0300
Message-ID: <[e-mail]>
Date: Tue, 26 Jan 1999 03:45:10 +0300
From: Alexey Melnikov <[e-mail]>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: ru,en-US
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: Randall Gellens <[e-mail]>, [e-mail]
Subject: Re: Multiple actions in Sieve script.
References: <[e-mail]>
Content-Type: text/plain; charset=koi8-r
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>

Randall wrote:

>> Incidentially, I really think we should dump implicit keep. If this is
>> not the case, I'd really like to know it now.
>
>What does that mean?  Surely the default action must still be keep.

I agree.
I still think it is quite clear when implicit keep will be performed (no
action or run-time failure).


Tim wrote:

>My intent was that many "FileInto"s can be obeyed IF the server supports
>FileInto at all.

I agree.

>If the server supports "FileOnlyInto", only one invocation works (either
>the first or the last).



Tim Showalter wrote:

> > >
> > > I suggest "FileInto" and "FileOnlyInto", or possibly, add an optional
> > > tagged argument to Fileinto, ":only".
> >
> > Is the intent of the "only" part to prevent also doing a non-only?
>
> No.  I wasn't clear.  I find the terminology "FileInto" and "CopyInto"
> confusing because the terms do not clearly specify what they do.
>
> Actually, neither do "FileOnlyInto" and "FileInto" or whatever.  Blah.
>
> My intent was that many "FileInto"s can be obeyed IF the server supports
> FileInto at all.
>
> If the server supports "FileOnlyInto", only one invocation works (either
> the first or the last).
>
> Ack.  Perhaps "MoveInto" is best, and the last one is the only one
> obeyed.  I dunno.

I would like to see only one FileInto action that may take a list of mailboxes
as parameter (and may be :only argument). If server doesn't support multiple
FileInto it may file into first mailbox only and ignore all other mailboxes
and other fileinto's.

As I understand we are trying to solve few different problems:

1). How to treat multiple FileInto - additive or selective (first/last)?
my opinion: Additive, if server supports multiple FileInto. Otherwise file
into last.

2). Can FileInto have multiple parameters? How treat them if the answer is
yes?
my opinion: Yes. Treat FileInto with multiple parameters as atomic operation
[as Matthew proposed] (the alternative is to treat it as multiple operations).

3). What to do if fileinto fails?

--
Best Regards,
Alexey Melnikov
+----------------------------------------------------+
|SMTP/POP3/IMAP4/ACAP  | Epsylon Technologies, Russia|
|servers creation team |     http://www.taxxi.com    |
|----------------------------------------------------|
|Imap Development Kit (my own product)               |
|http://194.87.43.111/homerus/mail/idk/index.htm     |
|----------------------------------------------------|
|Fax (in San Diego, California): 1 (619) 8393837     |
+----------------------------------------------------+




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA13359 for ietf-mta-filters-bks; Mon, 25 Jan 1999 16:10:28 -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 QAA13355 for <[e-mail]>; Mon, 25 Jan 1999 16:10:26 -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 TAA11796; Mon, 25 Jan 1999 19:12:47 -0500 (EST)
Date: 25 Jan 1999 19:12:56 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: genetic Cocaine North Korea CIA nuclear Rule Psix Legion of Doom
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
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: 22 Jan 1999 02:56:44 -0500
> From: Tim Showalter <[e-mail]>

> So let's dump the implicit keep.  We're still arguing about it, no one
> will ever understand it, it's hard to explain, it's hard to decide when
> it shouldn't happen, and it's not going to save anyone.

Walter has bugged me about this and I think I was wrong.  Part of my
reasoning was that FLAMES doesn't have an implicit keep.  But FLAMES
*does* have an implicit keep in the standard function library, more or
less (it's in the cookbook fill-in-the-blank functions, but not in the
language itself).

I'd like to see the way keep is defined changed to be either Tony's
proposal, or what I believe Larry wants (zero actions == implicit
keep).

(FLAMES is the Filtering Language for the Anddrew MEsssaging System, our 
legacy mail system.  It's quite popular among those who learned to use
it.)

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA13235 for ietf-mta-filters-bks; Mon, 25 Jan 1999 16:00:50 -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 QAA13231 for <[e-mail]>; Mon, 25 Jan 1999 16:00:48 -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 TAA11210; Mon, 25 Jan 1999 19:03:10 -0500 (EST)
Date: 25 Jan 1999 19:03:17 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: South Africa Clinton Ft. Meade KGB FSF NSA CIA
To: Randall Gellens <[e-mail]>
Cc: [e-mail]
In-reply-to: <v04103e02b2ced9522cb0@129.46.219.133>
Subject: Re: Multiple actions in Sieve script.
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: Fri, 22 Jan 1999 17:48:50 -0800
> From: Randall Gellens <[e-mail]>

> At 8:24 PM -0500 1/22/99, Tim Showalter wrote:
> 
> > No.  I wasn't clear.  I find the terminology "FileInto" and "CopyInto"
> > confusing because the terms do not clearly specify what they do.
> >
> > Actually, neither do "FileOnlyInto" and "FileInto" or whatever.  Blah.
> >
> > My intent was that many "FileInto"s can be obeyed IF the server supports
> > FileInto at all.
> >
> > If the server supports "FileOnlyInto", only one invocation works (either
> > the first or the last).
> >
> > Ack.  Perhaps "MoveInto" is best, and the last one is the only one
> > obeyed.  I dunno.
> 
> Are we at least agreed that we need one action which indicates into 
> which mailbox the message should be delivered, and that if more than 
> one of these actions is executed, only one is actually obeyed?  [...]

My problem is that I believe multiple fileintos will be useful, and a
single-use fileinto is a limited case, i.e., fitting into another
architechture which had limits on such things.  I am not happy about
adding multiple fileinto variants to make up for the prohibition on
multiple fileintos.

> Or do some people disagree, and feel we need an action (optional to 
> support) which can be invoked any number of times, each time causing 
> the message to be delivered into a mailbox?

I consider this important, but FLAMES and Cyrus both have duplicate
delivery supression such that multiple messages with the same
Message-IDs are only put in the mailbox once.

> The second case is harder to name, because we have a FileInto (must 
> implement) and something else which is optional, call it 
> OptionalFileInto.  [...]

Fileinto is not mandatory.

> A script can be expected to execute one or more 
> OptionalFileIntos on systems which support it, and alternatively one 
> FileInto on systems which do not support OptionalFileInto.

I think this situation sucks.

I understand your position, but I don't like it.  I don't mean to make
this sound like a flame, but I'm really not happy about arbitrary limits
on numbers of actions, especially ones like FileInto which can be
considered to be harmless.  I don't know how common this problem is
going to be, but I really thought it was nonexistant until you brought
it up.

I guess that if I write my scripts well I will typically file on
Return-Path, so it can be dealt with.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13036 for ietf-mta-filters-bks; Mon, 25 Jan 1999 15:44:43 -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 PAA13031 for <[e-mail]>; Mon, 25 Jan 1999 15:44:40 -0800 (PST)
Received: from nil.andrew.cmu.edu (NIL.ANDREW.CMU.EDU [128.2.232.95]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id SAA10442; Mon, 25 Jan 1999 18:47:00 -0500 (EST)
Date: 25 Jan 1999 18:46:59 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Soviet North Korea Croatian Ft. Bragg Saddam Hussein assassination fissionable
To: [e-mail]
Subject: draft-showalter-sieve-06.txt
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: multipart/mixed; boundary="Multipart_Mon_Jan_25_18:46:59_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_Mon_Jan_25_18:46:59_1999-1
Content-Type: text/plain; charset=US-ASCII

Submitted for your approval:

(If this message is mangled in transmission, I blame the parts of the
MUA I use that I didn't write, but please let me know if that's the
case.)

Known problems with this draft are the grammar and anything we've
discussed this week.  When we hit some sort of consensus, I'll do a rev.

I have sumitted this to the I-D repository and asked them to number it
-06.  If they number it -05 anyway, I may just submit it again.

-- Tim


--Multipart_Mon_Jan_25_18:46:59_1999-1
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="sieve.txt"
Content-Transfer-Encoding: 7bit







Network Working Group                                       T. Showalter
Internet Draft: Sieve                                    Carnegie Mellon
Document: draft-showalter-sieve-06.txt                  January 25, 1999
Expire in six months


                    Sieve: A Mail Filtering Language


Status of this memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   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 1998.  All Rights Reserved.

Abstract

   This document describes a mail filtering language for filtering
   messages at time of final delivery.  It is designed to be independent
   of protocol, and 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 1]

Internet DRAFT                   Sieve                  January 25, 1999





                           Table of Contents



Status of this memo ...............................................    1
Copyright Notice ..................................................    1
Abstract ..........................................................    1
0. Meta-information on this draft .................................    4
0.1. Discussion ...................................................    4
0.2. Known Problems ...............................................    4
0.2.1. Probable Extensions ........................................    4
0.2.2. Known Bugs .................................................    5
0.3. Noted Changes ................................................    5
0.3.1. since -05 ..................................................    5
0.3.2. since -04 ..................................................    5
1. Introduction ...................................................    7
1.1. Conventions Used in This Document ............................    7
1.2. Example mail messages ........................................    8
2. Design .........................................................    9
2.1. Form of the Language .........................................    9
2.2. Whitespace ...................................................    9
2.3. Comments .....................................................    9
2.4. Literal Data .................................................    9
2.4.1. Numbers ....................................................   10
2.4.2. Strings ....................................................   10
2.4.2.1. String Lists .............................................   11
2.4.2.2. Headers ..................................................   11
2.4.2.3. Addresses ................................................   11
2.5. Tests ........................................................   11
2.6. Tagged Arguments .............................................   12
2.7. String Comparison ............................................   12
2.7.1. Match Type .................................................   13
2.7.2. Comparisons across Character Sets ..........................   13
2.7.3. Comparators ................................................   14
2.7.4. Comparisons against addresses ..............................   15
2.8. Blocks .......................................................   15
2.9. Commands .....................................................   15
2.9.1. Positional Arguments .......................................   16
2.9.2. Optional Arguments .........................................   16
2.9.3. Blocks as Arguments ........................................   16
2.10. Evaluation ..................................................   16
2.10.1. Implicit Keep .............................................   16
2.10.2. Extensions and Optional Features ..........................   16
3. Control Structures .............................................   17
4. Actions ........................................................   18



Showalter                 Expire in Six Months                  [Page 2]

Internet DRAFT                   Sieve                  January 25, 1999


4.1. Action reject ................................................   18
4.2. Action fileinto ..............................................   19
4.3. Action redirect ..............................................   19
4.4. Action keep ..................................................   20
4.6. Action stop ..................................................   20
4.7. Action discard ...............................................   20
4.8. Action require ...............................................   21
5. Tests ..........................................................   21
5.1. Test address .................................................   21
5.2. Test allof ...................................................   22
5.3. Test anyof ...................................................   22
5.4. Test envelope ................................................   22
5.5. Test exists ..................................................   23
5.6. Test false ...................................................   23
5.7. Test header ..................................................   23
5.8. Test not .....................................................   24
5.9. Test size ....................................................   24
6. Extensibility ..................................................   25
6.1. Capability String ............................................   25
6.2. Registry .....................................................   26
6.3. Capability Transport .........................................   26
7. Transmission ...................................................   26
8. Acknowledgments ................................................   26
9.  Formal Grammar ................................................   26
10. Security Considerations .......................................   28
11. Author's Address ..............................................   28
Appendix A.  References ...........................................   28
Appendix B. Full Copyright Statement ..............................   29























Showalter                 Expire in Six Months                  [Page 3]

Internet DRAFT                   Sieve                  January 25, 1999





















































Showalter                 Expire in Six Months                  [Page 2]

Internet DRAFT                   Sieve                  January 25, 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.

   Draft number 05 was circulated among developers at the 43nd IETF in
   Orlando, but never seemed to make it to the Internet-Drafts
   repository.  In the event that this draft's file is numbered -05,
   readers are advised that there were two with that number.

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 Problems

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; a preliminary
   draft exists and will be submitted to the internet-drafts repository.
   Vacation functionality is isn't in 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.

   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.





Showalter                 Expire in Six Months                  [Page 4]

Internet DRAFT                   Sieve                  January 25, 1999


0.2.2. Known Bugs

   The discussion of the limits of actions is not there.

   The language is represented in UTF-8, but the character set specified
   in the ABNF is only good for ASCII.  This obviously needs to be
   fixed.

0.3. Noted Changes

0.3.1. since -05

   The following are changes from draft 05.  (This may not be complete.)
   Most of these changes were discussed at the Sieve meeting in Orlando
   at the 43rd IETF.

   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
   mutliple 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.2. since -04

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

   * Concensus: i;ascii-casemap is required.



Showalter                 Expire in Six Months                  [Page 5]

Internet DRAFT                   Sieve                  January 25, 1999


   * 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
     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 6]

Internet DRAFT                   Sieve                  January 25, 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 otherwise should generalize to other systems that meet
   these criteria.

   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 and
   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 [FLAMES] filtering
   language 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



Showalter                 Expire in Six Months                  [Page 7]

Internet DRAFT                   Sieve                  January 25, 1999


   [KEYWORDS].

   Each section on a 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 seperated 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 8]

Internet DRAFT                   Sieve                  January 25, 1999


   Message B
   -----------------------------------------------------------
   From: youcouldberich!@reply-by-postal-mail
   Sender: [e-mail]
   To: [e-mail]
   Date:  Mon, 31 Mar 1997 18:26:10 -0800 (PST)
   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

   This language is made up as a set of commands.  Commands can take a
   number of arguments; arguments can be either literal data, tests, or
   blocks of commands.

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

2.2. Whitespace

   Whitespace is used to separate commands.  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.

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


2.4. Literal Data

   Literal data means data that is not executed and is supplied as
   arguments, such as numbers and strings.




Showalter                 Expire in Six Months                  [Page 9]

Internet DRAFT                   Sieve                  January 25, 1999


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.

   Negative, fractional, and decimal numbers are not 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).  A backslash ("\") 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
   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.



Showalter                 Expire in Six Months                 [Page 10]

Internet DRAFT                   Sieve                  January 25, 1999


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

2.4.2.1. String Lists

   When matching patterns, strings frequently come in groups.  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.  So 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 by the interpreter.

   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.

2.5. Tests

   Tests are given as arguments to commands in order to control how the
   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,



Showalter                 Expire in Six Months                 [Page 11]

Internet DRAFT                   Sieve                  January 25, 1999


   and side effects are forbidden in extensions as well.

   Note:  Tests with side effects impair readability and maintainability
          and are difficult to represent in a graphic interface to
          generating scripts, so side effects have been confined to
          actions where they are more clear.


2.6. Tagged Arguments

   This document provides for tagged arguments in the style of
   CommonLISP.

   A tagged argument is an 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.

   One case where this is useful 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.

   Tagged arguments must appear before positional arguments, but they
   may appear in any order.  For convienence, this is not expressed in
   the syntax definitions with commands, but they still may be reordered
   arbitrarily provided they appear before positional arguments.  This
   explicitally includes match types and comparator arguments (see 2.7.1
   and 2.7.3).

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

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 being used to represent the name of a
   header, the comparator is not user-specified.  Header comparisons are
   always done in a case-insensitive manner, since this is the way
   things are specified in the message specification [IMAIL].  That is,
   header-name comparisons are always done with the "i;ascii-casemap"
   comparator.



Showalter                 Expire in Six Months                 [Page 12]

Internet DRAFT                   Sieve                  January 25, 1999


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" version 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" version 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 any number of characters, and
   "?" matches a single character.  "?" and "*" may be escaped as "\?"
   and "\*" in strings to match against them by name.

   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
   ":contains"  or  ":matches".  It is an error to use a comparator with
   ":contains" or ":matches" that is not compatible with it.

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

   Syntax:   [ < ":is" / ":contains" / ":matches" > <key: string> ]


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.



Showalter                 Expire in Six Months                 [Page 13]

Internet DRAFT                   Sieve                  January 25, 1999


      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 containing 8-bit data can be considered equal.

2.7.3. Comparators

   In order to allow for character set-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 in 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.

   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 convienence, 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



Showalter                 Expire in Six Months                 [Page 14]

Internet DRAFT                   Sieve                  January 25, 1999


   is not case-sensitive.

   If a comparator is not known to an implementation, it is treated in
   the same way as an unknown command or syntax 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 representations as
   strings.  Because these are structured and being able to compare
   against the local-part or the domain of an address is useful, 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 is done, such as whether or not the comparison
   done is case-insensitive, is specified as a comparator argument to
   the test.


   Syntax:   < ":localpart" / ":domain" / ":all" > ":localpart"


2.8. Blocks

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

   So a control structure is just a command that happens to take a test
   and a block as its arguments; depending on the result of the control
   structure, it runs the code in the block zero or more times.  (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.)

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.




Showalter                 Expire in Six Months                 [Page 15]

Internet DRAFT                   Sieve                  January 25, 1999


   A command begins with a name, which is a simple token.  It ends with
   either a semicolon or a block.  (Commands ending with blocks are used
   to implement control structures.)  Commands never take both a
   semicolon and a block, nor do they ever take more than one block as
   an argument.

2.9.1. Positional Arguments

   Positional arguments are familiar from any programming language.  A
   command takes zero or more untagged positional arguments in order to
   specify its behavior.  Positional arguments are given their value
   based on their order in the command.

2.9.2. Optional Arguments

   Optional arguments are tagged arguments that may be omitted; when
   omitted, they are given default values.

2.9.3. Blocks as Arguments

   Commands may take blocks as arguments.  A block is always the last
   argument to a command, and when it exists, it replaces the semicolon
   that would otherwise end the command.

2.10. Evaluation

   This memo imposes specific limits on actions; for instance, a
   rejected message may not also be filed into a mailbox.  These
   restrictions are noted on a per-command basis.

   OPEN:   Or rather, they should be.

2.10.1. Implicit Keep

   If evaluation of a script fails to result in one "fileinto", "keep",
   or "reject", a "keep" action is implicitly taken: The message is
   filed into the user's primary mailbox.

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

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

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



Showalter                 Expire in Six Months                 [Page 16]

Internet DRAFT                   Sieve                  January 25, 1999


   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.


   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 languages such as PostScript that have
          extension mechanisms that allow a script to include
          information on how to work around a lack of an extension
          suggest that such mechanisms do not work well in practice.


3. Control Structures

   In order for a script to do more than one set of actions, control
   structures are needed.  In Sieve, a control structure is a command
   that takes a block as an argument.

   In this document, only the "if" control structure is provided.  There
   are three pieces to if: "if", "elsif", and "else".

   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 17]

Internet DRAFT                   Sieve                  January 25, 1999


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

   Example:  if header :contains "from" "coyote" {
                discard;
             } elsif :contains header ["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 "Subject" contains "$$$" {
                redirect "[e-mail]";
             } else {
                redirect "[e-mail]";
             }

4. Actions


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

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:  if header :contains "from" "[e-mail]" {
                reject "I am not taking mail from you, and I don't want
                your birdseed, either!";
             }








Showalter                 Expire in Six Months                 [Page 18]

Internet DRAFT                   Sieve                  January 25, 1999


   A reject message MUST takes the form of a failed 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.  A message
   that triggers a "reject" action is never allowed to be kept by the
   user, and the "reject" overrides all other actions.

   A message may only be rejected once.

   Because some implementations cannot implement the reject command, it
   is optional.

4.2. Action fileinto


   Syntax:   fileinto <folder: string>

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

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

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

4.3. Action redirect


   Syntax:   redirect <address: string>




Showalter                 Expire in Six Months                 [Page 19]

Internet DRAFT                   Sieve                  January 25, 1999


   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.

   A simple script can be used for redirecting:

   Example:  redirect "[e-mail]";

   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.)  The redirect command does
   not add Resent- headers.

4.4. Action keep


   Syntax:   keep

   The "keep" action is whatever action is taken in lieu of all other
   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.6. Action stop


   Syntax:   stop

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

4.7. Action discard


   Syntax:   discard

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




Showalter                 Expire in Six Months                 [Page 20]

Internet DRAFT                   Sieve                  January 25, 1999


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

   Discard takes no arguments.

   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.

4.8. Action require


   Syntax:   require <capabilities: string-list>

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


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


5. Tests

   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-KEYWORD]
             <header-list: string-list> <key-list: string-list>


   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 have the somewhat awkward characteristic



Showalter                 Expire in Six Months                 [Page 21]

Internet DRAFT                   Sieve                  January 25, 1999


   that the mailbox-part [IMAIL] 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.

5.2. Test allof


   Syntax:   allof ( <test1: test>, <test2: test>, ..., <testN: test> )

   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.

5.3. Test anyof


   Syntax:   anyof ( <test1: test> , <test2: test> , ..., <testN:  test>
             )

   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 [ADDRESS-PART] [MATCH-KIND]
             <envelope-part: string-list> <key-list: string-list>





Showalter                 Expire in Six Months                 [Page 22]

Internet DRAFT                   Sieve                  January 25, 1999


   The "envelope" test is true if the specified part of the RFC-822
   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.

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]



Showalter                 Expire in Six Months                 [Page 23]

Internet DRAFT                   Sieve                  January 25, 1999


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

   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.



Showalter                 Expire in Six Months                 [Page 24]

Internet DRAFT                   Sieve                  January 25, 1999


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 that the server does not support.

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, 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" incidates 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" capability.






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


6.2. Registry

   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:

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.

   OPEN:   There needs to be a more complete description here,
           suggestions appreciated.


7. Transmission

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

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

9.  Formal Grammar

   The grammar used in this section is the same as the ABNF described in
   [ABNF].



Showalter                 Expire in Six Months                 [Page 26]

Internet DRAFT                   Sieve                  January 25, 1999


   In the case of alternative or optional rules in which a later rule
   overlaps an earlier rule, the rule which is listed earlier MUST take
   priority.  (This shouldn't happen.  Please let me know if it does.)

   The start symbol for this grammar is "start".

   argument = string / string-list / number / tag / test

   block = "{" commands "}"
           ;; C-style block

   CHAR-NOT-DOT = (%x01-2d / %x2f-%xff)
           ;; all the characters that aren't "."

   command = identifier *(WSP argument) [WSP] ( ";" / block )

   commands = *([WSP] command [WSP])

   comment = "#" *VCHAR CRLF

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

   multi-line = "text:" [WSP] 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 ".".

   number = 1*DIGIT [QUANTIFIER]
           ;; quantifier is a multiplier (or bit shift)

   QUANTIFIER = "K" / "M" / "G"
           ;; K == 2^10; M == 2^20; G = 2^30

   quoted-string = DQUOTE *CHAR DQUOTE
           ;; \" inside a string maps to "
           ;; \\ inside a string maps to \
           ;; All other characters map to themselves.
           ;; Note that newlines and other weird characters
           ;; are all allowed strings.

   start = commands

   string = quoted-string / multi-line

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



Showalter                 Expire in Six Months                 [Page 27]

Internet DRAFT                   Sieve                  January 25, 1999


   tag = ":" identifier

   test = identifier *(WSP argument) [WSP test-list]

   test-list = [WSP] "(" [WSP] *(test [WSP] "," [WSP])
       test [WSP] ")" [WSP]

   WSP = 1*(SP / CRLF / HTAB) / comment
           ;; just whitespace.  anyplace this is allowed, a comment is
           ;; as well

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.

   Therefore, an implementation SHOULD only allow one "reject" per
   message processed, and MAY limit the number of redirect actions
   taken.  An implementation MUST refuse to redirect a message to
   itself.  [OPEN: What do you do when a site limit prevents you from
   this?  Say I do three replies; which ones take effect when the limit
   is 1? 2? 0?]

   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, an implementation MUST refuse to
   filter a message that it has already filtered once; that is, a
   message must not pass through a given server twice.

11. Author's Address

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

   E-Mail: [e-mail]






Showalter                 Expire in Six Months                 [Page 28]

Internet DRAFT                   Sieve                  January 25, 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 29]

Internet DRAFT                   Sieve                  January 25, 1999


Appendix B. Full Copyright Statement

   Copyright (C) The Internet Society 1998. 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.































Showalter                 Expire in Six Months                 [Page 30]


--Multipart_Mon_Jan_25_18:46:59_1999-1--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA11443 for ietf-mta-filters-bks; Mon, 25 Jan 1999 13:53:38 -0800 (PST)
Received: from odd.qualcomm.com (odd.qualcomm.com [129.46.2.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA11439 for <[e-mail]>; Mon, 25 Jan 1999 13:53:37 -0800 (PST)
Received: from randy-nt (randy-nt.qualcomm.com [129.46.219.44]) by odd.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id NAA14070 for <[e-mail]>; Mon, 25 Jan 1999 13:55:30 -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: Mon, 25 Jan 1999 13:51:57 -0800
To: [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Duplicated header lines
In-Reply-To: <[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 10:29 PM 1/21/99 -0500, Lawrence Greenfield wrote:

>Currently, my implementation is broken---it tests only against the
>first (or maybe last) header of that name---but it's quite possibly
>that I want to see if I'm mentioned explicitly in the "To" header, and
>this will break if there are multiple "To" headers.
>
>I've thought about fixing this by appending the contents of a header
>that appears multiple times together, possibly with a \r\n in
>between.  (I'm lazy.)
>
>Tim suggested that instead a header test be run against each instance
>of the header, and the result OR'd together.  (But this is also easy.)

My Sieve implementation runs the test against all instances of the header.
(I was specifically thinking of "Received" when I wrote the code, as I use
a number of spam filters that examine "Received" headers, but the code does
this for all headers.)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA09046 for ietf-mta-filters-bks; Mon, 25 Jan 1999 10:23:40 -0800 (PST)
Received: from ckgppxy1.proxy.att.com (ckmsfw1.att.com [12.20.58.157]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA09040 for <[e-mail]>; Mon, 25 Jan 1999 10:23:18 -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 NAA14072 for <[e-mail]>; Mon, 25 Jan 1999 13:24:56 -0500 (EST)
Received: from att.com (hansenpc.bl-els.att.com[135.25.111.58](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990125182508un1157199ce>; Mon, 25 Jan 1999 18:25:08 +0000
Message-ID: <[e-mail]>
Date: Mon, 25 Jan 1999 13:25:54 -0500
From: Tony Hansen <[e-mail]>
Reply-To: [e-mail]
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.07 [en] (Win98; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Multiple actions in Sieve script.
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>

Tim Showalter wrote:
> Incidentially, I really think we should dump implicit keep. If this is
> not the case, I'd really like to know it now.

Not without adding something else to replace it, because I think it
would be difficult to recreate the implicit keep's capability using the
other features currently available within the language.

Adding a test primitive in which you can explicitly test to see if the
message had been dealt with would provide one way to do it. Another way
would be to adding variables to the language into which you can store
state and later test against. The latter would be overkill, but could
have other uses as well, as well as headaches. Probably the easiest
would be the former, something like:

	if message-is :unhandled {
		keep;
	}

Gosh, you could have all sorts of state you could test for. :-)

	Tony Hansen
	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA08864 for ietf-mta-filters-bks; Mon, 25 Jan 1999 10:06:04 -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 KAA08860 for <[e-mail]>; Mon, 25 Jan 1999 10:06:03 -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 NAA26539; Mon, 25 Jan 1999 13:08:20 -0500 (EST)
Date: Mon, 25 Jan 1999 13:10:14 -0500
From: Matthew Wall <[e-mail]>
To: Sieve Mailing List <[e-mail]>
cc: Keith Moore <[e-mail]>, =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
Subject: Minneapolis Sieve BOF redux
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>

Just an FYI.

We have until Feb. 22 to put in a formal request for an agenda slot for a
BOF at Minneapolis. Obviously, the sooner we can put something in, the
better the slot...

When I asked about whether to "use" our second BOF, there was a gentle hum
on the list that we should go ahead and do it, but not what I'd yet call a
strong consensus. I don't think anyone objected, though, in concept.

Having been prodded about this again, I've changed my mind a bit.

I'm now thinking that if we could get a full two-hour session (as opposed
to a one-hour BOF), it might be a useful working session, in that there are
multiple implementations and some semantic issues that have clearly arisen
(which might of course be worked out on the list). It would be more in the
character of a working group session than a BOF, in that the primary goal
would be to slog through residual specification issues. 

We're well beyond the BOFish-is-there-interest? stage but still well shy of
needing to form a working group, and rather than worry about "using up" our
second BOF, I'd rather use the time to get as many issues resolved as
possible.

The last agenda item on our BOF agenda be: do we need to form a working
group? I'll bring a charter in hand, just in case (I'll put it on the
list). I still really don't think this is going to be necessary, but if
things are not relatively close to completion, it's probably best if we can
have Plan B in hand to give our Area Directors some advance notice that
we'd want a WG (given that the ADs are trying to lay down a number of
working groups to make room for new ones, not starting one at all would be
a definite bonus 8-). "Plan B" would probably be some concept of 'if the
spec isn't ready by such and such a date, we'll need to meet again, and
therefore having used up our two BOFs a working group is probably
justified', where 'such and such a date' would be sometime after the March
meeting.

In fact, here's a proposed mini-agenda:

Sieve document
 -- open issues

Extensions
 -- open issues

WG or no WG? 
 -- Charter
 -- timetable

- matt




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07163 for ietf-mta-filters-bks; Mon, 25 Jan 1999 08:32:40 -0800 (PST)
Received: from main (main.demo.ru [194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07134 for <[e-mail]>; Mon, 25 Jan 1999 08:32:13 -0800 (PST)
Received: FROM demo.ru ([194.87.43.111]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 25 Jan 1999 19:32:46 +0300
Message-ID: <[e-mail]>
Date: Mon, 25 Jan 1999 19:31:16 +0300
From: Alexey Melnikov <[e-mail]>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Lawrence Greenfield <[e-mail]>
CC: [e-mail], Randall Gellens <[e-mail]>, [e-mail]
Subject: Re: Multiple actions in Sieve script.
References: <[e-mail]> <[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>

Lawrence Greenfield wrote:

> There are a couple of interrelated issues here, and I'd like to try
> to seperate them.  Please let me know if I have this right.  I've also
> included my opinions on each...
>
> Issue #1 -- Conflicting Actions:
>
> I'd like to know what the semantics of the following script is:
>
> forward "[e-mail]";
> reject "i no longer read electronic mail";
>
> I believe such scripts should create an error, and that the default
> action ("keep") should be taken.

I agree.

> ---
>
> Issue #2: Multiple Actions
>
> Currently, sieve can allow multiple actions to be taken.  Consider the
> following script:
>
> keep;
> forward "[e-mail]";
>
> To me, this is a logically coherent script, and should take the action
> of both forwarding all mail and storing it as normal.  It is different
> from the script:
>
> forward "[e-mail]";
>
> which does _not_ keep the mail locally.  The default "keep" action is
> _only_ taken when no explicit actions occur in the script.
>
> To me, "forward", "fileinto", and "keep" are all compatible.  We could
> say that this is implementation dependant, and any use of multiple
> actions could be treated as a run-time error like #1 above.

I interpret SIEVE document the same way.

--
Alexey Melnikov





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA24886 for ietf-mta-filters-bks; Sun, 24 Jan 1999 17:13:04 -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 RAA24882 for <[e-mail]>; Sun, 24 Jan 1999 17:13:03 -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 UAA25697; Sun, 24 Jan 1999 20:15:15 -0500 (EST)
Date: Sun, 24 Jan 1999 20:17:08 -0500
From: Matthew Wall <[e-mail]>
To: Tim Showalter <[e-mail]>
cc: [e-mail]
Subject: Sieve 05/06 draft; Sieve website is up
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>

Tim, et al

just noted in doing a little housekeeping today that the most recent
official version of the Sieve draft (04) in the IETF/internic pages will
expire in seven days.

I'd strongly suggest resubmitting whatever the current version of 05
directly to  the secretariat. Since we agreed that  "06" would reflect all
changes discussed at Orlando (and which would presumably reflect results of
recent discussions), I think it would do more harm to let this expire than
to put up an incomplete draft at this point, since there's no working group
to form an umbrella for related activities.

With this latter point in mind, I've thrown up a quickie web page for sieve
with an email address to submit sample scripts and browse general info:

http://www.cyrusoft.com/sieve

I've taken the liberty of linking in Larry's implementation and putting in
a single sample script into the archive as a seed. It might help the
interoperation goal, as well as provide a reality check, if everybody who
has working scripts they're willing to share them sends them in, and if
you've got any public plans for Sieve, please let me know and I'll list
them. Just helps the bandwagon keep rolling.

This is my typical all-on-a-single-page first draft for a site, but I
figured something was better than nothing. I also managed to track down and
link some minutes that aren't part of the mailing list archives, fwiw.

- Matt




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA22039 for ietf-mta-filters-bks; Fri, 22 Jan 1999 17:51:00 -0800 (PST)
Received: from emrys.qualcomm.com (emrys.qualcomm.com [129.46.2.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA22035 for <[e-mail]>; Fri, 22 Jan 1999 17:50:59 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by emrys.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA22406; Fri, 22 Jan 1999 17:52:34 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04103e02b2ced9522cb0@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04103e08b2ced1be21b4@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Fri, 22 Jan 1999 17:48:50 -0800
To: Tim Showalter <[e-mail]>, Randall Gellens <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
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>

At 8:24 PM -0500 1/22/99, Tim Showalter wrote:

> No.  I wasn't clear.  I find the terminology "FileInto" and "CopyInto"
> confusing because the terms do not clearly specify what they do.
>
> Actually, neither do "FileOnlyInto" and "FileInto" or whatever.  Blah.
>
> My intent was that many "FileInto"s can be obeyed IF the server supports
> FileInto at all.
>
> If the server supports "FileOnlyInto", only one invocation works (either
> the first or the last).
>
> Ack.  Perhaps "MoveInto" is best, and the last one is the only one
> obeyed.  I dunno.

Are we at least agreed that we need one action which indicates into 
which mailbox the message should be delivered, and that if more than 
one of these actions is executed, only one is actually obeyed?  And 
that we need an action which is optional to support and which causes 
the message to be placed in a specified mailbox in addition to any 
other invocations of this action, or any invocation of the deliver 
action?

Or do some people disagree, and feel we need an action (optional to 
support) which can be invoked any number of times, each time causing 
the message to be delivered into a mailbox?

The difference is that the in the first case we really do have a 
FileInto and a CopyInto, and a script would be expected to execute 
one FileInto, and zero or more CopyIntos. 

The second case is harder to name, because we have a FileInto (must 
implement) and something else which is optional, call it 
OptionalFileInto.  A script can be expected to execute one or more 
OptionalFileIntos on systems which support it, and alternatively one 
FileInto on systems which do not support OptionalFileInto.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA21784 for ietf-mta-filters-bks; Fri, 22 Jan 1999 17:22:05 -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 RAA21775 for <[e-mail]>; Fri, 22 Jan 1999 17:21:59 -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 UAA01500; Fri, 22 Jan 1999 20:24:06 -0500 (EST)
Date: 22 Jan 1999 20:24:14 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: assassination White Water $400 million in gold bullion Panama explosion quiche Cocaine
To: Randall Gellens <[e-mail]>
Cc: [e-mail]
In-reply-to: <v04103e08b2ced1be21b4@129.46.219.133>
Subject: Re: Multiple actions in Sieve script.
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: Fri, 22 Jan 1999 17:15:33 -0800
> From: Randall Gellens <[e-mail]>
> 
> At 7:49 PM -0500 1/22/99, Tim Showalter wrote:
> 
> >> I think it is OK to both reject and redirect (forward) a message.
> >> The message is not kept.
> > I am strongly opposed to this. It's been discussed before.
> 
> I can live with these being mutually exclusive.  What is the rule if 
> both are executed?  Last one wins?  First one wins?  Script aborts 
> (filing into INBOX as default)?
> 
> > Incidentially, I really think we should dump implicit keep. If this is
> > not the case, I'd really like to know it now.
> 
> What does that mean?  Surely the default action must still be keep.
> 
> >
> >> That's my point exactly.  We need to distinguish a single file-into
> >> from a multiple file-into.  Let's say we spell them "FileInto" and
> >> "CopyInto".  Then, if more than one "FileInto" is executed, only one
> >> of them is effective (which one is an open point).  If more than one
> >> CopyInto is done, all are effective.  If both a CopyInto and a
> >> FileInto are done, both are effective.
> >
> > I suggest "FileInto" and "FileOnlyInto", or possibly, add an optional
> > tagged argument to Fileinto, ":only".
> 
> Is the intent of the "only" part to prevent also doing a non-only? 

No.  I wasn't clear.  I find the terminology "FileInto" and "CopyInto"
confusing because the terms do not clearly specify what they do.

Actually, neither do "FileOnlyInto" and "FileInto" or whatever.  Blah.

My intent was that many "FileInto"s can be obeyed IF the server supports 
FileInto at all.

If the server supports "FileOnlyInto", only one invocation works (either 
the first or the last).

Ack.  Perhaps "MoveInto" is best, and the last one is the only one
obeyed.  I dunno.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA21712 for ietf-mta-filters-bks; Fri, 22 Jan 1999 17:15:16 -0800 (PST)
Received: from mail1.qualcomm.com (mail1.qualcomm.com [129.46.2.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA21708 for <[e-mail]>; Fri, 22 Jan 1999 17:15:15 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by mail1.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA23771; Fri, 22 Jan 1999 17:16:53 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04103e08b2ced1be21b4@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04103e02b2cec374c5be@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Fri, 22 Jan 1999 17:15:33 -0800
To: Tim Showalter <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 7:49 PM -0500 1/22/99, Tim Showalter wrote:

>> I think it is OK to both reject and redirect (forward) a message.
>> The message is not kept.
> I am strongly opposed to this. It's been discussed before.

I can live with these being mutually exclusive.  What is the rule if 
both are executed?  Last one wins?  First one wins?  Script aborts 
(filing into INBOX as default)?

> Incidentially, I really think we should dump implicit keep. If this is
> not the case, I'd really like to know it now.

What does that mean?  Surely the default action must still be keep.

>
>> That's my point exactly.  We need to distinguish a single file-into
>> from a multiple file-into.  Let's say we spell them "FileInto" and
>> "CopyInto".  Then, if more than one "FileInto" is executed, only one
>> of them is effective (which one is an open point).  If more than one
>> CopyInto is done, all are effective.  If both a CopyInto and a
>> FileInto are done, both are effective.
>
> I suggest "FileInto" and "FileOnlyInto", or possibly, add an optional
> tagged argument to Fileinto, ":only".

Is the intent of the "only" part to prevent also doing a non-only? 

So a script can't do:

    if <test 1>
        CopyInto "foo";

    ...

    if <test2>
        FileInto "bar";


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA21497 for ietf-mta-filters-bks; Fri, 22 Jan 1999 16:46:57 -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 QAA21493 for <[e-mail]>; Fri, 22 Jan 1999 16:46:56 -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 TAA27971; Fri, 22 Jan 1999 19:48:47 -0500 (EST)
Date: 22 Jan 1999 19:49:15 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Soviet cracking strategic Vince Foster BATF $400 million in gold bullion munitions
To: [e-mail], Randall Gellens <[e-mail]>
In-reply-to: <v04103e02b2cec374c5be@129.46.219.133>
Subject: Re: Multiple actions in Sieve script.
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: Fri, 22 Jan 1999 16:17:38 -0800
> From: Randall Gellens <[e-mail]>
> Cc: [e-mail], Randall Gellens <[e-mail]>
> 
> At 10:53 PM -0500 1/21/99, Lawrence Greenfield wrote:
> 
> > This contradicts both of our interpretations, since I believe that
> > actions shouldn't override other actions, and you believe that it's ok
> > to reject and keep a message.
> 
> No, I think it is OK to both reject and redirect (forward) a message. 
> The message is not kept.

I am strongly opposed to this. It's been discussed before.

> > I believe that a sender receiving a rejection notice will believe that
> > their message was never read by a human.  I'm not sure I like the idea
> > of fooling them.
> 
> Yes, this bothers me too.  But is it any different from a case where 
> mail is sent to "luser@foo", which is actually an alias that expands 
> to "luser@bar, luser@gork", and mail sent to "luser@gork" bounces?

Yes, it is, in two ways.  First, if it's a sendmail alias, the envelope
isn't rewritten.  (A Sieve implementation should do that, right?)

Also, the original sender can see a difference between a bounce from
luser@foo, who he sent mail to, and luser@gork, who he didn't.

Incidentially, I really think we should dump implicit keep. If this is
not the case, I'd really like to know it now.

> >    > I think multiple fileinto's are a very useful thing---I think users
> >    > will expect it, though I realize that this is hard (impossible?) for
> >    > some systems.  I think on those systems, multiple fileinto's should be
> >    > handled the same way #1 is above.
> >
> >    I think this should be a compile error on systems that don't support
> >    it.  The question is how to spell it.
> >
> > This is very hard (or impossible if you imagine an extension of some
> > tests) to detect at compile time.  For instance:
> >
> > if (size :over 50K) {
> >    fileinto "big";
> > }
> > if (size :under 55K) {
> >    fileinto "small";
> > }
> 
> That's my point exactly.  We need to distinguish a single file-into 
> from a multiple file-into.  Let's say we spell them "FileInto" and 
> "CopyInto".  Then, if more than one "FileInto" is executed, only one 
> of them is effective (which one is an open point).  If more than one 
> CopyInto is done, all are effective.  If both a CopyInto and a 
> FileInto are done, both are effective.

I suggest "FileInto" and "FileOnlyInto", or possibly, add an optional
tagged argument to Fileinto, ":only".

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA21222 for ietf-mta-filters-bks; Fri, 22 Jan 1999 16:15:37 -0800 (PST)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21218 for <[e-mail]>; Fri, 22 Jan 1999 16:15:19 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id QAA11254; Fri, 22 Jan 1999 16:16:54 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04103e02b2cec374c5be@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04103f00b2cda18e9f8b@129.46.219.133> <[e-mail]> <[e-mail]> <v04103f00b2cda18e9f8b@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Fri, 22 Jan 1999 16:17:38 -0800
To: Lawrence Greenfield <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Cc: [e-mail], 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>

At 10:53 PM -0500 1/21/99, Lawrence Greenfield wrote:

> This contradicts both of our interpretations, since I believe that
> actions shouldn't override other actions, and you believe that it's ok
> to reject and keep a message.

No, I think it is OK to both reject and redirect (forward) a message. 
The message is not kept.

> I believe that a sender receiving a rejection notice will believe that
> their message was never read by a human.  I'm not sure I like the idea
> of fooling them.

Yes, this bothers me too.  But is it any different from a case where 
mail is sent to "luser@foo", which is actually an alias that expands 
to "luser@bar, luser@gork", and mail sent to "luser@gork" bounces?

>
>    [forward; keep; v. just forward]
>
>    Interesting.  To me (and in my implementation), the scripts are
>    identical semantically, as "keep" is performed by default unless a
>    "discard" or "reject" is done.
>
> Implicit keeps are specified (in section 2.11.1) to be taken "if
> evaluation of a script fails to result in one fileinto, keep, or
> reject".  I don't understand why this list doesn't include "discard".

Yes, it should include "discard".

> I would argue that "forward" also belongs in the above list, since
> that makes me think that the message usually won't be kept.
> ("redirect" has the same feeling to me.)

Did we separate "forward" and "redirect"?  I'm sorry, I thought we 
only changed the name of "forward" to "redirect" to avoid confusion. 
Anyway, I disagree about forward/redirect being in the list, since to 
me forward/redirect does not cause delivery or non-delivery.  It is 
merely an intermediate action, much as the "mark" extension in my 
implementation (which adds a header).

>
>    > I think multiple fileinto's are a very useful thing---I think users
>    > will expect it, though I realize that this is hard (impossible?) for
>    > some systems.  I think on those systems, multiple fileinto's should be
>    > handled the same way #1 is above.
>
>    I think this should be a compile error on systems that don't support
>    it.  The question is how to spell it.
>
> This is very hard (or impossible if you imagine an extension of some
> tests) to detect at compile time.  For instance:
>
> if (size :over 50K) {
>    fileinto "big";
> }
> if (size :under 55K) {
>    fileinto "small";
> }

That's my point exactly.  We need to distinguish a single file-into 
from a multiple file-into.  Let's say we spell them "FileInto" and 
"CopyInto".  Then, if more than one "FileInto" is executed, only one 
of them is effective (which one is an open point).  If more than one 
CopyInto is done, all are effective.  If both a CopyInto and a 
FileInto are done, both are effective.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA14453 for ietf-mta-filters-bks; Fri, 22 Jan 1999 03:22:34 -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 DAA14449 for <[e-mail]>; Fri, 22 Jan 1999 03:22:33 -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 GAA01070; Fri, 22 Jan 1999 06:24:38 -0500 (EST)
Date: 22 Jan 1999 06:25:02 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: DES fissionable Uzi Craig Livingstone bomb SEAL Team 6 BATF
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Duplicated header lines
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: Fri, 22 Jan 1999 01:59:33 -0600
> From: Pete Resnick <[e-mail]>

> On 1/21/99 at 10:29 PM -0500, Lawrence Greenfield wrote:
> 
> > The other day I received a mail message with multiple "To" lines, and
> > this got me thinking---what is the definition of the "header" test
> > when a header appears multiple times?
> 
> May I mention that you might want to take into consideration section 
> 4.5.3 of <draft-ietf-drums-msg-fmt-07.txt>.

So HEADER should match across address headers concatenated with a comma.

I still believe that non-address headers, such as Received, should not
be matched across headers.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA10204 for ietf-mta-filters-bks; Thu, 21 Jan 1999 23:57:46 -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 XAA10200 for <[e-mail]>; Thu, 21 Jan 1999 23:57:45 -0800 (PST)
Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 2.2); Fri, 22 Jan 1999 01:59:36 -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]>
X-Mailer: Eudora [Macintosh version 4.1b62-2.99]
Date: Fri, 22 Jan 1999 01:59:33 -0600
To: Lawrence Greenfield <[e-mail]>
From: Pete Resnick <[e-mail]>
Subject: Re: Duplicated header lines
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>

On 1/21/99 at 10:29 PM -0500, Lawrence Greenfield wrote:

> The other day I received a mail message with multiple "To" lines, and
> this got me thinking---what is the definition of the "header" test
> when a header appears multiple times?

May I mention that you might want to take into consideration section 
4.5.3 of <draft-ietf-drums-msg-fmt-07.txt>.

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 XAA10142 for ietf-mta-filters-bks; Thu, 21 Jan 1999 23:54:17 -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 XAA10138 for <[e-mail]>; Thu, 21 Jan 1999 23:54:16 -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 CAA19628; Fri, 22 Jan 1999 02:56:20 -0500 (EST)
Date: 22 Jan 1999 02:56:44 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: colonel strategic FBI Ft. Meade Serbian domestic disruption FSF
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
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'd like to put aside the question of MultipleFileInto for a moment.
The reliability required for Sieve scripts has been declared to be
sufficiently low that MultipleFileInto may represent a considerable
burden to implementors (you *must* lock mailboxes while delivering and
*must* not screw it up).  I don't care about this, but I think the
question can wait until we nail down the question of filing into two
mailboxes.


I think the copyinto/fileinto situation is very ugly because it involves 
a set of semantics that may prevent anyone from getting hurt but also
prevent anyone from being able to comprehend a Sieve script without
trying to decipher them.  We will have lots of hidden semantics that
will not make sense at first glance.

FLAMES lacked an implicit keep and users did not lose mail.  What they
did was they had LISP programs that had a cond form (it's like an
if/elsif/else chain) that the last form always said "If all else fails,
just keep it."

So let's dump the implicit keep.  We're still arguing about it, no one
will ever understand it, it's hard to explain, it's hard to decide when
it shouldn't happen, and it's not going to save anyone.

I haven't yet come up with a set of keep semantics that make any sense.

Once we do that, we can have two commands, one which is a
single-fileinto and one which allows a multiple-fileinto, make keep a
special case of single-fileinto, and be done with it.

(We can add a all-or-nothing multiple-fileinto on top of that.  I
believe we can argue them seperately.)

Tim

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA10015 for ietf-mta-filters-bks; Thu, 21 Jan 1999 23:41:47 -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 XAA10011 for <[e-mail]>; Thu, 21 Jan 1999 23:41:46 -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 CAA25191; Fri, 22 Jan 1999 02:43:50 -0500 (EST)
Date: 22 Jan 1999 02:44:14 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Nazi Delta Force Craig Livingstone Marxist NSA Kennedy Albania
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Duplicated header lines
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: 21 Jan 1999 22:29:41 -0500
> From: Lawrence Greenfield <[e-mail]>
> 
> The other day I received a mail message with multiple "To" lines, and
> this got me thinking---what is the definition of the "header" test
> when a header appears multiple times?

> I've thought about fixing this by appending the contents of a header
> that appears multiple times together, possibly with a \r\n in
> between.  (I'm lazy.)

> Tim suggested that instead a header test be run against each instance
> of the header, and the result OR'd together.  (But this is also easy.)

For the message fragment

	To: [e-mail]
	To: [e-mail]

the string "[e-mail]\r\[e-mail]" does not appear, but by the
first algorithm specified, it would match, but it never occurs.

This is nearly absurd for structured address headers but less so on
random other headers (perhaps Received).

Oh, whatever we called the address-in-header command should parse all
headers specified.

We are splitting hairs so fine the electrons are flying away from the protons.

-- 
Tim Showalter <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA23658 for ietf-mta-filters-bks; Thu, 21 Jan 1999 19:53:03 -0800 (PST)
Received: from ckgppxy1.proxy.att.com ([12.20.58.157]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA23642 for <[e-mail]>; Thu, 21 Jan 1999 19:52:59 -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 WAA08450 for <[e-mail]>; Thu, 21 Jan 1999 22:54:19 -0500 (EST)
Received: from att.com (hansen.bl-els.att.com[135.25.113.245](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990122035426un115719sve>; Fri, 22 Jan 1999 03:54:27 +0000
Message-ID: <[e-mail]>
Date: Sun, 17 Jan 1999 13:36:08 -0500
From: Tony Hansen <[e-mail]>
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.07 [en] (Win98; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Multiple actions in Sieve script.
References: <[e-mail]> <[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>

Lawrence Greenfield wrote:
> Issue #2: Multiple Actions
> 
> Currently, sieve can allow multiple actions to be taken.  Consider the
> following script:
> 
> keep;
> forward "[e-mail]";
> 
> To me, this is a logically coherent script, and should take the action
> of both forwarding all mail and storing it as normal.  It is different
> from the script:
> 
> forward "[e-mail]";
> 
> which does _not_ keep the mail locally.  The default "keep" action is
> _only_ taken when no explicit actions occur in the script.

Agreed.
 
> To me, "forward", "fileinto", and "keep" are all compatible.  We could
> say that this is implementation dependant, and any use of multiple
> actions could be treated as a run-time error like #1 above.

I would prefer that it be well specified. It would be impossible to
write such a script that depends on multiple actions without such
guarantees; making it implementation dependant would prevent that.

	Tony Hansen
	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA23530 for ietf-mta-filters-bks; Thu, 21 Jan 1999 19:52:26 -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 TAA23522 for <[e-mail]>; Thu, 21 Jan 1999 19:52:24 -0800 (PST)
Received: from pounce.cc.cmu.edu (POUNCE.CC.CMU.EDU [128.2.36.181]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id WAA12498; Thu, 21 Jan 1999 22:53:55 -0500 (EST)
Date: 21 Jan 1999 22:53:55 -0500
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.1
To: [e-mail]
Cc: [e-mail], Randall Gellens <[e-mail]>
In-reply-to: <v04103f00b2cda18e9f8b@129.46.219.133>
Subject: Re: Multiple actions in Sieve script.
References: <[e-mail]> <[e-mail]> <v04103f00b2cda18e9f8b@129.46.219.133>
Mime-Version: 1.0 (generated by tm-edit 7.106)
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>

Interesting!  Your interpretation of sieve semantics is dramatically
different from mine.

   > forward "[e-mail]";
   > reject "i no longer read electronic mail";
   >
   > I believe such scripts should create an error, and that the default
   > action ("keep") should be taken.

   I'm not sure.  Why should this be an error?  Is it because the sender 
   may get a failure DSN even though the message went somewhere?

Draft 05 specifies (section 4.1) "A draft that triggers a reject
action is never allowed to be kept by the user, and the reject
overrides all other actions."  

This contradicts both of our interpretations, since I believe that
actions shouldn't override other actions, and you believe that it's ok
to reject and keep a message.

I believe that a sender receiving a rejection notice will believe that
their message was never read by a human.  I'm not sure I like the idea
of fooling them.

   [forward; keep; v. just forward]

   Interesting.  To me (and in my implementation), the scripts are 
   identical semantically, as "keep" is performed by default unless a 
   "discard" or "reject" is done.

Implicit keeps are specified (in section 2.11.1) to be taken "if
evaluation of a script fails to result in one fileinto, keep, or
reject".  I don't understand why this list doesn't include "discard".

I would argue that "forward" also belongs in the above list, since
that makes me think that the message usually won't be kept.
("redirect" has the same feeling to me.)

The way the draft is currently written, your interpretation is
correct.

My implementation currently performs an implicit keep only if NO other
actions are taken.

   [...]
   > I think multiple fileinto's are a very useful thing---I think users
   > will expect it, though I realize that this is hard (impossible?) for
   > some systems.  I think on those systems, multiple fileinto's should be
   > handled the same way #1 is above. 

   I think this should be a compile error on systems that don't support 
   it.  The question is how to spell it.

This is very hard (or impossible if you imagine an extension of some
tests) to detect at compile time.  For instance:

if (size :over 50K) {
   fileinto "big";
}
if (size :under 55K) {
   fileinto "small";
}

I think requiring implementations to do the sort of static checking
that would be required for an implementation to realize that this is a
problem (but "50K" and "40K" isn't) is unreasonable onerous.

We will have run-time errors in sieve (quotas fill up, ACLs change) so
I don't think it's horrible specifying that this is a run-time error.

Larry



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA21217 for ietf-mta-filters-bks; Thu, 21 Jan 1999 19:37:33 -0800 (PST)
Received: from frobozz.qualcomm.com (frobozz.qualcomm.com [129.46.174.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA21211 for <[e-mail]>; Thu, 21 Jan 1999 19:37:32 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by frobozz.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id TAA05648; Thu, 21 Jan 1999 19:39:02 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: [e-mail] (Unverified)
Message-Id: <v04103f00b2cda18e9f8b@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 21 Jan 1999 19:38:04 -0800
To: Lawrence Greenfield <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Cc: Randall Gellens <[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>

At 10:19 PM -0500 1/21/99, Lawrence Greenfield wrote:

> There are a couple of interrelated issues here, and I'd like to try
> to seperate them.  Please let me know if I have this right.  I've also
> included my opinions on each...
>
> Issue #1 -- Conflicting Actions:
>
> I'd like to know what the semantics of the following script is:
>
> forward "[e-mail]";
> reject "i no longer read electronic mail";
>
> I believe such scripts should create an error, and that the default
> action ("keep") should be taken.

I'm not sure.  Why should this be an error?  Is it because the sender 
may get a failure DSN even though the message went somewhere?

>
> ---
>
> Issue #2: Multiple Actions
>
> Currently, sieve can allow multiple actions to be taken.  Consider the
> following script:
>
> keep;
> forward "[e-mail]";
>
> To me, this is a logically coherent script, and should take the action
> of both forwarding all mail and storing it as normal.  It is different
> from the script:
>
> forward "[e-mail]";
>
> which does _not_ keep the mail locally.  The default "keep" action is
> _only_ taken when no explicit actions occur in the script.

Interesting.  To me (and in my implementation), the scripts are 
identical semantically, as "keep" is performed by default unless a 
"discard" or "reject" is done.

>
> To me, "forward", "fileinto", and "keep" are all compatible.  We could
> say that this is implementation dependant, and any use of multiple
> actions could be treated as a run-time error like #1 above.

I'd like to see this spelled out, for consistency.

>
> ---
>
> Issue #3: Many Fileinto
>
> My implementation accepts a string-list as the argument for fileinto,
> and will honor multiple fileinto's.  It will attempt to run all of
> them, and if an error occurs, it will attempt delivery to the default
> mailbox (like a "keep").
>
> I think multiple fileinto's are a very useful thing---I think users
> will expect it, though I realize that this is hard (impossible?) for
> some systems.  I think on those systems, multiple fileinto's should be
> handled the same way #1 is above. 

I think this should be a compile error on systems that don't support 
it.  The question is how to spell it.
>
> I think that the simplicity of a single "fileinto" action is more
> useful than having multiple actions some of which are primary and some
> secondary.  After all, what's the interpretation of the following
> script:
>
> copyinto "INBOX.foo"; # no primary actions
>
> does this do an implicit "keep"?  What about:
>
> copyinto "INBOX.foo";                 # secondary action?
> forward "[e-mail]"; # primary action?

As I see it, there is no confusion here at all.  Both of these 
scripts also do an implicit "keep" and file into the default mailbox.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA19674 for ietf-mta-filters-bks; Thu, 21 Jan 1999 19:27:38 -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 TAA19667 for <[e-mail]>; Thu, 21 Jan 1999 19:27:37 -0800 (PST)
Received: from pounce.cc.cmu.edu (POUNCE.CC.CMU.EDU [128.2.36.181]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id WAA11699; Thu, 21 Jan 1999 22:29:40 -0500 (EST)
Date: 21 Jan 1999 22:29:41 -0500
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.1
To: [e-mail]
Subject: Duplicated header lines
Mime-Version: 1.0 (generated by tm-edit 7.106)
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 other day I received a mail message with multiple "To" lines, and
this got me thinking---what is the definition of the "header" test
when a header appears multiple times?

Currently, my implementation is broken---it tests only against the
first (or maybe last) header of that name---but it's quite possibly
that I want to see if I'm mentioned explicitly in the "To" header, and
this will break if there are multiple "To" headers.

I've thought about fixing this by appending the contents of a header
that appears multiple times together, possibly with a \r\n in
between.  (I'm lazy.)

Tim suggested that instead a header test be run against each instance
of the header, and the result OR'd together.  (But this is also easy.)

Thoughts?

Larry



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA18161 for ietf-mta-filters-bks; Thu, 21 Jan 1999 19:17:54 -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 TAA18153 for <[e-mail]>; Thu, 21 Jan 1999 19:17:53 -0800 (PST)
Received: from pounce.cc.cmu.edu (POUNCE.CC.CMU.EDU [128.2.36.181]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id WAA16970; Thu, 21 Jan 1999 22:19:33 -0500 (EST)
Date: 21 Jan 1999 22:19:35 -0500
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.1
To: [e-mail]
Cc: Randall Gellens <[e-mail]>, [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
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>

There are a couple of interrelated issues here, and I'd like to try
to seperate them.  Please let me know if I have this right.  I've also
included my opinions on each...

Issue #1 -- Conflicting Actions:

I'd like to know what the semantics of the following script is:

forward "[e-mail]";
reject "i no longer read electronic mail";

I believe such scripts should create an error, and that the default
action ("keep") should be taken.

---

Issue #2: Multiple Actions

Currently, sieve can allow multiple actions to be taken.  Consider the
following script:

keep;
forward "[e-mail]";

To me, this is a logically coherent script, and should take the action
of both forwarding all mail and storing it as normal.  It is different
from the script:

forward "[e-mail]";

which does _not_ keep the mail locally.  The default "keep" action is
_only_ taken when no explicit actions occur in the script.

To me, "forward", "fileinto", and "keep" are all compatible.  We could
say that this is implementation dependant, and any use of multiple
actions could be treated as a run-time error like #1 above.

---

Issue #3: Many Fileinto

My implementation accepts a string-list as the argument for fileinto,
and will honor multiple fileinto's.  It will attempt to run all of
them, and if an error occurs, it will attempt delivery to the default
mailbox (like a "keep").

I think multiple fileinto's are a very useful thing---I think users
will expect it, though I realize that this is hard (impossible?) for
some systems.  I think on those systems, multiple fileinto's should be
handled the same way #1 is above.  

I think that the simplicity of a single "fileinto" action is more
useful than having multiple actions some of which are primary and some
secondary.  After all, what's the interpretation of the following
script:

copyinto "INBOX.foo"; # no primary actions

does this do an implicit "keep"?  What about:

copyinto "INBOX.foo";                 # secondary action?
forward "[e-mail]"; # primary action?
---

Larry



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA16421 for ietf-mta-filters-bks; Thu, 21 Jan 1999 19:07:16 -0800 (PST)
Received: from emrys.qualcomm.com (emrys.qualcomm.com [129.46.2.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA16411 for <[e-mail]>; Thu, 21 Jan 1999 19:07:14 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by emrys.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id TAA16282; Thu, 21 Jan 1999 19:08:07 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04103f0fb2cd9bda4881@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04103f03b2cd8989fa7f@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 21 Jan 1999 19:09:59 -0800
To: Matthew Wall <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
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>

At 9:31 PM -0500 1/21/99, Matthew Wall wrote:

> PS Can we call CopyInto DuplicateInto...? It would make me happier...

I'm not hung up on the spelling.  However, I don't think CopyInto 
would be confused with file-carbon-copy.  Eudora filters, for 
example, have "transfer to" and "copy to".  This is separate from the 
"fcc" that can be specified when messages are composed.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA13472 for ietf-mta-filters-bks; Thu, 21 Jan 1999 18:30:03 -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 SAA13467 for <[e-mail]>; Thu, 21 Jan 1999 18:30:02 -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 VAA21815 for <[e-mail]>; Thu, 21 Jan 1999 21:32:01 -0500 (EST)
Date: Thu, 21 Jan 1999 21:33:51 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
Subject: Re: Multiple actions in Sieve script.
Message-ID: <[e-mail]>
In-Reply-To: <v04103f03b2cd8989fa7f@129.46.219.133>
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 Thu, Jan 21, 1999 5:58 PM -0800 the entity known as Randall Gellens
<[e-mail]> wrote:


>  (I suppose that raises the question: 
> should FileInto be permitted for a shared mailbox?)

To which Matthew Wall writes on Thu, 21 Jan 1999 21:32:06 -0500:

um, YES. It MUST be, imho. 

Again, I can verify through experience there's a functional distinction
between forwarding mail and filing it if an organization is using Shared
mailboxes. (I'm particularly thinking about possible Sieve extensions that
do more complex automation.)

- mw




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA13452 for ietf-mta-filters-bks; Thu, 21 Jan 1999 18:27:45 -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 SAA13448 for <[e-mail]>; Thu, 21 Jan 1999 18:27:44 -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 VAA21795; Thu, 21 Jan 1999 21:29:43 -0500 (EST)
Date: Thu, 21 Jan 1999 21:31:33 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Message-ID: <[e-mail]>
In-Reply-To: <v04103f03b2cd8989fa7f@129.46.219.133>
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 Thu, Jan 21, 1999 5:58 PM -0800 the entity known as Randall Gellens
<[e-mail]> wrote:


> So a copy action in Sieve can't be the kind of 
> copy you are thinking of, where the message is delivered first, then 
> copied from there.
> 
> So the semantics of FileInto would be: this message will be delivered 
> into the specified mailbox instead of the default INBOX.
> 
> The semantics of CopyInto would be: this message will be delivered 
> into the specified mailbox in addition.
> 
> 

To which Matthew Wall writes on Thu, 21 Jan 1999 21:13:39 -0500:

I guess I'm hung up on the term 'copy', but also on the need to have
multiple commands. I just don't associated 'copy' with a 'final delivery
action'. (Shades of 'Folder Carbon Copy', although that's an outgoing
action, to be sure.)

I may be reacting to this this way since we use the term rather explicitly
in Mulberry's user interface (similar but somewhat richer than Pine's
folder carbon copy), in a way which is somewhat incompatible with possibly
exposing this command name in an editable sieve script.

Anyway, let me explode the syntactic implications of the semantics you
propose above:

FileInto simply specifies the name of the mailbox for which a message
matching the filter is filed into; failure files into the Default (Rather
than INBOX, let's just call it the Default mailbox.)

'Copyinto' does the same thing, but requires more lines of a Sieve script.

Example 1:

If <subject=Sieve> and <From=gellens> then
Fileinto inbox, randymail, sievemail, potentialspammail

Example 2:

If <subject=Sieve> and <From=gellens> then
Fileinto inbox
CopyInto randymail
CopyInto sievemail
Copyinto potentialspammail

I prefer example 1, in that it's real clear that all the actions are
related. 

Again, we're probably coming from different environments in terms of how
common this is. I rather think that having lengthy lists of mailboxes to
file messages into is quite useful. A common example might be a technical
question on a certain subject; one could filter mail, for instance, sent to
'info' that might go into 'support' and/or a half dozen other locations,
including shared mailboxes, personal mailboxes, mailboxes monitored by
processes, etc.

Alternatively (thinking aloud here, such as it is), let's say we had a
MultipleFileInto command with these semantics: the message is filed into
all the mailboxes, and a failure on any one fails the entire operation,
delivering it instead to the Default mailbox. That's different from a sort
of serial copying, where you might want to have it continue even if there's
one failure, without delivering the message to the Default (as long as it
successfully delivered to at least one mailbox).

Hell, am I arguing for _three_ commands here?

Fileinto --> files into one and only one, defaults to Default mailbox
CopyInto --> files into specified mailbox, if it's able to, assumes at
least one initial succesful file operation
MultipleFileinto --> files into all the mailboxes, else it fails.

Damn. I can actually see the need for all three.

- matt

PS Can we call CopyInto DuplicateInto...? It would make me happier...




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA13323 for ietf-mta-filters-bks; Thu, 21 Jan 1999 18:07:36 -0800 (PST)
Received: from fezik.qualcomm.com (fezik.qualcomm.com [129.46.2.74]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA13319 for <[e-mail]>; Thu, 21 Jan 1999 18:07:32 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by fezik.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id SAA15683; Thu, 21 Jan 1999 18:08:19 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04103f03b2cd8989fa7f@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04103f12b2cd750bd405@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 21 Jan 1999 17:58:57 -0800
To: Matthew Wall <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Cc: Randall Gellens <[e-mail]>, Lawrence Greenfield <[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>

I thought we decided that the Sieve model is assumed to operate at 
final delivery time, that final delivery does not take place until 
after Sieve.  (I know Sieve can be used by POP clients, but that is a 
different matter).  So a copy action in Sieve can't be the kind of 
copy you are thinking of, where the message is delivered first, then 
copied from there.

So the semantics of FileInto would be: this message will be delivered 
into the specified mailbox instead of the default INBOX.

The semantics of CopyInto would be: this message will be delivered 
into the specified mailbox in addition.

Your example of copying a message to the postmaster's mailbox would, 
I think, be better handled by a Forward action.  It is certainly 
cleaner, as I don't expect a Sieve implementation to have access to 
mailboxes for any other user.  (I suppose that raises the question: 
should FileInto be permitted for a shared mailbox?)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA12787 for ietf-mta-filters-bks; Thu, 21 Jan 1999 17:12:11 -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 RAA12782 for <[e-mail]>; Thu, 21 Jan 1999 17:12:10 -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 UAA21676; Thu, 21 Jan 1999 20:14:09 -0500 (EST)
Date: Thu, 21 Jan 1999 20:15:59 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Randall Gellens <[e-mail]>, Lawrence Greenfield <[e-mail]>, [e-mail]
Subject: Re: Multiple actions in Sieve script.
Message-ID: <[e-mail]>
In-Reply-To: <v04103f12b2cd750bd405@129.46.219.133>
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>

To simplify the previous post:

I think the essence of this question will go back to whether multiple
fileintos is considered necessary and therefore must be required. I think
it is. If there are implementations that can't support this (as Randy
points out), then we need two actions, whatever they may be.

Level two of my argument is that COPY is not a MULTIPLEFILEINTO.

- mw


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA12743 for ietf-mta-filters-bks; Thu, 21 Jan 1999 17:09:17 -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 RAA12739 for <[e-mail]>; Thu, 21 Jan 1999 17:09:15 -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 UAA21666; Thu, 21 Jan 1999 20:11:14 -0500 (EST)
Date: Thu, 21 Jan 1999 20:13:04 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Randall Gellens <[e-mail]>, Lawrence Greenfield <[e-mail]>, [e-mail]
Subject: Re: Multiple actions in Sieve script.
Message-ID: <[e-mail]>
In-Reply-To: <v04103f12b2cd750bd405@129.46.219.133>
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 Thu, Jan 21, 1999 4:34 PM -0800 the entity known as Randall Gellens
<[e-mail]> wrote:


> I see fileinto as an action that 
> determines into which mailbox this message is placed.  On "classic" 
> message store systems there can be only one such mailbox per message; 
> to put the message into additional mailboxes requires copying.  On 
> systems that implement single-copy message stores, it may be simple 
> to logically make the message part of any number of mailboxes, but I 
> don't think that should drive Sieve semantics.
> 
> So, only one fileinto per message.  Anything else is a copy, which is 
> separate (and should be optional).

To which Matthew Wall writes on Thu, 21 Jan 1999 19:46:08 -0500:

au contraire. I think a "copy" is "cloning" an original (usually from disk
or static store), whereas a fileinto is typically done from memory
dynamically at the "delivery" event, like giving birth to twins. The
distinction is making a copy versus making multiple instantiations of a
single original. Whether there's a difference in the actual storage of the
message or not may not be an important one, but I'd maintain a message
might change between the time it's initially filed and then copied.


This is what I'm thinking the state difference is:

message is delivered ---> fileinto messagestore A --> copy from A to B

e.g.
           +----------+
SMTP --->  | SIEVE    | ---> fileinto A action --> 
RFC/822    +----------+
              +----------+
        --->  | SIEVE    | ---> copyaction A to B
              +----------+
(Randy's model, as I understand it)

vs.

           +----------+
SMTP --->  | SIEVE    | ---> fileinto A
RFC/822    +----------+ ---> fileinto B

(the way I see a simple multiple fileintos as Larry described.)

The former model isn't so strange if you think about the client being the
Sieve engine, with full access to and knowledge of the mailstore. Easy
enough if you're talking about an IMAP append (although with the state of
the message not necessarily the same in the COPY scenario -- think about a
"seen" flag, for instance -- not reliably the same kind of message) or a
copy on a local POP store. But I don't think you can assume that SIEVE will
know enough about the store to do a copy. Let's say the fileinto action is
meant to flag certain messages for delivery to a user (primary function)
but alert a system adminstrator (say, a potential candidate for Spam) as a
secondary recipient. The mailstores for the two of them may be different.

Anyway, I'd argue multiple fileinto is simpler, since it only requires
three "steps" for completion instead of five. (Please, no comments about 11
being louder than 10.)

> There is nothing in particular implied by the order of 
> the Sieve statements.

my turn to be dense 8-). I again make a distinction between an ordered
series of fileinto actions vs. a single fileinto action into multiple
stores (mailboxes) which you may not. The very fact of a fileinto itself
may be an important artifact of a single fileinto or test.

Here's a pseudo-script. 

file X into --> A
file Y into --> B
copy X from A --> B

assume there's an ultra-precise timestamp on a message. Let's pretend A is
a private mailbox, B is a shared one.

Yes, there's no order implied by Sieve, but implementations will have a
specific order.The time 'received' or the recent flag or whatever is going
to be different for the same message in the above two scenario. 

With multiple fileintos, it would be more like

file X ---> A and B
file Y --> B

Thus the state of X is the same in A and B at the time (in whatever order)
the Sieve script is executed.

I just find this a cleaner model for single-line execution, bearing in mind
that implementations (like Larry's) are free to treat (and resolve) all
actions as aggregates rather than as a linear sequence.

I can also see, from the history of FLAMES, why this is important to not
assume linear exection.

> How is (multiple) FileInto more obvious than CopyInto?

MultipleFileinto implies a single event of delivery to multiple
destinations. Copy (to me, at least) implies a delivery, then a copy of
that original. It's two events, not one.

> 
> In my implementation, Sieve operates as a plug-in, and gets to set 
> the destination mailbox.  So it can only do one fileinto (at least as 
> the API is now).  If that fileinto can't be honored (the mailbox 
> doesn't exist), the delivery agent uses INBOX as the default.

Yah, you're right, this is consistent. I'm saying if there's a
multipleFileinto where one fails, there should be a default fileinto
behavior as for singleFileinto. (I don't mean to suggest these as actual
names.) However, since I haven't thought through syntax issues for a
proposed new command, I'm not sure I know whether this should be different
from the current behavior or not.

I actually just want fileinto to be allowed to go to multiple mailboxes,
but if we can't require that, I don't like the concept of a "copy" if we
need to remove the requirement for multiple fileintos for the above
reasons...

- matt




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA12372 for ietf-mta-filters-bks; Thu, 21 Jan 1999 16:31:49 -0800 (PST)
Received: from odd.qualcomm.com (odd.qualcomm.com [129.46.2.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA12368 for <[e-mail]>; Thu, 21 Jan 1999 16:31:48 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by odd.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id QAA03678; Thu, 21 Jan 1999 16:32:35 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04103f12b2cd750bd405@129.46.219.133>
In-Reply-To: <[e-mail]>
References: <v04103f02b2cd35977278@129.46.219.133>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 21 Jan 1999 16:34:03 -0800
To: Matthew Wall <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Cc: Randall Gellens <[e-mail]>, Lawrence Greenfield <[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>

At 6:05 PM -0500 1/21/99, Matthew Wall wrote:

>
> I see the issue with multiple fileintos, but the proposed solution of
> having sort of cascading optional actions seems strange. Basically, I see
> "copy" as a separate kind of option from "file" and relying on copy
> actually puts burdens on the implementation to keep track of this stuff and
> copy from one storage location to another; while fileinto more than one
> location is its own kind of thing.

I'm not sure I follow this.  I see fileinto as an action that 
determines into which mailbox this message is placed.  On "classic" 
message store systems there can be only one such mailbox per message; 
to put the message into additional mailboxes requires copying.  On 
systems that implement single-copy message stores, it may be simple 
to logically make the message part of any number of mailboxes, but I 
don't think that should drive Sieve semantics.

So, only one fileinto per message.  Anything else is a copy, which is 
separate (and should be optional).

>
> Also, even though the point is well taken about there being no requirement
> or convention for making the most important fileinto first in a series,
> from a parsing standpoint, it makes more sense to file-or-fail for the
> first entry. This is something the user interface setting up the script
> might gently remind the user about, with respect to the implications of not
> following the convention.

I'm afraid I'm not following this either (I must be having a dense 
day).  What does "from a parsing standpoint" and "file-or-fail for 
the first entry" mean?

I'm using a multi-hundred line Sieve script now to process all my 
mail.  It's mostly a long series of if-else statements that do 
"fileinto"s (and some "mark"s) based on envelope from or headers.  (I 
don't use reject or discard, but I do have filters that file into 
"Trash", which is safer and also doesn't send out NDNs, since this is 
mostly spam.)  There is nothing in particular implied by the order of 
the Sieve statements.

>
> A couple of other options:
>
> 1. Have the first unsuccessful fileinto simply halt any subsequent
> fileintos in a multiple fileinto.
>
> 2. Have multiple fileintos as a separate command, separate from
> singleFileinto and optional to implement. This would be morally equivalent
> to a copyInto, I guess 8-). But it would make the distinction a little more
> obvious, and

How is (multiple) FileInto more obvious than CopyInto?

>
> 3. Default multiple fileintos that fail into the INBOX.

In my implementation, Sieve operates as a plug-in, and gets to set 
the destination mailbox.  So it can only do one fileinto (at least as 
the API is now).  If that fileinto can't be honored (the mailbox 
doesn't exist), the delivery agent uses INBOX as the default.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA11374 for ietf-mta-filters-bks; Thu, 21 Jan 1999 15:01:17 -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 PAA11369 for <[e-mail]>; Thu, 21 Jan 1999 15:01:15 -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 SAA21372; Thu, 21 Jan 1999 18:03:12 -0500 (EST)
Date: Thu, 21 Jan 1999 18:05:03 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Randall Gellens <[e-mail]>, Lawrence Greenfield <[e-mail]>, [e-mail]
Subject: Re: Multiple actions in Sieve script.
Message-ID: <[e-mail]>
In-Reply-To: <v04103f02b2cd35977278@129.46.219.133>
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 Thu, Jan 21, 1999 11:56 AM -0800 the entity known as Randall Gellens
<[e-mail]> wrote:


> 
> Not all implementations will be able to support multiple fileinto 
> actions.  It depends on the environment.  I suggest we state that 
> only the last fileinto is acted on, and create a new optional action 
> for copyinto.
> 
> (We could make the first fileinto the active one, but I think the 
> last one is much more intuitive.  And while it is true that some 
> users may put high-priority filters first, there is no requirement or 
> even convention to do so.  Also, a high-priority filter can always 
> include a stop action.)

To which Matthew Wall writes on Thu, 21 Jan 1999 17:56:36 -0500:

I see the issue with multiple fileintos, but the proposed solution of
having sort of cascading optional actions seems strange. Basically, I see
"copy" as a separate kind of option from "file" and relying on copy
actually puts burdens on the implementation to keep track of this stuff and
copy from one storage location to another; while fileinto more than one
location is its own kind of thing.

Also, even though the point is well taken about there being no requirement
or convention for making the most important fileinto first in a series,
from a parsing standpoint, it makes more sense to file-or-fail for the
first entry. This is something the user interface setting up the script
might gently remind the user about, with respect to the implications of not
following the convention.

A couple of other options:

1. Have the first unsuccessful fileinto simply halt any subsequent
fileintos in a multiple fileinto.

2. Have multiple fileintos as a separate command, separate from
singleFileinto and optional to implement. This would be morally equivalent
to a copyInto, I guess 8-). But it would make the distinction a little more
obvious, and

3. Default multiple fileintos that fail into the INBOX.

- mw



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA03542 for ietf-mta-filters-bks; Thu, 21 Jan 1999 11:57:00 -0800 (PST)
Received: from strange.qualcomm.com (strange.qualcomm.com [129.46.2.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03538 for <[e-mail]>; Thu, 21 Jan 1999 11:56:59 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by strange.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id LAA06346; Thu, 21 Jan 1999 11:57:44 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04103f02b2cd35977278@129.46.219.133>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 21 Jan 1999 11:56:16 -0800
To: Lawrence Greenfield <[e-mail]>, [e-mail], [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:34 PM -0500 1/19/99, Lawrence Greenfield wrote:

> In the implementation of sieve for Cyrus that I'm working on, I'm
> following the following convention:
>
> Running a script accumulates a list of actions to take.
>
> Upon successful termination of the script, ALL actions are taken.
> Currently, this allows unlimited fileinto's and forward's.

Not all implementations will be able to support multiple fileinto 
actions.  It depends on the environment.  I suggest we state that 
only the last fileinto is acted on, and create a new optional action 
for copyinto.

(We could make the first fileinto the active one, but I think the 
last one is much more intuitive.  And while it is true that some 
users may put high-priority filters first, there is no requirement or 
even convention to do so.  Also, a high-priority filter can always 
include a stop action.)

>
> If no actions have been accumulated by script termination, a keep is
> performed.
>
> If an action conflicts with an action already on the list, there's a
> run-time error.  That is, if a "keep" has been specified and then we
> come across "reject", that's an error.  "reject" and "discard"
> conflict with all other actions (and each other).  "fileinto",
> "forward", and "keep" can all be performed together.

Are keep and reject exclusive, or does the last one simply override 
the first?  It really is a question as to the semantics of keep. 
Since this is the default action, what is the purpose of an explicit 
keep?  It can be either to server as protection against a subsequent 
reject, or it could simply be a way to explicitly state (and 
document) the default action.  I can see an argument for both choices.

>
> If any run-time errors occur, a "keep" is performed.
>
> ---
>
> I think this is a logical collection of rules.  Site policies may want
> to limit the number of forwards or fileintos done.

Yes, but Sieve should not itself impose a limit, such as only one forward.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA21430 for ietf-mta-filters-bks; Tue, 19 Jan 1999 13:36: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 NAA21426 for <[e-mail]>; Tue, 19 Jan 1999 13:36:45 -0800 (PST)
Received: from pounce.cc.cmu.edu (POUNCE.CC.CMU.EDU [128.2.36.181]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id QAA24635; Tue, 19 Jan 1999 16:34:37 -0500 (EST)
Date: 19 Jan 1999 16:34:39 -0500
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.1
To: [e-mail], [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
References: <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.106)
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>

In the implementation of sieve for Cyrus that I'm working on, I'm
following the following convention:

Running a script accumulates a list of actions to take.

Upon successful termination of the script, ALL actions are taken.
Currently, this allows unlimited fileinto's and forward's.

If no actions have been accumulated by script termination, a keep is
performed.

If an action conflicts with an action already on the list, there's a
run-time error.  That is, if a "keep" has been specified and then we
come across "reject", that's an error.  "reject" and "discard"
conflict with all other actions (and each other).  "fileinto",
"forward", and "keep" can all be performed together.

If any run-time errors occur, a "keep" is performed.

---

I think this is a logical collection of rules.  Site policies may want
to limit the number of forwards or fileintos done.

Larry



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20880 for ietf-mta-filters-bks; Tue, 19 Jan 1999 12:13:54 -0800 (PST)
Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA20876 for <[e-mail]>; Tue, 19 Jan 1999 12:13:51 -0800 (PST)
Received: from kcig1.att.att.com by kcgw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-mta-filters sender maillennium.att.com!gsereda (maillennium.att.com!gsereda); Tue Jan 19 14:15 CST 1999
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by kcig1.att.att.com (AT&T/IPNS/GW-1.0) with ESMTP id OAA28990 for <[e-mail]>; Tue, 19 Jan 1999 14:15:20 -0600 (CST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990119201531un115719sie>; Tue, 19 Jan 1999 20:15:31 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 19 Jan 1999 15:20:34 -0500
To: [e-mail], [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: Multiple actions in Sieve script.
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 06:03 PM 1/18/99 -0500, Tony Hansen wrote:
>Gregory Sereda wrote:
>> 
>> Filter list members,
>> 
>> Draft 5 states:
>> 
>> 0.2.2. Known Bugs
>> 
>>    The discussion of the limits of actions is not there.  Only one
>>    forward should be allowed per message.  Keep and reject are mutually
>>    exclusive.
>> ---------------------
>> I think we need to define the limits of actions.  For example should
>> only one "fileinto" action be allowed?  If we allow multiple "fileinto",
>> which one is effective?  Logically, it would be the last.  From a user
>> perspective, the first one woould make more sense because higher priority
>> "rules" appear first.
>
>Another logical expectation is that all are effective. That is, a copy
>goes into each of the folders specified.

Good point.  The spec is not very clear on this...

4.2. Action fileinto


   Syntax:   fileinto <folder>

   The "fileinto" action drops the message into a named folder.
---------------------
I interpret "drops the message" as a move message rather than
a copy message.  Spec should be clear if this is a move or copy.
If it is a copy, does it also leave a copy in the IN folder, ie "keep".

Greg Sereda


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA00983 for ietf-mta-filters-bks; Mon, 18 Jan 1999 15:01:52 -0800 (PST)
Received: from att.com (algw1.att.com [192.128.167.153]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA00979 for <[e-mail]>; Mon, 18 Jan 1999 15:01:50 -0800 (PST)
Received: from alms2.fw.att.com by algw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-mta-filters sender att.com!tony (att.com!tony); Mon Jan 18 17:57 EST 1999
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alms2.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id RAA00299 for <[e-mail]>; Mon, 18 Jan 1999 17:59:13 -0500 (EST)
Received: from att.com (hansenpc.bl-els.att.com[135.25.111.58](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990118230317un1157199te>; Mon, 18 Jan 1999 23:03:18 +0000
Message-ID: <[e-mail]>
Date: Mon, 18 Jan 1999 18:03:12 -0500
From: Tony Hansen <[e-mail]>
Reply-To: [e-mail]
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.07 [en] (Win98; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Multiple actions in Sieve script.
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:
> 
> Filter list members,
> 
> Draft 5 states:
> 
> 0.2.2. Known Bugs
> 
>    The discussion of the limits of actions is not there.  Only one
>    forward should be allowed per message.  Keep and reject are mutually
>    exclusive.
> ---------------------
> I think we need to define the limits of actions.  For example should
> only one "fileinto" action be allowed?  If we allow multiple "fileinto",
> which one is effective?  Logically, it would be the last.  From a user
> perspective, the first one woould make more sense because higher priority
> "rules" appear first.

Another logical expectation is that all are effective. That is, a copy
goes into each of the folders specified.

> On another topic, what is the subject for a vacation reply message?
> I would guess it is:
> 
>         Subject: Re: <original message subject>
> 
> Should this be stated in the spec?  Any other headers needed, such
> as "In-Reply-To:"?

After stripping off any existing Re: and subsequent white space, then
add Re: to the original subject.

	Tony Hansen
	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA00575 for ietf-mta-filters-bks; Mon, 18 Jan 1999 14:15:45 -0800 (PST)
Received: from att.com (cagw1.att.com [192.128.52.89]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA00571 for <[e-mail]>; Mon, 18 Jan 1999 14:15:43 -0800 (PST)
Received: from caig1.fw.att.com by cagw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-mta-filters sender maillennium.att.com!gsereda (maillennium.att.com!gsereda); Mon Jan 18 17:07 EST 1999
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by caig1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id RAA15372 for <[e-mail]>; Mon, 18 Jan 1999 17:16:43 -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 <19990118221654un1157197te>; Mon, 18 Jan 1999 22:16:54 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 18 Jan 1999 17:21:44 -0500
To: [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Multiple actions in Sieve script.
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,

Draft 5 states:

0.2.2. Known Bugs

   The discussion of the limits of actions is not there.  Only one
   forward should be allowed per message.  Keep and reject are mutually
   exclusive.
---------------------
I think we need to define the limits of actions.  For example should
only one "fileinto" action be allowed?  If we allow multiple "fileinto",
which one is effective?  Logically, it would be the last.  From a user
perspective, the first one woould make more sense because higher priority
"rules" appear first.

Are there more mutually exclusive actions, such as "discard" and "forward"?

On another topic, what is the subject for a vacation reply message?
I would guess it is:

	Subject: Re: <original message subject>

Should this be stated in the spec?  Any other headers needed, such
as "In-Reply-To:"?

Greg Sereda


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA01732 for ietf-mta-filters-bks; Fri, 15 Jan 1999 19:17:01 -0800 (PST)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA01728 for <[e-mail]>; Fri, 15 Jan 1999 19:17:00 -0800 (PST)
Received: from 129.46.219.133 (randy-mac.qualcomm.com [129.46.219.133]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id TAA02309; Fri, 15 Jan 1999 19:17:27 -0800 (PST)
Mime-Version: 1.0
Message-Id: <v04103e0fb2c5b045c884@129.46.219.133>
In-Reply-To: <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Fri, 15 Jan 1999 19:00:06 -0800
To: Matthew Wall <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Minneapolis IETF and Sieve - BOF or what?
Cc: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Signature-Tag: v1.0b3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree having anotherBOF right away is what we should do.  But 
*only* if we have what we believe is the Sieve base spec ready for 
IETF last call in advance.  That means we need the final draft 
published and we need good solid agreement on it within the Sieve 
community, and progress towards multiple implementations of it.  If 
we don't have this, another BOF will hurt.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23736 for ietf-mta-filters-bks; Fri, 15 Jan 1999 08:44:14 -0800 (PST)
Received: (from phoffman@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23705; Fri, 15 Jan 1999 08:43:44 -0800 (PST)
Date: Fri, 15 Jan 1999 08:43:44 -0800 (PST)
Message-Id: <[e-mail]>
From: List Manager of ietf-mta-filters <[e-mail]>
To: [e-mail]
Subject: How to be removed from this list
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings again. Occasionally, people will sign up for a mailing list and
forget how to be removed. This message is a reminder for those folks.

First off, when you subscribe to a mailing list, you almost always get a
first message from the list owner telling you about the mailing list, and
explaining how to unsubscribe. It is always a good idea to keep those
messages, since you never know when you will need to unsubscribe. This is
particularly useful when you change email addresses, because it is difficult
to unsubscribe from a list after you have a different mailing address.

In the case of this list, the method to unsubscribe is to send a message
to:
     [e-mail]
with the single word:
     unsubscribe
in the body of the message. This is the same as it always has been.

To make this easier for you, I have crafted this message so that you should
be able to simply reply to this message, and the reply address should be
[e-mail] (although some mail clients screw this up...).
Remove everything from the body of the reply, and put in the single word:
     unsubscribe

If you have tried this method, and the mailing list software won't let you
unsubscribe, it is probably because your address has changed. In that case,
please send a message to [e-mail] stating which list (or lists) you
want to unsubscribe from, and what you think your previous address was.
There is a human (that's me!) who will then try to take care of your
request, often within a few days.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA21274 for ietf-mta-filters-bks; Thu, 14 Jan 1999 08:11:57 -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 IAA21270 for <[e-mail]>; Thu, 14 Jan 1999 08:11:56 -0800 (PST)
Received: from gallileo.esys.ca (dhcp198-44.esys.ca [198.161.92.44]) by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id JAA05177; Thu, 14 Jan 1999 09:13:08 -0700
From: Steve Hole <[e-mail]>
Date: Thu, 14 Jan 1999 09:12:28 -0700
To: Matthew Wall <[e-mail]>
Subject: Re :  Minneapolis IETF and Sieve - BOF or what?
Cc: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: Execmail for Win32 Version Execmail Mercury pc2 Build (30)
MIME-Version: 1.0
Content-Type: Text/Plain; 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 Tue, 12 Jan 1999 18:40:02 -0500 Matthew Wall <[e-mail]> wrote:

> So I'd basically propose, and seek discussion and response from the list,
> that we have three options:
> 
> (1) schedule a second BOF for Minneapolis. 
> 
> My theory is that this will provide another opportunity for an open-door
> meeting, but we'll have implementation experience at that point. If a
> second BOF isn't sufficient to complete the bulk of work by that point,
> then that suggests we might actually need formal WG status after all. So at
> the end of the meeting in Minneapolis, we'd have three possible outcomes: 
> 
>  (a) set a timetable to submit the Sieve draft to the IESG as a Proposed
> Standard, 
> 
>  (b) agree to a charter for a WG, or 
> 
>  (c) defer and/or abandon the work in place.

A notable difference between this BOF and the last is that there are a
number of working implementations out there. This is the best possible 
indicator that we have something that is workable.   Many people are using
this preferentially over older mechanisms such as procmail.

Then I would:

1.  Have the BOF.    Shoot for (d).   Failing that, go for (b).

If we can't get it to proposed immediately, then at least let's get a WG 
going with an aggressive charter that prevents the non-implementing 
bastard tire kickers from their fascist perversion of the process :-)

> (2) defer another BOF, reserving Washington in November (+six months) as a
> potential meeting time.
> 
> This would have the advantage of being 8 months in the future instead of
> two, so presumably more work would have been done by then, and it may turn
> out the meeting isn't at all necessary after all0.

We need to get this thing on the standards track yesterday.    I would not
vote for a deferral.   


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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA01938 for ietf-mta-filters-bks; Tue, 12 Jan 1999 19:59:15 -0800 (PST)
Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.8/8.8.5) with SMTP id TAA01934 for <[e-mail]>; Tue, 12 Jan 1999 19:59:14 -0800 (PST)
Received: from kcig1.att.att.com by kcgw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-mta-filters sender att.com!tony (att.com!tony); Tue Jan 12 22:00 CST 1999
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by kcig1.att.att.com (AT&T/IPNS/GW-1.0) with ESMTP id WAA29208 for <[e-mail]>; Tue, 12 Jan 1999 22:00:24 -0600 (CST)
Received: from att.com (hansen.bl-els.att.com[135.25.113.245](may be forged)) by maillennium.att.com (labmail) with SMTP id <19990113040029un1157197se>; Wed, 13 Jan 1999 04:00:29 +0000
Message-ID: <[e-mail]>
Date: Tue, 12 Jan 1999 22:58:32 -0500
From: Tony Hansen <[e-mail]>
X-Mailer: Mozilla 4.07 [en] (Win98; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Minneapolis IETF and Sieve - BOF or what?
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>

Matthew Wall wrote:
> 
> Well, I know it seems like I just asked this, but I've gotten the periodic
> nudge from the IETF secretariat that's issued prior to IETF agenda
> scheduling, saying 'do you want to schedule something at Minneapolis?' The
> March meeting kinda sneaks up on you.
>  ...
> So I'd basically propose, and seek discussion and response from the list,
> that we have three options:
> 
> (1) schedule a second BOF for Minneapolis.
> 
> My theory is that this will provide another opportunity for an open-door
> meeting, but we'll have implementation experience at that point. If a
> second BOF isn't sufficient to complete the bulk of work by that point,
> then that suggests we might actually need formal WG status after all. So at
> the end of the meeting in Minneapolis, we'd have three possible outcomes:
> 
>  (a) set a timetable to submit the Sieve draft to the IESG as a Proposed Standard,
>  (b) agree to a charter for a WG, or
>  (c) defer and/or abandon the work in place.
> 
> (2) defer another BOF, reserving Washington in November (+six months) as a
> potential meeting time.
> 
> (3) not plan to meet.
> 
> If we don't have to, why bother?
> 
> My instinct at this point is to go for option (1), with a goal of (1a),
> getting the document, as amended in this next BOF, to standards track
> submission, bypassing a working group.
> ...
> -- Next question: wy bother with another BOF? I believe scrutiny of the
> broader community in a second BOF will help both the document and getting
> it to Proposed Standard ASAP by further exposing it to the community
> (especially if we do NOT procrastinate and submit a revised document at the
> last minute, but get it out at least 4-6 weeks in advance of the meeting).
> ...
> -- if we don't get good consensus on the document at that point, we'd
> probably have difficulty getting the IESG to approve straight-to-standard
> anyway, at which point we'd have to get up a WG anyway to continue.
> 
> So, please, can I have a quick show of e-hands indicating which of the
> above options, (1), (2), or (3), seems best to each of you.

I think we are close enough to having a working language that we should
push forward as quickly as possible. So we need to meet.

However, this could be done via another BOF (1), or another informal
get-together like we did in Orlando.

I think the choice between these two should be dependent on how quickly
we can get -06 out and implemented by multiple people. (Tim, any
progress on that?) But if we have to make a decision within the next
week, then I'd rather go with another informal meeting rather than a
formal BOF.

(By the way, -05 never made it to the official internet-drafts archive.)

	Tony Hansen
	[e-mail]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA20943 for ietf-mta-filters-bks; Tue, 12 Jan 1999 15:37:18 -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 PAA20939 for <[e-mail]>; Tue, 12 Jan 1999 15:37:17 -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 SAA02419; Tue, 12 Jan 1999 18:38:20 -0500 (EST)
Date: Tue, 12 Jan 1999 18:40:02 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Ned Freed <[e-mail]>, Tim Showalter <[e-mail]>
Subject: Minneapolis IETF and Sieve - BOF or what?
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>

Well, I know it seems like I just asked this, but I've gotten the periodic
nudge from the IETF secretariat that's issued prior to IETF agenda
scheduling, saying 'do you want to schedule something at Minneapolis?' The
March meeting kinda sneaks up on you.

The dates, FYI, are March 15-19th. Yes, just about sixty days away. The
next meetings after this are in July in Norway, and in November in
Washington (DC). The next meeting after that is in March 2000, in Adelaide,
Australia. The next North American meeting after that won't be until at
least the third quarter of 2000, insofar as I know.

For practical purposes, then, for most North American participants, I think
we've got our choice of Minneapolis in March or Washington in November for
any possible short-term BOF or WG meetings.

I'd again remind the list that we've had one formal BOF already; we're
allowed a maximum of two on the same topic, after which we go to WG or
abandon-in-place, at least to the extent that we won't get another shot at
an IETF agenda slot on the same topic.

We have to get Area Director (Patrik and Keith's) approval for any proposed
scheduling request, I would note, so it's probably best to talk about this
right away.

Following our informal meeting at Orlando (see Tim's message from 12/7/98
titled 'Sieve Meeting Notes'), I personally think we're in very good shape
with respect to 'Sieve 1.0'. (I'm calling the current draft 'Sieve 1.0' to
mean the future, final version of what we're working on now.) We've got
multiple implementations from a variety of client and server vendors
underway, agreement on the base spec's scope and much of the details, and
it seems like we're down to more minor issues on the list. This leads me to
believe more than ever that a formal working group is NOT necessary.
There's just not enough stuff to go through to justify a full working
group, imho.

When we had the formal BOF in LA last year [see 'LA IETF BOF Notes',
Laurence Linblade, 4/1/98], there were a lot of what I would call
scope-creep discussions. 

Here, quoted as reported by Laurence in the minutes, is what we concluded
on 3/31/98:

> There was good humming(tm) about going forward on sieve in general.
> 
> Roughly equal humming in favor and opposed to forming a working
> group. Those opposed said:
>  - will take too long
>  - not baked enough to start a working group
>  - will thrash if we don't have something more cooked
> 
> Course of action decided on is to work on sieve in the mailing list,
> come up with another draft and consider a working group in a few
> months after things are more cooked.

The fact that these newer suggestions either did not percolate up on the
list in detail or have been rejected by list participants since makes me
think that while there may have been many valid points raised, they weren't
fundamental to the 'Sieve 1.0' concept, as evidence by the number of
implementations in progress that do not incorporate.

So I'd basically propose, and seek discussion and response from the list,
that we have three options:

(1) schedule a second BOF for Minneapolis. 

My theory is that this will provide another opportunity for an open-door
meeting, but we'll have implementation experience at that point. If a
second BOF isn't sufficient to complete the bulk of work by that point,
then that suggests we might actually need formal WG status after all. So at
the end of the meeting in Minneapolis, we'd have three possible outcomes: 

 (a) set a timetable to submit the Sieve draft to the IESG as a Proposed
Standard, 

 (b) agree to a charter for a WG, or 

 (c) defer and/or abandon the work in place.

(2) defer another BOF, reserving Washington in November (+six months) as a
potential meeting time.

This would have the advantage of being 8 months in the future instead of
two, so presumably more work would have been done by then, and it may turn
out the meeting isn't at all necessary after all0.

(3) not plan to meet.

If we don't have to, why bother?

My instinct at this point is to go for option (1), with a goal of (1a),
getting the document, as amended in this next BOF, to standards track
submission, bypassing a working group.

My rationale:

-- the clear consensus of the last few meetings we've had are that sooner
is much, much better for a relatively simple specification, and we all need
this yesterday. To my mind, this means getting whatever IETF open meeting
we need to have scheduled at the earliest opportunity.

I would also note that given the two non-North American meetings coming up
in the next four, it may be that other activities (perhaps as yet
unforseen) may distract our individual and collective attentions, so it may
be best to meet sooner.

-- my .02 units is that the document is in very decent shape, thus worthy
of attention now.

-- Next question: wy bother with another BOF? I believe scrutiny of the
broader community in a second BOF will help both the document and getting
it to Proposed Standard ASAP by further exposing it to the community
(especially if we do NOT procrastinate and submit a revised document at the
last minute, but get it out at least 4-6 weeks in advance of the meeting).

Possible objection: won't we just get meeting hoppers at this BOF who will
make the same proposals for complexifying the document we got last year,
who will then go away and not show up on the list again, thus delaying us
even further? Response: The difference between this meeting and a year ago
will be we will have multiple working implementations to demonstrate the
running-code part, to try to make the point that further complication of
the spec would simply delay presently-available functionality, and that it
would be more adequate to declare the rough-consensus part in submitting
the document to the IESG for consideration as straight-to-proposed.

-- if we don't get good consensus on the document at that point, we'd
probably have difficulty getting the IESG to approve straight-to-standard
anyway, at which point we'd have to get up a WG anyway to continue.


So, please, can I have a quick show of e-hands indicating which of the
above options, (1), (2), or (3), seems best to each of you.

We need an idea of whether to make a scheduling request within the next
week or ten days. Please chime in as soon as you can.

- Matt







Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA11014 for ietf-mta-filters-bks; Mon, 11 Jan 1999 14:21:26 -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 OAA11009 for <[e-mail]>; Mon, 11 Jan 1999 14:21:25 -0800 (PST)
Received: from pounce.cc.cmu.edu (POUNCE.CC.CMU.EDU [128.2.36.181]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id RAA24269; Mon, 11 Jan 1999 17:22:28 -0500 (EST)
Date: 11 Jan 1999 17:22:30 -0500
Message-ID: <[e-mail]>
From: Lawrence Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.1
To: [e-mail]
Subject: cmu-sieve implementation
Mime-Version: 1.0 (generated by tm-edit 7.106)
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>

Now available from anonymous ftp is a prototype sieve implementation.
It implements 05 as precisely as possible, minus a few obvious bugs
correcting where comments are allowed and allowing empty blocks, etc.
I'm interested if people agree that it implements the spec correctly.

ftp://ftp.andrew.cmu.edu:/pub/cmu-sieve/cmu-sieve-1.0

Larry