headers
Stephan Bosch | 7 Jul 2008 10:21
Picon

Re: Treat as a WGLC: draft-martin-managesieve-10.txt


Hi Alexey,

Alexey Melnikov wrote:
>> I thought the idea was to simply allow and ignore the '+' for legacy 
>> implementations.
>>
> ManageSieve was largely documenting Cyrus timsieved and timsieved 
> never emitted "+" to clients.
> If you know any server that emits non-synchronizing literals to 
> clients, please let me know. But absent any evidence that this would 
> break deployed servers, I would prefer to keep consistency with IMAP 
> and timsieved.
Ok, if I encounter any in the near future I will notify you.
>> Strictly requiring it from clients seems cumbersome and will, to my 
>> opinion,
>> likely introduce even more incompatibilities. 
> As far as I know ManageSieve never allowed clients to send 
> synchronizing literals (literals without +). timsieved allows for that 
> (because it reuses IMAP parser), but I don't think it ever emits IMAP 
> style "+ go ahead" back to clients. So it is not consistent with IMAP 
> either.
>
> If people think that support for synchronizing literals in the 
> direction from the client to the server is needed, I can add that. But 
> I am not convinced that this is a problem either.
I am not so much interested in the (IMAP) synchronizing semantics of the 
'+' character. With version 08 of the managesieve specification the '+' 
character was indicated as 'only allowed from clients' in the comment 
somewhere in the ABNF. I am worried that some client implementors have
(Continue reading)

Permalink | Reply | 20 comments |
headers
Robert Burrell Donkin | 7 Jul 2008 14:05
Picon

Re: Treat as a WGLC: draft-martin-managesieve-10.txt


On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <stephan <at> rename-it.nl> wrote:
>

<snip>

> Ok, I did some preliminary implementation of the new commands. Regarding the
> NOOP command I have only one (nitpicking) remark. The managesieve
> specification explicitly lists which commands are valid before
> authentication. However, by introducing extensions this becomes a little
> more sketchy. The RENAMESCRIPT command is clearly not useful before
> authentication. However, implementors with IMAP experience might think of
> allowing NOOP before authentication, because in IMAP the NOOP command  may
> be issued before authentication.

failing to allow NOOP as may be expected violates the principle of
least surprise.

is there any reason for this?

in general, this protocol seems more than a little peculiar. it's
close in syntax to IMAP but has enough differences for IMAP
implementors to be surprised and confused by the differences.

is there any reason for this choice?

- robert
Permalink | Reply | 18 comments |
headers
Alexey Melnikov | 7 Jul 2008 14:18
Favicon

Re: Treat as a WGLC: draft-martin-managesieve-10.txt


Robert Burrell Donkin wrote:

>On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <stephan <at> rename-it.nl> wrote:
>  
>
><snip>
>  
>
>>Ok, I did some preliminary implementation of the new commands. Regarding the
>>NOOP command I have only one (nitpicking) remark. The managesieve
>>specification explicitly lists which commands are valid before
>>authentication. However, by introducing extensions this becomes a little
>>more sketchy. The RENAMESCRIPT command is clearly not useful before
>>authentication. However, implementors with IMAP experience might think of
>>allowing NOOP before authentication, because in IMAP the NOOP command  may
>>be issued before authentication.
>>    
>>
>
>failing to allow NOOP as may be expected violates the principle of
>least surprise.
>
>is there any reason for this?
>
>in general, this protocol seems more than a little peculiar. it's
>close in syntax to IMAP but has enough differences for IMAP
>implementors to be surprised and confused by the differences.
>
>is there any reason for this choice?
(Continue reading)

Permalink | Reply | 17 comments |
headers
The IESG | 7 Jul 2008 18:37
Picon
Favicon

Protocol Action: 'Sieve Email Filtering: Editheader Extension' to Proposed Standard

The IESG has approved the following document:

- 'Sieve Email Filtering: Editheader Extension '
   <draft-ietf-sieve-editheader-11.txt> as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working

Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-11.txt

Technical Summary

The SIEVE editheader extensions provides a way for a SIEVE script to add
or remove top-level message headers in the message being processed. This
allows SIEVE to interact with other components in the mail delivery
system via information in message headers.

The extension defines an addheader action with the option to have the
header inserted at the start or end of the entire block of message
headers. Consideration is given to issues of header encoding and
possible length limits, as required by internet email standards.

The extension defines a deleteheader action which can optionally delete
all, the last, or a specific indexed header in the top-level message
headers.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Burrell Donkin | 7 Jul 2008 21:27
Picon

Re: Treat as a WGLC: draft-martin-managesieve-10.txt


On Mon, Jul 7, 2008 at 1:18 PM, Alexey Melnikov
<alexey.melnikov <at> isode.com> wrote:
> Robert Burrell Donkin wrote:
>
>> On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <stephan <at> rename-it.nl>
>> wrote:
>>
>> <snip>
>>
>>>
>>> Ok, I did some preliminary implementation of the new commands. Regarding
>>> the
>>> NOOP command I have only one (nitpicking) remark. The managesieve
>>> specification explicitly lists which commands are valid before
>>> authentication. However, by introducing extensions this becomes a little
>>> more sketchy. The RENAMESCRIPT command is clearly not useful before
>>> authentication. However, implementors with IMAP experience might think of
>>> allowing NOOP before authentication, because in IMAP the NOOP command
>>>  may
>>> be issued before authentication.
>>>
>>
>> failing to allow NOOP as may be expected violates the principle of
>> least surprise.
>>
>> is there any reason for this?
>>
>> in general, this protocol seems more than a little peculiar. it's
>> close in syntax to IMAP but has enough differences for IMAP
(Continue reading)

Permalink | Reply | 16 comments |
headers
Aaron Stone | 7 Jul 2008 22:20
Gravatar

Re: Treat as a WGLC: draft-martin-managesieve-10.txt


On Jul 7, 2008, at 12:27 PM, Robert Burrell Donkin wrote:

>
> On Mon, Jul 7, 2008 at 1:18 PM, Alexey Melnikov
> <alexey.melnikov <at> isode.com> wrote:
>> Robert Burrell Donkin wrote:
>>
>>> On Mon, Jul 7, 2008 at 9:21 AM, Stephan Bosch <stephan <at> rename-it.nl>
>>> wrote:
>>>
>>> <snip>
>>>
>>>>
>>>> Ok, I did some preliminary implementation of the new commands.  
>>>> Regarding
>>>> the
>>>> NOOP command I have only one (nitpicking) remark. The managesieve
>>>> specification explicitly lists which commands are valid before
>>>> authentication. However, by introducing extensions this becomes a  
>>>> little
>>>> more sketchy. The RENAMESCRIPT command is clearly not useful before
>>>> authentication. However, implementors with IMAP experience might  
>>>> think of
>>>> allowing NOOP before authentication, because in IMAP the NOOP  
>>>> command
>>>> may
>>>> be issued before authentication.
>>>>
>>>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeffrey Hutzelman | 7 Jul 2008 22:23
Picon
Favicon

Re: Treat as a WGLC: draft-martin-managesieve-10.txt


--On Monday, July 07, 2008 08:27:59 PM +0100 Robert Burrell Donkin 
<robertburrelldonkin <at> gmail.com> wrote:

> i can see that's a tough choice: codification of existing (possibly
> dubious but at least well understood) practice verses the creation of
> a better protocol

The situation here is that we are standardizing a protocol which was 
already widely deployed.  In such cases, it is usually better to avoid 
breaking interoperability with the deployed base, especially if the 
deployment experience largely shows that the existing protocol works. 
Sometimes, there is no way to avoid making a backward-incompatible change 
to correct a problem, but I don't think this is such a case.

> it seems unfortunate that this means that a separate port is required
> for sieve management. a compatible extension to IMAP would allow sieve
> management using the same URI.

That makes the assumption that sieve scripts live only in IMAP servers, 
which I don't think we want to do.

-- Jeff
Permalink | Reply | 11 comments |
headers
Stephan Bosch | 7 Jul 2008 22:25
Picon

Re: Treat as a WGLC: draft-martin-managesieve-10.txt (OT)


Aaron Stone schreef:
> 
> On Jul 7, 2008, at 12:27 PM, Robert Burrell Donkin wrote:

> managesieve for dovecot:
> http://sinas.rename-it.nl/~sirius/
Off topic: that url is old. :) The new url is:

http://www.rename-it.nl/dovecot

Regards,

--
Stephan Bosch
stephan <at> rename-it.nl
Permalink | Reply | 2 comments |
headers
Aaron Stone | 7 Jul 2008 22:31
Gravatar

Re: Treat as a WGLC: draft-martin-managesieve-10.txt (OT)


Hey, that's the same domain as in your email address! ;-)

Is your implementation now consistent with the document in question?

On Jul 7, 2008, at 1:25 PM, Stephan Bosch wrote:

> Aaron Stone schreef:
>> On Jul 7, 2008, at 12:27 PM, Robert Burrell Donkin wrote:
>
>> managesieve for dovecot:
>> http://sinas.rename-it.nl/~sirius/
> Off topic: that url is old. :) The new url is:
>
> http://www.rename-it.nl/dovecot
>
> Regards,
>
> --
> Stephan Bosch
> stephan <at> rename-it.nl
Permalink | Reply | 1 comment |
headers
Stephan Bosch | 7 Jul 2008 22:36
Picon

Re: Treat as a WGLC: draft-martin-managesieve-10.txt (OT)


Aaron Stone schreef:
> Hey, that's the same domain as in your email address! ;-)
> 
> Is your implementation now consistent with the document in question?
> 
Not quite, as I did not release any changes as of yet. My latest changes 
should bring it pretty close though. However, I still don't have a 
proper quota implementation (which i personally see as a requirement).

Regards,

Stephan.
Permalink | Reply | 0 comments |

Gmane