Sieve Extension for Converting Messages before Delivery
RFC 6558
Yes
(Pete Resnick)
No Objection
(Dan Romascanu)
(David Harrington)
(Gonzalo Camarillo)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 06 and is now closed.
Pete Resnick Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2011-12-01)
Unknown
Section 2
If a "convert" action cannot be completed -- perhaps because the
conversion failed, or because the requested conversion is not
available -- the message MUST remain unchanged, and the script
processing continues. In particular, no error condition is raised,
and no partial conversions are allowed.
To be clear, you mean '...MUST remain unchanged by that "convert"
action,...'
and
'...and no partial conversions due to a single "convert" action are
allowed.'
As written it implies no change is allowed (and changes already made
must be unpicked).
And (for my own clarity) this means that if there are two conversions
that would be carried out by a single convert command, the first
replacement is successful and the second fails, the result must not
include either replacement.
Maybe it would help to really spell this out.
---
I think you might comment on infinite recursions.
Suppose in your example 3.1 you had written
require ["convert"];
convert "image/tiff" "image/tiff" ["pix-x=320","pix-y=240"];
(as I see in the middle of 3.4)
It is easy to see how this might be interpreted as an infinite loop,
but also easy to cover the case with a line of text that says the
output of any conversion must be considered as atomic so that the
conversion never applies to its own output.
It would probably be possible to come up with worse (explosive)
scenarios.
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Harrington Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2011-12-01)
Unknown
Ari Keränen's review: For people not that familiar with IMAP extensions and Sieve the abstract of the document is not not immediately clear. Maybe clarify this with: s/IMAP CONVERT/the "CONVERT" IMAP extension/ s/Sieve/Sieve mail filtering language/
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2011-11-28)
Unknown
In Section 2.1, it might be helpful to cite RFC 5228 on the definition of "implicit keep".
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2011-11-26)
Unknown
Does rfc5259 support doing things in loops? If not, then it seems like this makes the potential DoS on the server worse to the extent that the client can craft a CPU intensive loop. If applicable, then that should be noted.
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
()
Unknown