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

From: [email-masked]
Date: Fri, 08 Jul 2011 14:48:41 -0700

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sieve-imap-sieve-02.txt

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Jul 2011 17:56:09 -0400

> 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.
>
...
> http://www.ietf.org/internet-drafts/draft-ietf-sieve-imap-sieve-02.txt

In this update, I've resolved everything from Ned's very old review,
except for one, about ManageSieve.  I've also left one comment of my
own in there.  Look for "[[" to see both, and please help me resolve
them.

Everyone, please review this version.  Ned especially, will you see if
you think this takes care of your issues?

The only one I didn't understand is why envelope tests should
necessarily be banned here.  It's possible that the sever has stored
envelope information with the message, and that Sieve tests on that
envelope information will work normally.  It's true that for messages
that have been APPENDed, there will probably be no envelope
information, so perhaps I just need to add something that says that
envelope tests might not work if there's no applicable envelope
information, and that should cover it.  Yes?

Barry

---

From: [email-masked]
Date: Mon, 11 Jul 2011 10:12:19 -0700 (PDT)

> you think this takes care of your issues?

I'll try and do a review this week.

> information, and that should cover it.  Yes?

Yes, it's possible  that an IMAP server supports some sort of private extension
to attach envelope information to messages. But what are its semantics? Does
the envelope data survive COPY operations? (I can make an argument that it
should. I can also make an argument that it shouldn't.) What about other new
message building mechanisms like CATENATE? And of course APPEND is a big
problem, as you mentioned.

And what about implementing envelope "from" by looking at return-path and
envelope "to" by looking at Received: for clauses? Is this permissible?

Standardized tests to work consistently across conforming implementations. The
envelope test in this context depends on the implementation supporting an
unspecified extension with unspecified semantics. This is not a recipe for
interoperability, and absent a specification for an IMAP extension for
retaining envelope information, I don't see how we can legitimately include
this.

					Ned

---

From: Barry Leiba <[email-masked]>
Date: Mon, 11 Jul 2011 13:46:23 -0400

> retaining envelope information, I don't see how we can legitimately include

Makes sense.  I'll put something in the next version that says that
all envelope tests, whether from the base or as added by extensions,
are either inapplicable or have serious interoperability issues when
done at other than final-delivery time.  They, therefore, are not
allowed here.

Barry

---

From: Stephan Bosch <[email-masked]>
Date: Wed, 27 Jul 2011 16:22:16 +0200

> 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