Subject: sieve protocol

From: Timothy L Martin <[email-masked]>
Date: 28 Sep 1999 11:42:58 -0400

The Cyrus Imapd currently gives two options of where to store users'
sieve scripts. In the user's home directory or within the /usr/sieve
directory on the Cyrus Imapd server. Since Cyrus is a closed system
this presents the problem of how do users get their sieve scripts onto 
the server. We have come up with the protocol listed below and plan to 
release code based on it in the next version of Cyrus. We hope in the
future for users to submit their scripts to an ACAP server but we need 
a solution until that is possible.

Some others have expressed interest in this. Do people think it would be
worthwhile to write this protocol up formally?

Of course any comments or suggestions on the protocol would be greatly 
appreciated.

Thanks,
Tim

----------------------------------------------------------------------
This is a protocol for getting user sieve scripts onto the server. The
requirments for this process are:

-the user must authenticate to gain access
-only valid sieve scripts may be accepted

Additional "features" provided:

-the ability to manage multiple scripts on the server with zero or one
of them being the "active" sieve script

Types
-----

This is a line oriented protocol much like [IMAP] or [ACAP]. There
are two types: ATOMS and strings. Strings may be quoted or
literal. See [ACAP] for detailed descriptions.

Commands
--------

AUTHENTICATE <string (mechanism)> <string(initial data)> EOL

SASL authentication. Initial data is base64 encoded. The server
replies with a OK or NO response, or a string base64 encoded followed
by an EOL. Client then replies with a string base64 encoded followed
by an EOL and the procedure is repeated.

NOOP EOL

No side affects. OK, NO replies

LOGOUT EOL

Logout of server. OK, NO replies

GETSCRIPT <sievename> EOL

returns: <string (data of script)> EOL
Get the script with name 'sievename' from the server. OK, NO replies

PUTSCRIPT <sievename> <string (data)> EOL

Puts 'sievename' with data 'data' onto the server if possible. OK, NO replies

SETACTIVE <sievename> EOL

Set the script with the name 'sievename' as the active script. Any
other script that was active is no longer. OK, NO replies

DELETESCRIPT <sievename> EOL

Delete the script with 'sievename'. OK or NO replies

LISTSCRIPTS EOL

returns zero or more: <tag> <sivename> EOL
where the active script has a '*' at the end of it's name
OK or NO replies

<sievename> is a string where only certain characters are
allowed and it must be at least 1 character long

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 28 Sep 1999 14:51:08 -0600

>>>>> "Timothy" == Timothy L Martin <[email-masked]> writes:

    Timothy> NOOP EOL
    Timothy> No side affects. OK, NO replies

If this doesn't do anything it should be removed from the protocol.

--lyndon

To: Timothy L Martin <[email-masked]>
cc: [email-masked]
Subject: Re: sieve protocol 
Date: Tue, 28 Sep 1999 14:51:08 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

>>>>> "Timothy" == Timothy L Martin <[email-masked]> writes:

    Timothy> NOOP EOL
    Timothy> No side affects. OK, NO replies

If this doesn't do anything it should be removed from the protocol.

--lyndon

Date: 28 Sep 1999 11:42:58 -0400
From: Timothy L Martin <[email-masked]>
To: [email-masked]
Subject: sieve protocol
Sender: [email-masked]

Thanks,
Tim

Types
-----

Commands
--------

NOOP EOL

LOGOUT EOL

LISTSCRIPTS EOL

Date: 20 Sep 1999 14:33:14 -0700
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: next-to-last call on sieve base spec
Sender: [email-masked]

If anyone has any comments, flames, or corrections to the Sieve spec
as published (version 09), please let me know.  I'd like to last call
it shortly, or we'll have to talk about it at the next IETF.

I know the formfeeds got eaten.  My mailer seems to have acquired some 
bad habits.  I'm sorry for the inconvienence.

Tim

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-showalter-sieve-09.txt
Date: Fri, 17 Sep 1999 08:03:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Sieve: A Mail Filtering Language
	Author(s)	: T. Showalter
	Filename	: draft-showalter-sieve-09.txt
	Pages		: 40
	Date		: 16-Sep-99
	
This document describes a language for filtering e-mail messages at
time of final delivery.  It is designed to be implementable on either
a mail client or mail server.  It is meant to be extensible, simple,
and independent of access protocol, mail architecture, and operating
system.  It is suitable for running on a mail server where users may
not be allowed to execute arbitrary programs, such as on black box
IMAP servers, as it has no variables, loops, or ability to shell out
to external programs.

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

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-showalter-sieve-09.txt

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

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

--OtherAccess--

--NextPart--

