Subject: Comments about draft-martin-managesieve-00.txt

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Feb 2000 00:56:33 -0700

>1.1.  Changes
>
>    Changes since 00
>
>    -dropped syncronized literals. added HAVESPACE command

The ABNF grammar still allows synchronizing literals. Update grammar or
leave it (see HAVESPACE comment)

>1.6.  Script Names
>
>    Sieve script names may contain any valid UTF8 characters, but ***names
>    must be at least one character long***. ...
               
When one reads the draft for the first time it is not clear why you have
such restriction.
It is better to explain that empty name has different semantics when
SETACTIVE is used.

>2.  Commands
>
>    The following commands are valid. Prior to successful authentication
>    only the AUTHENTICATE, CAPABILITY, STARTTLS, and LOOGOUT commands
                                                      ^^^^^^^
Typo in LOGOUT

>2.1.  AUTHENTICATE Command
>
...
>
>    The service name specified by this protocol's profile of SASL is
>    "imap" since implementations are generally tied to an IMAP
>    installation.

I object because the service name is an element used in several SASL
mechanisms (at least KERBEROS_V4, GSSAPI & DIGEST-MD5)

>    [SASL-ANON]. SASL mechanisms which use plaintext passwords
>    (including the PLAIN mechanism [PLAIN]) MUST NOT be used unless a
>    security layer is active or backwards compatibility dictates other
>    wise.

I don't see the case of "backward compatibility" for the protocol. The
situation is different from POP3/IMAP4 where PLAIN is widely deployed.

>2.2.  STARTTLS Command

How client/server should behave if TLS negotiation fails?
There was some discussions in TLS Mailing List
(<[email-masked]>) regarding TLS and SMTP.

>2.5.  HAVESPACE Command
>
>    Arguments:
>         String - name
>         Number - size
>
>    The HAVESPACE command is used to query the server for available
>    space. Clients specifiy the name wished to save the script as and
>    it's size in octets.

Why do you want to pass name to HAVESPACE, i.e. does it make any
difference whether name is the name of an existing script or  not?

Also, we was discussing HAVESPACE with Lyndon and he pointed out that
there is a race condition in using HAVESPACE (imagine two clients wants
to store script for the same user. There is enough space for any of them
but not for both).

I prefer IMAP approach: use synchronizing literals in PUTSCRIPT. If
server respond '+ ...', then it will accept the script,
otherwise it will return NO.

>2.6.  PUTSCRIPT Command
>
>    Arguments:
>         String - Script name
>         String - Script content
>
>    The PUTSCRIPT command is used by the client to submit a Sieve script
>    to the server.
>
>    If the script already exists upon success the old script will be
>    overwritten. The old script MUST NOT be overwritten if PUTSCRIPT
>    fails in any way.

I suggest adding "A script of the empty length erases script from the
server" (i.e. it will not show up in LISTSCRIPTS anymore)

>3.  Formal Syntax
...
>
>    response-authenticate = *(string CRLF / response-okno / response-special-ok)

I think response-authenticate should look like:

response-authenticate = *(string CRLF) (response-okno /
response-special-ok)

i.e. any number of string CRLF followed by OK or NO

General:

What do you think about adding response codes for various failures?

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Feb 2000 01:33:06 -0700

...
>    Server implementations SHOULD support proxying so that an
>    administrator can administer a user's scripts. Proxying is when a
>    user authenticates as himself but logs in as another user.

Authorization is much better term, IMHO.

>3.  Formal Syntax
    SAFE-UTF8-CHAR        = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 /
                            UTF8-5 / UTF8-6

SAFE-CHAR and others are not defined in the ABNF

Alexey

---

From: Tim Showalter <[email-masked]>
Date: 07 Feb 2000 12:58:45 -0800

I have a couple comments on Alexey's comments.  I don't think I've
read the draft in detail, so please pardon my ignorance.

> mechanisms (at least KERBEROS_V4, GSSAPI & DIGEST-MD5)

I object as well.  The service name matters.

> >    security layer is active or backwards compatibility dictates other

This paragraph seems to be unnecessary.  PLAIN already states a
stronger requirement, and you can't weaken it here by pleading to
backwards compatibility.  Implementations that implement cleartext
PLAIN are in violation of the protocol despite the best of intentions.

> situation is different from POP3/IMAP4 where PLAIN is widely deployed.

Backwards compatibility is an issue.  If a system is authenticating
against a Unix passwd database, plaintext is the only thing that
works.

> otherwise it will return NO.

This has the same race condition as HAVESPACE except it adds
synchronizing literals.

PUTSCRIPT command has to be able to fail... or we can have a two-phase
commit.  :-)

> What do you think about adding response codes for various failures?

Please consider these.  Adding them would greatly raises the hopes of
intelligent error recovery in client implementations, something that
seems to be very difficult for IMAP clients.  (Fortunately this is
much simpler than IMAP.)

Tim

---

From: Timothy Martin <[email-masked]>
Date: Mon, 7 Feb 2000 18:10:07 -0500 (EST)

