Everyone, please review this version. Ned especially, will you see if
you think this takes care of your issues?
I'll try and do a review this week.
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?
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
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve