> 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
[email protected]
https://www.ietf.org/mailman/listinfo/sieve
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.