Date: Sat, 11 Sep 1999 22:32:59 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: MDNs vs. DSNs
To: Tim Showalter <[email-masked]>
Cc: [email-masked], MTA Filters <[email-masked]>
Sender: [email-masked]

> Sam Robertson <[email-masked]> writes:

> > Generating MDN's in our implementation is not possible at this point,
> > yet we want to support the reject action.  Aside from all the features
> > provided by supporting RFC 2298, why is an MDN an absolute requirement?

> We want a standard reply with well-known semantics.  MDN has standard
> semantics, but they are weak enough to allow for what a reject action
> implies.  Specifically, a "deleted" MDN allows for the ambiguity that
> "maybe the recipient deleted your message, or maybe he deleted it and
> kept it".

There's also another side to this coin -- suppose filtering is implemented in
the MUA (perfectly reasonable), the message had a NOTIFY=SUCCESSES in the
envelope, and the MUA's filters said "reject".  Then it is possible to get a
success DSN followed by a failure MDN. (Also reasonable.) But if a DSN
was generated, you'd have a success DSN followed by a failure DSN. Not
good.

> The semantics of a DSN are not defined this way.  There's no wiggle
> room for what amounts to lying.

> I find it rather strange that you can't generate an MDN.  Why not?
> (What am I missing?)

One case where this would be an issue is if reject was implemented in
an LMTP delivery agent as a return of a failure status. This would
result in a failure DSN and short of implementing a queue in the
LMTP delivery agent there would be no way to avoid this. (And remember
that the point of LMTP is to avoid having a queue.)

In order to work around such restrictions I suppose we could allow
use of DSNs if combining with any other action is blocked and
if the imeplementation is sure to block generation of a spurious
success DSN. But this is rather intricate, and I remain to be convinced
the added complexity is worth it.

				Ned

To: [email-masked] (Sam Robertson)
Cc: MTA Filters <[email-masked]>
Subject: Re: MDNs vs. DSNs
From: Tim Showalter <[email-masked]>
Date: 09 Sep 1999 01:09:27 -0700
Lines: 38
Sender: [email-masked]

Sam Robertson <[email-masked]> writes:

> Generating MDN's in our implementation is not possible at this point,
> yet we want to support the reject action.  Aside from all the features
> provided by supporting RFC 2298, why is an MDN an absolute requirement?

We want a standard reply with well-known semantics.  MDN has standard
semantics, but they are weak enough to allow for what a reject action
implies.  Specifically, a "deleted" MDN allows for the ambiguity that
"maybe the recipient deleted your message, or maybe he deleted it and
kept it".

The semantics of a DSN are not defined this way.  There's no wiggle
room for what amounts to lying.

I find it rather strange that you can't generate an MDN.  Why not?
(What am I missing?)

> Is there anyway we might be able to change the wording in 4.1 to read:
> 
>    The optional "reject" action refuses delivery of a message by sending
>    back an [MDN] or [DSN] to the sender.

MDNs and DSNs are not interchangable, so I don't want to make this
change.

> Regardless of whether we can change the wording at all, the second
> sentence in the first paragraph of 4.1 should start with a capital R.

er, actually, I think the word "It" is missing in there.  Thanks.

> In addition, in defining the action 'redirect' we should define the
> behavior without forcing someone to know what a .forward file using
> sendmail under UNIX does.  In other words we should define it in
> explicit terms???

It is defined in explicit terms in the next sentence.  I'd entertain
any suggestions of specific wording that you'd care to offer.

Date: Wed, 08 Sep 1999 18:11:52 -0700
From: [email-masked] (Sam Robertson)
Organization: Netscape Communications a subsidiary of America Online
To: MTA Filters <[email-masked]>
Subject: MDNs vs. DSNs
Sender: [email-masked]

I'm probably resurrecting a dead horse here, but let's see.

Generating MDN's in our implementation is not possible at this point,
yet we want to support the reject action.  Aside from all the features
provided by supporting RFC 2298, why is an MDN an absolute requirement?

Is there anyway we might be able to change the wording in 4.1 to read:

   The optional "reject" action refuses delivery of a message by sending

   back an [MDN] or [DSN] to the sender.

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

   A reject message SHOULD take the form of a failure MDN but MAY be a
DSN as specified  by
   [MDN] [DSN].

... continued specifics about MDN verbage ...

Regardless of whether we can change the wording at all, the second
sentence in the first paragraph of 4.1 should start with a capital R.

In addition, in defining the action 'redirect' we should define the
behavior without forcing someone to know what a .forward file using
sendmail under UNIX does.  In other words we should define it in
explicit terms???

Sam Robertson