And you thought that this document was done ;-).
IESG didn't think so. Here are the two main issues:
1). Cullen Jennings:
>The document says that one SHOULD do loop detection - I think it needs
to point
>at some advice that provided at least one way to implement loop
detection at a
>level of detail high enough that it is implementable.
I think this was discussed on the mailing list before and there was
consensus that this should be addressed in a separate document, because
this issue is not specific to Sieve. Do I have this right?
2). Cullen Jennings:
>I see a serious problem with the allowing redirection to more than one
users.
>This allows a very high speed server in the center of the network to
perform a
>application of already large traffic. When filtering happens on an end
user
>email client it is no worse than what the client could do by just
sending new
>email. This is worse. It is also different than mailing lists which
hopefully
>have a consent mechanism. I am proposing fixing this by saying that
the limit on
>number of redirects SHOULD be one and the times to ignore this SHOULD
are text
>environments and such.
I've sent Cullen a reply saying that there are several implementation
that allow for multiple redirects.
However the document should have a security consideration on this issue,
if it doesn't already.
Opinions?
===============
Also, Cullen has suggested to drop the text about CMU FLAME language. I
welcome comments on this.