draft-ietf-sieve-imap-sieve-00 - expired. Authors please report. My intent
is to issue a last call on this once we have completed the other last calls
mentioned above.
From my IETF 78 notes:
* Needs reviews, especially from Ned, also from others.
* I will revise the draft to keep it from expiring, chairs will
ask Ned again for review.
I thought I had already posted a rev of it for that purpose, but I see
that I didn't. I will now. I'd rather have Ned's review before WGLC,
but during is fine as well. I'm very reluctant to send this to the
IESG without reviews from Ned and at least two or three others who
have given it thorough thought.
I just finished reviewing the latest version. The good news is almost all of
the semantic mismatch problems have been addressed, but there are still a lot
of other issues.
Section 1.1, second paragraph. The required support for Sieve environment
should be mentioned here.
[[anchor2: Note about identity: We might want to use Sieve to impose
fine-grained access controls. In final delivery, there's no identity
for the "filer". Here, there is: the logged-in IMAP user. How do we
get at that identity?]]
I don't see why this cannot be done with one or more environment items. As a
concrete proposal, I'd suggest having two: The user id and the primary email
address associated with the "filer". (These may be the same on some systems.)
Section 2: Thinking about it, "the IMAP IMAPSeive extension" sounds prety
swkward and redundant. Is there any reason not to simply call this the IMAP
SIEVE extension? (Or is it too late to change this?)
[[anchor3: Sieve has no way to get the annotations, so is there
really value in being told about annotation changes here? Maybe push
that into a sieve-annotations extension later.]]
Another problem is that IMAP ANNOTATE is currently experimental, which could
make getting this onto the standards track much harder. I think the handling of
annotations should be pushed off another specification.
2.3.1. Changes to Metadata
Maybe I'm missing something, but I don't see any actual changes to the metadata
extension in this section. All it does is use metadata for a particular
purpose. How about changing this to "Use of Metadata"?
Section 2.3.1: Managesieve script names are implicitly qualified by the
authentication credentials used to access the server. Although RFC 5804 says
nothing about how "active" Sieves are associated with a mailbox, the obvious
approach is that the same credentials that identify you as the owner or a given
mailbox will, if used in ManageSieve, result in a SETACTIVE command associating
the named Sieve with delivery to that mailbox. (This probably should be stated
explicitly in a future revision of ManageSieve, because without knowing this
relationship holds it makes writing a useful client to manipulate Sieves nearly
impossible.) Also note that this in no way dictates how an implementation
actually performs this association. SETACTIVE could be implemented by pushing
the script from the ManageSieve server to the IMAP server, or by having the
IMAP server fetch the script from the ManageSieve server.
Anyway, the present draft carries this association much further, mapping an
entire collection of named scripts (presumably all associated with the same set
of authentication credentials to each mailbox, along with a bit of handwaving
about how there might be a distinguished collection that's associated with the
entire server. Of the immediate implications of this is it constrains the
implementation choices for hooking ManageSieve up to IMAP. Another is that
there's no way to share scripts by referencing one in a different collection.
The draft also seems to think that by not explicitly requiring ManageSieve, it
makes lots of other implementation approaches possible. But this isn't really
true. The draft is quite clear that what appears in value.shared under
"/IMAPSieve/Script" is, with the exception of the metadata: prefix, just a
name. There are any number of potential storage locations and methodologies
(LDAP with single entries for each user is the obvious one) where this doesn't
map very cleanly if at all.
But the real question is why should be limit ourselves this way? Why not make
the contents of "/IMAPSieve/Script" a URL? (The metadata: prefix can then be
defined as a URL.) If we want to reach into ManageSieve, use a sieve: URL. (I
do see a big problem with this currently - RFC 5804 appears to have badly
botched the specification of sieve: URLs - the authority field is mandatory
when it shouldn't be, and the owner field is encoded into the URL path when it
should have been extracted from the authority field if it is present. The way
it's done now, you cannot write sieve:///scriptname and have it mean what it
should mean: Select out of the mailbox owner's scripts.
Now, there is no doubt that allowing URLs creates additional concerns, mostly
security related. But we've dealt with this sort of thing before, e.g., in
BURL. All we have to say is that metadata:foo MUST be implemented and sieve:bar
(modulo some fixes to RFC 5804) SHOULD work if ManageSieve is available.
If this goes too far, then at a minimum I believe this section needs to be
more explicit about how, if ManageSieve is used, the mapping from script
collections in ManageSieve to a mbilbox works.
[[anchor4: Redirect assumes message can be submitted as is - not a
valid assumption in this context. What do we do if the decision is
"redirect" and there's not enough information to do it? Also, some
have been concerned about, say, a flag change that has the Sieve
effect of forwarding the message somewhere. Perhaps we should just
forbid redirect.]]
I think the solution here is to explicitly say that redirect does a SUBMIT
operation with the redirect address as the RCPT TO. The MAIL FROM SHOULD
be set to the address of the mailbox owner. The text should note that SUBMIT
servers are allowed to do message fixup, but if the message is missing
any required header fields it MAY be rejected by the server.
Section 3.5 - Does requiring reject generate an error, or do you have to
actually try and use it? I would prefer for the text to state that requiring
reject MUST generate an error. The only downside I see is that this might
prevent you from using the same script in IMAP that you do for deliveries,
but since you cannot count on the require being allowed, I don't think that's
a big problem. (And note that you can always use ihave to work around
this issue.)
This section also needs to be updated to mention ereject as well as reject.
And I see no mention of the envelope or notary extensions in this document,
both of which need to be banned.
Better still, merge this section with 3.10 (vacation) and just have a list
of all the extensions known to be invalid in IMAPSieve.
[[anchor5: Should editheader be allowed to change header fields that
aren't saved in place, such as for redirect or fileinto? Editheader
would still have to be banned for "keep", but not otherwise.]]
I think this change would be a good idea.
[[anchor6: Should this just require imap4flags? Some implementors
have said they wouldn't bother with it without the ability to
manipulate flags. And what values of flags does it see -- before or
after the change? If it changes them, can it see the originals? Can
it reset changes?]]
First, I think imap4flags should be required, just like environment is
required.
In hindsight, I guess we should have defined imap4flags with semantics similar
to editheader, with uses in other contexts always starting out with an empty
flag set. But's it's much too late to change this now.
The obvious thing to do here is to say that the internal flag state variable
starts out set to the flags the message was going to recieve. But this is
actually a little problematic, because AFAICT there's no way to copy the
setting of the internal variable to a real variable so you can manipulate it as
a string.
The altnerative is some sort of special variable, or maybe a currentflags
environment item. Absent use cases where the current flag list needs to be
examined as a string, I don't see sufficient cause to do this. (And keep in
mind that we have the changedflags environment item to tell us what flags
have changed.
This section also needs to discuss how use of :flags interacts with
flags that are set by other means.
Section 3.10 - merge with 3.5, per above discussion.
[Spamtest] [[anchor7: We need to say something about the spamtest/
virustest extension. We need to be able to scan appended messages.
And we can't use headers to communicate spam status, because the
message is immutable. What should we say here?]]
I disagree. There are lots of extensions that define tests on or derived from
message content: relational, variables, spamtest, virustest, body, date, index,
and subaddress. AFAICT the difference between delivery time and IMAP store
Sieve has no material effect on any of these. I think the right thing to do is
simply list all the ones that have been published that work here and say that
there's no problem using them.
As for the issue of status being communicatd via headers, this is precisely the
problem that spamtest/virustest solves: The information is kept out of band,
and in a universal format. To the extent there is a problem here, it is out of
scope for this draft: Some spam filters, notably ones that use milter, are
incapable of communicating via a mechanism like spamtest/virustest. If the
specific virtues of using spamtest/virustest needs to be spelled out, an
example would be a great way to do that.
There's one other extension that needs to be discussed, though - mime-loops.
The test part is fine, but the message modification parts, not so much.
Section 3.11:
Implementations MAY invoke different Sieve scripts for the different
conditions described in this document (append, copy, flag changes,
annotation changes). If the actions to be taken are common, and the
implementation supports the [Include] extension, the common script
code can be included as specified there.
Really? I don't see how the single Sieve script per mailbox model allows for
different scripts for different conditions.
Section 3.15: Defer to annotate extension draft.
Section 3.16:
This extension does not affect the operation of any tests or
comparisons.
Well, it invalidate at least one test: envelope, and may alter the behavior
of hasflag on the internal variable. So this is incorrect. I suggest changing
this section to say that the behavior of tests in the Sieve base (header and
address) is unchanged. Other tests are by definition extensions.
Section 4, second example: The use of notify appears to be aligned with the old
notary draft, not the current specification.
Section 5: Loops can also be caused by redirect. Based on past experience with
IESG review, this needs to be discussed here.
Section 6.5: Defer to future annotations extension.
Section 7.1 - the reference:
[Manage] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely
Managing Sieve Scripts", RFC editor queue, http://
tools.ietf.org/html/draft-ietf-sieve-managesieve,
January 2009.
needs to be updated to refer to RFC 5804.
That's it!
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve