This extension appears to conflate two unrelated things: information
about the interpreter context and information about the message.
I don't think these two sets of information are similar enough that the same
interface should be used to get to both of them.
In particular I believe that the remote-host and remote-ip variables
are inappropriate and should not be standardized.
I believe an applicability statement should be added to the extension
making it clear that this extension is only for interpreter state and
that another extension should be designed for examining information
about the message.
I find the string "MUA" meaning anything that happens after delivery
confusing. I'd suggest another string--possibly "POST-MDA" and
reserve "MUA" for sieve scripts actually executed inside a MUA.
Alternatively perhaps "MUA" could mean the script is executed at the
direction of the MUA. That's not quite the same thing as
Section 4.3.3 claims that experimental RFCs are an appropriate
mechanism to register non-standards-track variables intended for wide
use. That seems wrong. I recommend revisiting the registration
In conclusion, I object quite strongly combining message and
interpreter context information. The other comments I'm making are
less serous. However based on the number of comments I think this
document needs significant positive review before it is ready to be
IETF mailing list