Subject: FW: [Notifications] Setting up email event streams

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 16 Jan 2007 17:41:07 +0200

I apologize for the cross-posting, but the theme has some similarities
with discussions that happened in the OPS area and specifically in
NETCONF. 
 
Subscribing to the notifications list is probably the right way to
follow this discussion or even contribute to it. 
 
Dan

  _____  

From: Lisa Dusseault [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2007 1:16 AM
To: Message Notifications interest group discussion list
Subject: [Notifications] Setting up email event streams

I've been meaning to send this out more broadly after a bit of private
comment: two quite different models for setting up event streams based
on what's easier to authenticate -- the event stream "owner" (in this
case the mailbox owner) or the stream recipient.  I hope it helps
compare different approaches.

Lisa

---

The goal is to start (and stop) events flowing from an event source (in
our case, an email server) to the event sink, frequently using a system
with an explicit event relay.   Because there are often three parties
required in an event flow , we have to pick some way for the three
parties to coordinate.

The three parties are the event source (an email server), the event sink
(a client, perhaps not an email client)  and an event relay.  The event
relay has many users thus it has addresses for each user and possibly
also addresses for devices/clients.  Two kinds of application-layer
explicit event relays are starting to be common: XMPP and SIP.  For the
purposes of considering an event feed setup model, we do not want to be
concerned about the mostly orthogonal issue of what protocol to use to
talk to event relay.  So for now we assume that event relays have all
features common to XMPP and SIP (addresses, pub/sub features, event
stream aggregation).

Choosing between two event stream setup models requires assumptions
about
- what kind of authorization is easier or more important to provide
- whether there are a lot of different event sink addressess
- whether direct access to the event source is always/usually available
(can be affected by whether the event source is publicly available)
- whether event flows stop and start frequently, or can simply be turned
on for a very long term

MODEL A.  SUBSCRIBE Chain

A-1 Description

In this model, when a user decides to get an email event flow to a
particular device or piece of software, the user typically works with
the event sink interface to indicate where to get the events from.  Then
a SUBSCRIBE message of some kind gets generated by the event sink, sent
to the event relay and is handled by the event source.

A-2 Authorization issue

The authorization problem here is to determine if the address that the
SUBSCRIBE message comes from is permitted to receive these events.  In
the case of a publicly-subscribable resource this problem disappears.
In many email use cases, only a small number of event sink addresses
will be authorized to receive event notifications -- perhaps the event
source (the email server) can simply be configured with a short allowed
list of event recipients that doesn't change often (e.g. my personal IM
address, my work address, and the one used by my phone provided by my
phone service provider).

Some SUBSCRIBE systems have the ability to provide a PENDING response to
a subscription.  This is used when an out-of-band mechanism is initiated
to authorize the subscribing address.  In an email event source use
case, one obvious out-of-band mechanism is for the email server to
create an email with a link saying "Click here to authorize this
subscription".

It's also possible to use a mechanism like URLAUTH to prove
authorization -- in this approach, the subscriber provides a URL that
has a secret token in it authorizing the subscription.  It's possible
that this would authorize the subscribing address for future
subscriptions as well, or only for a limited period.

A-3 Drawbacks:
   a)  Only some notification protocols support SUBSCRIBE semantics.

   b)  Complicated filters and event types (to support use cases like
"Alert me on event type 'email arrives' if it is from my boss, has my
full email address or the address of the developer list on the to line,
and the subject does not begin with 'FUNNY'..." )  might need a little
extra work.  Both SIP and XMPP subscriptions can be extended in such a
way that existing notification relays would pass on a filter
specification in whatever language/format most appropriate for email.
It might even be possible to send SIEVE conditionals in the body of the
SUBSCRIBE message.  XMPP has notification nodes in XEP-0060 and
notification filters in XEP-0163.

A-4 Advantages
   b) Allows for frequent starting and stopping of subscriptions,
possibly an efficiency/scaling concern

MODEL B. Sender RULES

B-1 Description

In this model, the user typically works with the event source in order
to configure it to send events to a given set of addresses.  For
example, the user might have access to a Web interface to an email
server where it can say "Send new message notifications to 
xmpp://[email-masked] <xmpp://[email-masked]> " or someday use MANAGESIEVE.

B-2 Authorization issue

The authorization problem here is to determine if the user creating the
sending rule is authorized to send an event stream to the receiving
address.  If anybody can send to the receiving address (e.g. email) then
it's publicly addressable and the problem disappears.  Many kinds of
addresses are publicly addressable and use whitelisting together with
asking permission ("do you wish to allow messages from this source in
the future").

B-3 Drawbacks:
   a) Only some event sources support RULE systems.  We are building
SIEVE for email clients and servers but it may be harder to generalize
this beyond email clients and servers.  Even sticking strictly the
proposed scope of email server sources, we have to consider whether a
client such as a calendar client (subscribing for IMIP messages) or a
time-management dashboard (subscribes to "unread" counts but doesn't
otherwise read email) are going to be able to implement SIEVE,
authenticate to mail servers etc.

   b) If sender rules are setup through Web interfaces, users are
definitely not going to turn them on and off frequently.

   c) Failure feedback: how does the event source let the user know that
some address keeps bouncing?

_______________________________________________
Notifications mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/notifications

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 30 Jan 2007 15:12:48 -0500

Hi,
 
A third common application-layer explicit event relay is syslog, and
the syslog-security WG just submitted a spec for a standardized
protocol and standardized transports over udp and tls to the IESG for
advancement. They are resolving WGLC issues related to syslog-sign, a
mechanism that "signs" messages to ensure they have not been modified
in transit, and workin gon an update to RFC3195 which provides
reliable in-order transport.
 
A fourth is SNMP. The ISMS WG is dealing with the
authentication/authorization issues of sending notifications, as well
as request/response messages, sometimes through a proxy forwarder
(relay).
 
The netconf WG is also dealing with subscribe/unsubscribe issues and
event stream aggregation issues.
 
dbh

  _____  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, January 16, 2007 10:41 AM
To: OPS Area; Netconf (E-mail)
Cc: Lisa Dusseault
Subject: FW: [Notifications] Setting up email event streams

 
Dan

  _____  

Lisa

---

The goal is to start (and stop) events flowing from an event source
(in our case, an email server) to the event sink, frequently using a
system with an explicit event relay.   Because there are often three
parties required in an event flow , we have to pick some way for the
three parties to coordinate.

The three parties are the event source (an email server), the event
sink (a client, perhaps not an email client)  and an event relay.  The
event relay has many users thus it has addresses for each user and
possibly also addresses for devices/clients.  Two kinds of
application-layer explicit event relays are starting to be common:
XMPP and SIP.  For the purposes of considering an event feed setup
model, we do not want to be concerned about the mostly orthogonal
issue of what protocol to use to talk to event relay.  So for now we
assume that event relays have all features common to XMPP and SIP
(addresses, pub/sub features, event stream aggregation).

Choosing between two event stream setup models requires assumptions
about
- what kind of authorization is easier or more important to provide
- whether there are a lot of different event sink addressess
- whether direct access to the event source is always/usually
available (can be affected by whether the event source is publicly
available)
- whether event flows stop and start frequently, or can simply be
turned on for a very long term

MODEL A.  SUBSCRIBE Chain

A-1 Description

In this model, when a user decides to get an email event flow to a
particular device or piece of software, the user typically works with
the event sink interface to indicate where to get the events from.
Then a SUBSCRIBE message of some kind gets generated by the event
sink, sent to the event relay and is handled by the event source.

A-2 Authorization issue

The authorization problem here is to determine if the address that the
SUBSCRIBE message comes from is permitted to receive these events.  In
the case of a publicly-subscribable resource this problem disappears.
In many email use cases, only a small number of event sink addresses
will be authorized to receive event notifications -- perhaps the event
source (the email server) can simply be configured with a short
allowed list of event recipients that doesn't change often (e.g. my
personal IM address, my work address, and the one used by my phone
provided by my phone service provider).

Some SUBSCRIBE systems have the ability to provide a PENDING response
to a subscription.  This is used when an out-of-band mechanism is
initiated to authorize the subscribing address.  In an email event
source use case, one obvious out-of-band mechanism is for the email
server to create an email with a link saying "Click here to authorize
this subscription".

A-3 Drawbacks:

   b)  Complicated filters and event types (to support use cases like
"Alert me on event type 'email arrives' if it is from my boss, has my
full email address or the address of the developer list on the to
line, and the subject does not begin with 'FUNNY'..." )  might need a
little extra work.  Both SIP and XMPP subscriptions can be extended in
such a way that existing notification relays would pass on a filter
specification in whatever language/format most appropriate for email.
It might even be possible to send SIEVE conditionals in the body of
the SUBSCRIBE message.  XMPP has notification nodes in XEP-0060 and
notification filters in XEP-0163.

A-4 Advantages

MODEL B. Sender RULES

B-1 Description

<xmpp://[email-masked]> xmpp://[email-masked]" or someday use MANAGESIEVE.

B-2 Authorization issue

The authorization problem here is to determine if the user creating
the sending rule is authorized to send an event stream to the
receiving address.  If anybody can send to the receiving address (e.g.
email) then it's publicly addressable and the problem disappears.
Many kinds of addresses are publicly addressable and use whitelisting
together with asking permission ("do you wish to allow messages from
this source in the future").

B-3 Drawbacks:

   c) Failure feedback: how does the event source let the user know
that some address keeps bouncing?