> PLAIN are in violation of the protocol despite the best of intentions.

Agreed. I'm not sure why I didn't listen to you the first time :)

> This has the same race condition as HAVESPACE except it adds

It doesn't have to. Once the server agrees to the syncronization it 
can reserve that space because it knows the client will send a
script. However, this could possibly lead to denial of service attacks 
and greatly complicates implementations.

> seems to be very difficult for IMAP clients.  (Fortunately this is

Would using the ACAP response codes be a good idea?

Thanks,
Tim

---

From: Tim Showalter <[email-masked]>
Date: 07 Feb 2000 15:57:07 -0800

Timothy Martin <[email-masked]> writes:

> > > >    [SASL-ANON]. SASL mechanisms which use plaintext passwords [..]
> > This paragraph seems to be unnecessary.  [...]

I said that before?  At least I'm consistant.

> and greatly complicates implementations.

HAVESPACE can also reserve the space.  It moves the burden of doing so 
elsewhere, which may not be the best thing to do.

But the command still has to be able to fail.  What makes you think
that write(2) is going to succeed anyway, even if you've got the
space?

> Would using the ACAP response codes be a good idea?

They're probably the best thing going.  They had several advantages
over IMAP with no real additional cost.

By the way, if you're not already using quoted strings for response
text, please consider that, too.  It makes tokenization easier.

Tim

---

From: Timothy Martin <[email-masked]>
Date: Mon, 7 Feb 2000 17:58:54 -0500 (EST)

> It is better to explain that empty name has different semantics when

Good point. I'll try to phrase it better.

> mechanisms (at least KERBEROS_V4, GSSAPI & DIGEST-MD5)

I agree with this objection. Are there any objections to the use of
the service name "sieve"?

> situation is different from POP3/IMAP4 where PLAIN is widely deployed.

As Tim points out, I was referring to the large number of sites that
refuse to use strong authentication and insist on storing their
plaintext passwords in questionable places.

> (<[email-masked]>) regarding TLS and SMTP.

I have not been keeping up with that list. If there is a way to deal
with TLS negotiation failing will it be a generic way that all
protocols will be able to inherit or will something protocol specific
need to be written?

> difference whether name is the name of an existing script or  not?

Yes since it is overwriting the script.

Consider the example where you have a 10K limit and one script "foo"
of size 6K on the server. 'HAVESPACE "bar" 7000' would fail but
'HAVESPACE "foo" 7000' would succeed.

> otherwise it will return NO.

The grammer is simpler with the HAVESPACE command. PUTSCRIPT still
needs to check quota but a good client should be able to avoid sending 
the script data and then getting a quota violation 99% of the time.

> What do you think about adding response codes for various failures?

I didn't because I wasn't sure of a good/simple way of adding them?
Any suggestions?

Thanks,
Tim

---

From: Barry Leiba <[email-masked]>
Date: Tue, 08 Feb 2000 08:55:04 -0500

I have to say that this whole thing seems a little excessive, considering
the statement that this is an interim solution anyway:

    This an interim measure as it is hoped that eventually Sieve scripts
    will be stored on ACAP. This document is intended to proceed on the
    experimental track.

What we do is to specify a folder that's used to hold Sieve scripts (we 
use the name _Mail_Filters_; a standard name might be chosen), and the
contents (that is, what one would get from an IMAP "fetch body[]") of the
most recent message in that folder with the \Flagged flag set is used.
If there's an error in the script, the Sieve processor sends e-mail to 
the user and turns the \Flagged flag off and the \Draft flag on.

So the user can use any IMAP client to create the active script, by just
saving (APPENDing) the message to the _Mail_Filters_ folder, and then 
turning on the \Flagged flag.

This is not the ideal answer, but it *is* simple, and it *is* an interim
measure.  Think about it.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

---

From: Matthew Wall <[email-masked]>
Date: Tue, 08 Feb 2000 17:41:40 -0500

-- On Tuesday, February 8, 2000 8:55 AM -0500 the entity known as Barry 
Leiba <[email-masked]> wrote:

<begin quote>

> This is not the ideal answer, but it *is* simple, and it *is* an interim

<end quote>

To which Matthew Wall offers this response on Tue, 08 Feb 2000 17:35:58 
-0500:

