[Top] [All Lists]

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

2011-07-27 09:21:19
On 7/8/2011 11:48 PM, internet-drafts(_at_)ietf(_dot_)org 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 
        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:

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


sieve mailing list

<Prev in Thread] Current Thread [Next in Thread>