Re: I-D Action: draft-ietf-sieve-imap-sieve-02.txt

On 7/8/2011 11:48 PM, [email protected] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.
>
> 	Title           : Support for Sieve in Internet Message Access Protocol (IMAP4)
> 	Author(s)       : Barry Leiba
> 	Filename        : draft-ietf-sieve-imap-sieve-02.txt
> 	Pages           : 24
> 	Date            : 2011-07-08
>
>     Sieve defines an email filtering language that can, in principle,
>     plug into any point in the processing of an email message.  As
>     defined in the base specification, it plugs into mail delivery.  This
>     document defines how Sieve can plug into points in the IMAP protocol
>     where messages are created or changed, adding the option of user-
>     defined or installation-defined filtering (or, with Sieve extensions,
>     features such as notifications).
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sieve-imap-sieve-02.txt

I gave this a quick review. I have the following comments and questions:

1) According to Section 2.1, the IMAPSieve capability for Sieve is 
case-insensitive. This conflicts with the base specification of Sieve in 
RFC5228. Section 6 of that RFC explicitly states that Sieve capability 
names are case-sensitive. Consistency with all other Sieve extensions 
suggests using an all-lowercase name.

2) Section 3.11 prohibits reject, ereject and vacation. Perhaps it 
should also prohibit any future actions that send a response back to the 
sender.

3) I'm assuming it is allowed to use the ihave extension to test for the 
prohibited extensions and imapsieve itself (which i guess should be 
mentioned somewhere). This allows writing scripts that can run in both 
normal and IMAPSieve context, using the ihave test. Perhaps the wording 
of the prohibition should then be a bit different: the prohibition 
should not be directed at the scripts, but rather at the Sieve 
interpreter, which MUST NOT have the ereject, reject and vacations 
extensions available in imapsieve context.

4) Invoking the Sieve script linked to the mailbox for every possible 
event seems inefficient, especially when only one event (e.g. APPEND) is 
of interest. Whould a means to explicitly select which events are 
applicable for a (mailbox, script) pair be useful? Also, what happens if 
some new event type emerges in a future extension and gets enabled on 
the server? Are existing Sieve scripts expected to recognize (i.e. 
ignore) this event?

5) Related to the above, the first and second paragraph of section 4.2 
seem to be contradictory. The first suggests that different scripts CAN 
be invoked, whereas the second paragraph says that only a single script 
is used.

6) Allowing redirect seems risky. What if I accidently 'drag' in my 
mailclient the content of some enormous mailing list mailbox to a 
Sieve-enabled mailbox with a redirect? Shouldn't this at least be 
bounded somehow?

7) Since this document essentially defines a whole new context in which 
Sieve scripts can be executed, it can be helpful for the reader to have 
an introductory section that outlines and summarizes the main 
differences between the new and the familiar context, e.g. things like 
the lack of an envelope as pointed out earlier on this list, the 
undesirability of sending responses back to senders, etc.

8) The environment extension defines a "location" item which specifies 
where the Sieve script is being executed. So which value will it return 
in IMAPSieve context? I am assuming "MS", but that should be mentioned 
somewhere I guess. Similarly, the "phase" item will return "post".


Regards,

Stephan
_______________________________________________
sieve mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sieve