Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)
RFC 5437

[Ballot comment]
Stating that the "from:" header must be an email address is a bit imprecise
as there are various syntax representations for an email address (e.g.,
RFC 2822 allows a display name and folding whitespace in the address).
This could be clarified by specifically referring to RFC 2821 "Mailbox"
ABNF rule.

[Ballot discuss]
So the following text was added to deal with my discuss...

  The XMPP notification service associated with a Sieve engine MUST NOT
  leak presence (network availability) information regarding users of
  the service.  In particular, the service MUST NOT reveal presence
  information via a notify_method_capability test to entities that are
  not authorized to know such information (e.g., via a presence
  subscription as specified in [XMPP-IM]).

Now this would resolve the problem but I don't see how it is implementable. Only the XMPP server knows the privacy policy so I don't see how the sieve engine can do this. It seems there would be a way of doing this where the sieve server subscribed for the information on behalf of who it planned to disclose it to instead of tightly binding the policy such that the xmpp and email server have to interact in a proprietary way. I'm not sure how you are thinking of implementing this - let me - I may just be missing the boat on what you are thinking of. Thanks.

[Ballot discuss]
My apologies for missing section 2.2 on first read. In section 2.2 - I think a bit more is needed about the who does the subscription. Imagine Alice and Bob both use the notification from same email server. However, imagine that Alice does not allow Bob to to see Alice xmpp presence information. What I would like to stop is for Bob to be able to write a sieve rule that reads Alice's presence status and basically informs Bob is online or offline by what the sieve script does. I can see a solution to this where the Alice only authorizes the sieve server to read presence for her scripts but not for Bob's scripts. It seems like setting the from in the xmpp subscript in a particular way could resolve this issue.

It may be that section 2.1 already covers this but hard to tell. If the current document covers this attack - glad to understand how and clear.

If this makes no sense, call me and I can clarify.

[Ballot comment]
I'm not exactly sure if this is a discuss level issue or not. I think the document should strongly point out that the from attribute in the xmpp message element is not generated by the ":from" tag in the Sieve script. I think it would help to provide advice what the xmpp from was set to because clients are going to need to be able to add access rules to allow message from this sender. Once you start adding in any sense of strong identity, (imagine DKIM in the email case), this gets even more critical. If I did make this a discuss, I think i would say something along the lines of the security section should provide details on how the receive of the xmmp message knows about  authentication of a notification message.

[Ballot discuss]
I think this needs text to cover how the XMPP interacts with the "online" state in notify_method_capability of the base document. I suspect this was just missed - if there is some good reason this is not in this document, I'm glad to remove this discuss.

[Ballot discuss]
I expected this document to follow the "MUST" guidelines in the security
considerations section of draft-ietf-sieve-notify-11.txt that apply to
notification methods.  But I don't see text addressing notification loops.

There are two implicit mechanisms present that could be used for loop
prevention. These are the "headline" notification type (which I gather
is roughly equivalent to RFC 3834 auto-submitted), and the fact that
Resent-From is a trace header field and not to be used for replies.
However, the former is optional (making it not necessarily useful for
loop detection) and the latter may not be known to implementers less
familiar with the details of email.  Furthermore, the behavior of "the
XMPP address of the notification service associated with the SIEVE
engine" is not specified.  If that service generates XMPP auto-replies
then there could definitely be problems with looping or denial of
service (e.g. if the user set the to address to be the address of the
XMPP service that generates notifications).

Another problem: the syntax for the ":from" notify tag is supposed to
be defined by the mechanism.  However, this document explicitly places
no syntax restrictions on the value of from while at the same time
copying the value into a header field ("Reply-To") with syntax
restrictions.  For interoperability, I recommend stating explicitly
that the ":from" notify tag has URI syntax or the syntax of the
XMPP/SIP Reply-To header.

[Ballot comment]
I'm a bit puzzled at why the requirement that the notification sender
must be the notification service is at must level.  That doesn't seem
to be necessary for interoperability or security or for any of the
other reasons we typically place requirements at must level.  I think
should would be more appropriate.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following assignments in the "Sieve Notification Mechanisms" registry located at
http://www.iana.org/assignments/sieve-notification [TBD -- RFC-sieve-notify-10]

Mechanism name: xmpp
Mechanism URI: RFC4622
Mechanism-specific tags: none
Standards Track/IESG-approved experimental RFC number: this RFC
Person and email address to contact for further information:
Peter Saint-Andre
[RFC-sieve-notify-xmpp-06]

We understand the above to be the only IANA Action for this document.