headers
Alexey Melnikov | 5 Feb 2000 08:56

Comments about draft-martin-managesieve-00.txt

>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
>
...
>
(Continue reading)

Permalink | Reply | 13 comments |
headers
Alexey Melnikov | 5 Feb 2000 09:33

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

Some additions:

>2.1.  AUTHENTICATE Command
...
>    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
Permalink | Reply | 0 comments |
headers
Tim Showalter | 7 Feb 2000 21:58

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

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.

Alexey Melnikov <mel <at> messagingdirect.com> writes:

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

I object as well.  The service name matters.

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

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.

> I don't see the case of "backward compatibility" for the protocol. The
> 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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Timothy Martin | 8 Feb 2000 00:10
Picon

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


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

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

> > I prefer IMAP approach: use synchronizing literals in PUTSCRIPT. If
> > server respond '+ ...', then it will accept the script,
> > otherwise it will return NO.
> 
> This has the same race condition as HAVESPACE except it adds
> synchronizing literals.

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.

> 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?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tim Showalter | 8 Feb 2000 00:57

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

Timothy Martin <tmartin <at> andrew.cmu.edu> writes:

> > > >    [SASL-ANON]. SASL mechanisms which use plaintext passwords [..]
> > This paragraph seems to be unnecessary.  [...]
> Agreed. I'm not sure why I didn't listen to you the first time :)

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

> > This has the same race condition as HAVESPACE except it adds
> > synchronizing literals.
> 
> 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.

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?

> > > 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.)
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Timothy Martin | 7 Feb 2000 23:58
Picon

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

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

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

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

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

> >    [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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barry Leiba | 8 Feb 2000 14:55
Picon
Favicon

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

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  (leiba <at> watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
Permalink | Reply | 2 comments |
headers
Matthew Wall | 8 Feb 2000 23:41

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

-- On Tuesday, February 8, 2000 8:55 AM -0500 the entity known as Barry 
Leiba <leiba <at> watson.ibm.com> wrote:

<begin quote>

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

<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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Timothy Martin | 8 Feb 2000 23:58
Picon

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

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

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.
Permalink | Reply | 0 comments |
headers
Timothy Martin | 9 Feb 2000 00:27
Picon

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

> Date: Tue, 08 Feb 2000 08:55:04 -0500
> From: Barry Leiba <leiba <at> watson.ibm.com>
> Organization: Internet Messaging Technology; TR2_Xagent=WATSON
> 
> 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

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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane