[11:29:59] --- Lisa has joined
[11:45:45] --- Alexey has joined
[11:47:49] --- stpeter has joined
[11:48:22] --- cyrus_daboo has joined
[11:48:28] --- cnewman@jabber.org has joined
[11:48:42] <stpeter> greetings
[11:48:53] <Alexey> Morning everybody
[11:48:59] <Alexey> (or whatever)
[11:49:44] <Lisa> hi
[11:50:25] <stpeter> I replied to Chris's email with my perspective, but perhaps I was missing something
[11:50:47] <Alexey> After talking to Dave Cridland (who is unfortunately offline at the moment), my understanding is that the only single protocol loop possible in XMPP is auto-replies
[11:50:58] <Alexey> XMPP has no forwarding
[11:51:06] <stpeter> Alexey: correct, no forwarding
[11:51:31] <stpeter> Alexey: I have seen auto-replies in some clients (e.g., if the user is in "do not disturb" mode)
[11:52:21] <Alexey> Dave said that the entity generating XMPP notifications MUST NOT auto-reply to anybody
[11:52:44] <Alexey> This would prevent auto-reply loops, right?
[11:53:18] <stpeter> oh yes that seems like a good idea, but in general that would be the Sieve engine itself, right?
[11:53:44] <cyrus_daboo> FYI iChat has an 'Auto-reply with my Away message' option.
[11:54:18] <Alexey> stpeter: Exactly
[11:54:33] <Alexey> So it would be easy to put a requirement on such XMPP entity
[11:54:49] <stpeter> Alexey: yes, precisely
[11:55:12] <stpeter> cyrus_daboo: yes, that is a not-uncommon option in XMPP clients, but I think we're concerned here about the Sieve engine
[11:55:22] <Alexey> Chris, does this work for you, or do you have other use cases/concerns in mind?
[11:56:08] <cnewman@jabber.org> One non-discuss issue around this is the observation that it took the email world a while to realize an "Auto-Submitted" header is really useful and perhaps XMPP could learn that lesson sooner?
[11:56:29] <cnewman@jabber.org> The discuss level issue would be addressed by what you've outlined, however.
[11:57:11] <Alexey> Ok, so Peter and I would come up with 2 sentences: lack of forwarding and addressing auto-reply loops
[11:57:38] <Alexey> I can't comment on Auto-Submitted. Peter, is there anything like this in XMPP?
[11:58:02] <Lisa> If you give me that text here, then I can provide it as RFC Editor note during the discussion of the document
[11:58:04] <stpeter> the meaning of auto-submitted is not fully clear to me, so I need to understand it frist
[11:58:06] <stpeter> first
[11:58:22] <Lisa> we can also wait to deal with the discusses
[11:58:36] <stpeter> Lisa: ok let me wordsmith the forwarding text from my email to Chris
[11:59:37] <cnewman@jabber.org> The key point behind auto-submitted is the ability to label a message with "this came from an automatic agent rather than a human" that can be keyed to prevent loops. The headline type seems somewhat similar in concept so it may be sufficient.
[11:59:41] <Alexey> Auto-submitted is generated by vacation autoresponders, etc.
[11:59:48] <stpeter> well I think it would be better not to do this on the fly, Alexey and I should work to formulate correct text
[12:00:18] <Alexey> It would be better to get the text agreed today though. As I am on holidays tomorrow
[12:00:35] <cnewman@jabber.org> I do think an RFC editor note would be sufficient to address the discuss. The auto-submitted issue can wait.
[12:00:45] <stpeter> cnewman@jabber.org: yes that is the general idea of the headline type ("this is probably auto-generated and you should not reply to it") and we've had that since 1999, but some clients still don't honor those semantics
[12:02:50] <Alexey> Give Peter and myself 10 mins. We will wordsmith and post suggested text to the chatroom
[12:03:16] <cnewman@jabber.org> Sounds good.
[12:06:40] <Alexey> Lisa: regarding Cullen's discuss: I think he just missed the discussion in section 2.2
[12:09:48] <Lisa> Alexey: yes he did miss that
[12:10:32] <Alexey> I also need to read Cullen's comment. He might have missed some text about stanza's from as well
[12:15:25] <stpeter> ok here's what Alexey and I formulated:
[12:15:32] <stpeter> "SIEVE-NOTIFY specifies that a notification method MUST provide mechanisms for avoiding notification loops. One type of notification loop can be caused by message forwarding; however, such loops are prevented because XMPP does not support forwarding of messages from one XMPP address to another. Another type of notification loop can be caused by auto-replies to XMPP messages received by the XMPP notification service associated with the Sieve engine; therefore such a service MUST NOT auto-reply to XMPP messages it receives."
[12:20:49] <Alexey> The only other remaining bit is specifying the exact syntax for :from
[12:22:46] <stpeter> yes, perhaps the use of the ":from" is not clear to me, but my understanding is that it's the entity that generates the notification (not the triggering message), or a contact person associated with the generating entity -- but perhaps I misunderstand what it's for in generic Sieve notify scripts
[12:23:56] <Alexey> :from is an indicator from the sender about what generated the notification
[12:24:53] <Alexey> So if you have multiple email addresses going to the same IMAP/POP mailbox, you might want to set different :from's for notifications, depending on original email recipient
[12:25:00] <Alexey> Does this help?
[12:25:32] <stpeter> not yet :)
[12:25:50] <cnewman@jabber.org> The proposed text above sufficiently addresses part 1 of my discuss.
[12:26:09] <cyrus_daboo> Typically :from will be set to the recipient's email address - the one that caused the message to be processed by the sieve script.
[12:26:39] <stpeter> ok
[12:26:43] <stpeter> I see
[12:26:46] <cyrus_daboo> i.e. you send email to me at cyrus@daboo.name [mailto:cyrus@daboo.name], I will set :from to cyrus@daboo.name [mailto:cyrus@daboo.name].
[12:28:23] <stpeter> I thought we inherited the meaning of the ":from" tag from the notify spec and the fact that the notify-xmpp spec says "there are no special semantics here" meant that we were inheriting some semantics, but if that is not the case then we need to specify the semantics in the notify-xmpp spec
[12:29:02] <Alexey> Agree
[12:29:38] <Alexey> :from can just be transferred to a textual field
[12:29:41] <stpeter> Alexey: you agree that we are not inheriting semantics?
[12:30:13] <Alexey> I agree that we need to define the exact semantics, as there is nothing to inherit
[12:30:17] <stpeter> ok
[12:30:32] <stpeter> so shall we wordsmith that now, too?
[12:30:57] <Alexey> Sure
[12:31:38] <stpeter> ok Alexey and I will have a private chat about that and return :)
[12:31:54] <Alexey> Jabber is fun :-)
[12:32:02] <stpeter> heh
[12:33:16] <cnewman@jabber.org> For Cullen's discuss on the base sieve notify draft, I've updated my comment to include this:
[12:33:17] <cnewman@jabber.org> In response to Cullen's discuss, it is possible to construct parameters from message content using the Sieve variables extension, as the last paragraph in the security considerations points out. That paragraph points out the need for URL encoding of the parameters, but does not discuss the security implications of generating the address from message content. While I suspect most implementers/users would not be foolish enough to do that, particularly because the syntax gets so grotty, it wouldn't hurt to mention how dangerous that is. One simple remedy for the threat would be to simply disallow use of sieve variables in the method parameter of the notify command via script analysis. Note that I would not discuss over this issue, but I do think a brief comment on this issue in the security considerations would improve the document.
[12:38:59] <Alexey> I couldn't see text of Cullen's DISCUSS in the tracker
[12:39:42] <cnewman@jabber.org> Cullen's discuss: "I would like to talk about the security properties of being able to extract the list of users to receive a notification message from the incoming email. The first thing I would like to understand is if this is really needed. Once we get a handle on this, I'd like to figure out how to add some text about security concerns for this. I realize this discuss is crappy but I felt this was better than deferring the document. Basic issues is I want to talk about this, and then decide if any update is needed. Unless there is some cares where it should not be used, I would like to change "A notification SHOULD include means to identify / track" from a SHOULD to a MUST. I think the draft should provide a little bit of semantics around the meaning of "online". (As a side note, I think "open" may be a better term than "online"). I can easily be talked out of this if there is a good reason not to. I believe a tel URL would be more appropriate than the sms URL. This is more a topic for the SMS document."
[12:40:06] <Alexey> Thanks
[13:04:56] <stpeter> ok, about the ":from" tag, Alexey and I suggest the following text: 2.3. Notify tag ":from" If included, the ":from" tag MUST be the envelope recipient address of the original email message that triggered the notification. The value of the ":from" tag MAY be included in the human-readable XML character data of the XMPP notification; alternatively or in addition, it MAY be transformed into formal XMPP syntax, in which case it MUST be encapsulated as the value of an XMPP Stanza Headers and Internet Metadata [SHIM] header named "Resent-From".
[13:05:46] <Alexey> (The Resent-From SHIM header has email syntax)
[13:06:15] <stpeter> right, that just borrows from RFC 2822
[13:10:39] <cnewman@jabber.org> That would be sufficient to clear my discuss as it makes the syntax clear enough and should interoperate. From a technical perspective, it may be overly restrictive -- particularly given that users may use subaddresses or have multiple legitimate from addresses and the semantics of "Resent-From" are a trace field so it's mostly-harmless to put anything with email syntax in there.
[13:13:43] <Alexey> Chris, why is subaddressing a problem?
[13:15:05] <cnewman@jabber.org> Well, if the envelope recipient address happens to use a subaddress, but the user wants the notification to use their primary address in the resent-from header of the notification, for example.
[13:15:58] <Alexey> If the user omits :from, the subaddressed version is going to be used
[13:16:24] <Alexey> I thought there was a syntactic problem, but there doesn't seem to be any
[13:16:40] <cnewman@jabber.org> Yes, but if the user includes ":from", then "the ":from" tag MUST be the envelope recipient address    of the original email message that triggered the notification"
[13:17:34] <cnewman@jabber.org> I don't see why that MUST is necessary. Why not just say: the ":from" tag MUST have email address syntax.
[13:18:21] <Alexey> Oh, I see
[13:18:28] <Alexey> Yes, I agree with this
[13:18:31] <Alexey> Peter?
[13:18:34] <stpeter> yes that seems sensible
[13:21:16] <stpeter> do we want to say that it SHOULD be the envelope recipient address, or leave that out?
[13:22:44] <stpeter> that is, If included, the ":from" tag MUST be an email address, which SHOULD be the envelope recipient address of the original email message that triggered the notification.
[13:22:54] <stpeter> (?)
[13:25:05] <cnewman@jabber.org> With "Resent-From" semantics, I'm not sure the restriction provides any value. I can certainly live with it if that's what you want to say.
[13:26:11] <cnewman@jabber.org> But I note that "SHOULD" is applying to script writers rather than to sieve engine code...
[13:26:21] <stpeter> correct
[13:27:53] <cnewman@jabber.org> Well, let's try to get this done. If you have final text Lisa can put in as an RFC editor note, I can clear my discuss and it's approved.
[13:28:16] <Alexey> Peter: I think this is backward: if :from is not specified, then it SHOULD be defaulted from the envelope recipient address of the original email message that triggered the notification
[13:29:00] <stpeter> Alexey: ah, that makes more sense
[13:30:17] <stpeter> so 2.3. Notify tag ":from" If included, the ":from" tag MUST be an email address. The value of the ":from" tag MAY be included in the human-readable XML character data of the XMPP notification; alternatively or in addition, it MAY be transformed into formal XMPP syntax, in which case it MUST be encapsulated as the value of an XMPP Stanza Headers and Internet Metadata [SHIM] header named "Resent-From".
[13:33:08] <stpeter> then under Section 2.7 ("XMPP Syntax") we would have something like this: o The XMPP <message/> stanza MAY include an XMPP Stanza Headers and Internet Metadata [SHIM] header named "Resent-From". If the Sieve script included a ":from" tag, the "Resent-From" value MUST be the value of the ":from" tag; otherwise the "Resent-From" value SHOULD be the envelope recipient address of the original email message that triggered the notification.
[13:33:29] <Alexey> This looks good to me
[13:34:15] <stpeter> I am fixing the examples accordingly
[13:35:08] <cnewman@jabber.org> Looks very good to me.
[13:37:26] <stpeter> OK super
[13:41:47] * stpeter sends the agreed-upon text via email just in case this room is not archived properly :)
[13:43:38] <stpeter> ah, not to worry it seems: http://www.ietf.org/meetings/ietf-logs/sieve/2007-12-20.html
[13:48:00] <Alexey> Ok, Cullen has a new DISCUSS text:
[13:48:03] <Alexey> Discuss [2007-12-20]: 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.
[13:48:26] <Alexey> (Sieve XMPP notify)
[13:51:34] <stpeter> in XMPP we call this a "presence leak"
[13:52:19] <stpeter> i.e., Bob is not allowed to see Alice's presence information but figures it out somehow through a vulnerability
[13:52:20] <Alexey> Section 2.2 already says that in this case "online" should return "maybe"
[13:52:21] * stpeter ponders
[13:54:05] <stpeter> ok, I need to map this out on my whiteboard, brb :)
[13:57:51] <stpeter> hmm
[13:58:17] <stpeter> can Bob write a sieve script that behaves differently if Alice is online vs. offline?
[13:59:08] <stpeter> I mean we say "In response to a notify_method_capability test for the "online" notification-capability, an implementation SHOULD return a value of "yes" if it has knowledge of an active presence session "
[13:59:23] <stpeter> but who can generate a notify_method_capability test?
[14:00:01] <stpeter> I understand that Alice's scripts may behave differently if she is offline vs. online, but I don't see how Bob's scripts can
[14:00:22] * stpeter goes back to his whiteboard
[14:00:26] <Alexey> Yes, of course Bob can write such script.
[14:00:53] <Alexey> Bob can test Alice's presence, but not actually send any notification to her (and do something else)
[14:01:15] <stpeter> oh that's bad, we need to plug that potential presence leak
[14:01:36] <stpeter> hold on for modified text
[14:04:52] <stpeter> so this is better: 9. In response to a notify_method_capability test for the "online" notification-capability, an implementation SHOULD return a value of "yes" if it has knowledge of an active presence session (see [XMPP-IM]) for the specified XMPP notification-uri but only if the entity that requested the test has permission to know the presence of the notification-uri (e.g., via explicit presence subscription as specified in [XMPP-IM]); otherwise it SHOULD return a value of "maybe" (since typical XMPP systems may not allow a SIEVE engine to gain knowledge about the presence of XMPP entities).
[14:06:11] <Alexey> Looks good to me
[14:07:20] <stpeter> then we may want to talk about the presence leak possibility in the security considerations, as we do for example at http://tools.ietf.org/html/draft-saintandre-rfc3920bis-04#section-15.13
[14:29:11] --- Lisa has left
[14:30:43] <stpeter> so I would propose also the following security consideration... 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]).
[14:31:54] <stpeter> brb