Yah, I'd actually prefer using plain old SMTP for the submission protocol 
as the interim solution (assuming SMTP AUTH for authenticity), with a magic 
mail processor at the other end. Users can mess up these "magic" IMAP 
folders all too easily, other mail clients can stomp on them, etc. And I'm 
loathe to tie Sieve support into IMAP per se, since the 'delivery' concept 
is a bit different in the Cyrus IMAP concept than it is in other mailers. 
(Better, yes, but that's beside the point right now 8-).

Think about it: you can use a modified Listserv to parse the Sieve scripts, 
and good old email to return error messages. Users, at least anybody who's 
signed up for a mailing list, can understand this. If you ship the parts 
around using MIME application/sieve, presumably your well-behaved 
Sieve-cooperating MUAs can do some automated processing of results for 
presentation to the user and possible correction. In a worst case, a 
hand-prepared script can be emailed as text/plain. That's no worse than any 
other scheme that sends filters around in this manner.

As an interim hack, awaiting ACAP, LDAP, etc., I can't think of anything 
that's simpler and less problematic for other services, and requires little 
in the way of modification of existing software for Sieve other than the 
engine executing at the appropriate time.

- Matt

---

From: Timothy Martin <[email-masked]>
Date: Tue, 8 Feb 2000 17:58:59 -0500 (EST)

> text, please consider that, too.  It makes tokenization easier.

Our implentation always uses quoted strings but currently that isn't
required. It would seem requiring them for responses would make the
tokenization more difficult if anything.

---

From: Timothy Martin <[email-masked]>
Date: Tue, 8 Feb 2000 18:27:15 -0500 (EST)

> Date: Tue, 08 Feb 2000 08:55:04 -0500
> From: Barry Leiba <[email-masked]>
> Organization: Internet Messaging Technology; TR2_Xagent=WATSON
> 

I disagree with this solution for the same reason we don't store
addressbooks or preferences in IMAP folders. First of all it adds
complexity to server implementations. Also, mail clients that are not
aware of this addition would not be able to ignore it. A user might
see this _Mail_Filter_ folder, notice that the messages in it look
like garbage and delete them.

A better option might be to allow sieve script submission via
SMTP. The problems with this option is that the smtp server one
submits to often isn't the final delivery agent so it might not have
any knowledge of sieve (and therefor can't give the sieve
capabilities). Also managing multiple scripts this way seems
difficult.

My main concern would be that we'd be adding extensions to IMAP that
have little to do with mail access. I know writing yet another parser
is a pain but in IMO it is a lesser evil than adding yet another
addition to IMAP.

-Tim

---

From: Randall Gellens <[email-masked]>
Date: Mon, 14 Feb 2000 16:53:01 -0800

>the statement that this is an interim solution anyway:

I agree.  I don't think it's a good idea to go the yet-another-protocol 
route unless it moves us closer to where we want to be.

My proposal all along has been to use ACAP or a subset.  We have prototype 
implementations of an ACAP profile for Sieve (along with a Sieve engine) 
running on NT and Unix, and a prototype Windows GUI that manages scripts.

By using an ACAP profile, both client and server support becomes pretty 
easy, and the client can talk to a full ACAP server just as well as a mini, 
Sieve-only one.  So we get rapid deployment and move closer to a real 
solution (full ACAP servers).

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 14 Feb 2000 21:17:18 -0500 (EST)

Ok, we're all interesting in getting ACAP servers out there.
I'd love to just use ACAP.  However, defining an "ACAP profile" to
handle Sieve scripts isn't as easy as it sounds.

For instance:
  I want to be able to share my Sieve script with my coworkers, but
  not my boss (I filter all of his mail).

For instance:
  Since we don't want the ACAP server and IMAP server necessarily
  sharing the same filesystem, I want my IMAP server to be able to
  open contexts on my ACAP server that stores the scripts.  This way I
  don't have to do an ACAP search for every message delivery but I
  won't use out-of-date Sieve scripts.

Ok, great, now we need ACLs and contexts.  I'm sure I can justify just
about any other ACAP feature you want me to.

We (CMU) have a working ACAP server.  I'm willing to start putting
Sieve scripts on it next week.  I'd be extremely happy to say "we're
going to use ACAP" and see people implement ACAP servers to store
Sieve scripts.

I'm not sure this is going to encourage deployment of Sieve.

Or, rather: is anybody going to develop an ACAP server to deploy Sieve
in their products?

Larry

   Date: Mon, 14 Feb 2000 16:53:01 -0800
   From: Randall Gellens <[email-masked]>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Feb 2000 14:27:44 -0800

At 09:17 PM 2/14/00 -0500, Lawrence Greenfield wrote:
>However, defining an "ACAP profile" to

There are always going to be features that are desired in any Sieve access 
protocol.  The goal behind using a Sieve profile is to make it as easy as 
possible to deploy a protocol that meets the absolute minimum, and is 
upwardly extensible (by going to full ACAP).

>I want my IMAP server to be able to

You could also have an active client that opens contexts on the full ACAP 
server in which the Sieve scripts are stored, and when any of them change, 
pushes the change to the Sieve server.  But that's not my point.  My point 
is that people are going to want a lot in a Sieve access protocol, and 
developers want something that is very easy to implement and deploy.  I 
think a minimal ACAP subset meets the second goal, and provides a way to 
reach the first goal.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 Feb 2000 10:26:17 -0700

Sorry for the lack of response from my part. Just came back from UK.

> think a minimal ACAP subset meets the second goal, and provides a way to

I fully agree with Randy (In fact we had a private discussion with him
about the subject).

Currently ACAP profile for Sieve (ACAP Email Account Dataset Class) is
missing some of the functionality described in Tim's document.
Do people think it is worthwhile to extend dataset description?

Alexey