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
(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
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve