7Network Working Group A. Melnikov, Ed.
8Request for Comments: 5435 Isode Limited
9Category: Standards Track B. Leiba, Ed.
11 IBM T.J. Watson Research Center
17 Sieve Email Filtering: Extension for Notifications
21 This document specifies an Internet standards track protocol for the
22 Internet community, and requests discussion and suggestions for
23 improvements. Please refer to the current edition of the "Internet
24 Official Protocol Standards" (STD 1) for the standardization state
25 and status of this protocol. Distribution of this memo is unlimited.
29 Copyright (c) 2009 IETF Trust and the persons identified as the
30 document authors. All rights reserved.
32 This document is subject to BCP 78 and the IETF Trust's Legal
33 Provisions Relating to IETF Documents (http://trustee.ietf.org/
34 license-info) in effect on the date of publication of this document.
35 Please review these documents carefully, as they describe your rights
36 and restrictions with respect to this document.
40 Users go to great lengths to be notified as quickly as possible that
41 they have received new mail. Most of these methods involve polling
42 to check for new messages periodically. A push method handled by the
43 final delivery agent gives users quicker notifications and saves
44 server resources. This document does not specify the notification
45 method, but it is expected that using existing instant messaging
46 infrastructure such as Extensible Messaging and Presence Protocol
47 (XMPP), or Global System for Mobile Communications (GSM) Short
48 Message Service (SMS) messages will be popular. This document
49 describes an extension to the Sieve mail filtering language that
50 allows users to give specific rules for how and when notifications
58Melnikov, et al. Standards Track [Page 1]
60RFC 5435 Sieve Extension: Notifications January 2009
65 1. Introduction ....................................................3
66 1.1. Conventions Used in This Document ..........................3
67 2. Capability Identifier ...........................................3
68 3. Notify Action ...................................................3
69 3.1. Notify Action Syntax and Semantics .........................3
70 3.2. Notify Parameter "method" ..................................3
71 3.3. Notify Tag ":from" .........................................4
72 3.4. Notify Tag ":importance" ...................................4
73 3.5. Notify Tag ":options" ......................................5
74 3.6. Notify Tag ":message" ......................................5
75 3.7. Examples ...................................................6
76 3.8. Requirements on Notification Methods Specifications ........7
77 4. Test valid_notify_method ........................................8
78 5. Test notify_method_capability ...................................9
79 6. Modifier encodeurl to the 'set' Action .........................10
80 7. Interactions with Other Sieve Actions ..........................11
81 8. Security Considerations ........................................11
82 9. IANA Considerations ............................................13
83 9.1. Registration of Sieve Extension ...........................13
84 9.2. New Registry for Sieve Notification Mechanisms ............14
85 9.3. New Registry for Notification-Capability Parameters .......14
86 10. Acknowledgements ..............................................15
87 11. References ....................................................16
88 11.1. Normative References .....................................16
89 11.2. Informative References ...................................16
114Melnikov, et al. Standards Track [Page 2]
116RFC 5435 Sieve Extension: Notifications January 2009
121 This is an extension to the Sieve language defined by [Sieve] for
122 providing instant notifications. It defines the new action "notify".
124 This document does not specify the notification methods. Examples of
125 possible notification methods are email and XMPP. To allow for the
126 portability of scripts that use notifications, implementation of the
127 [MailTo] method is mandatory. Other available methods shall depend
128 upon the implementation and configuration of the system.
1301.1. Conventions Used in This Document
132 Conventions for notations are as in [Sieve], Section 1.1, including
135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
137 document are to be interpreted as described in [Kwds].
1392. Capability Identifier
141 The capability string associated with the extension defined in this
142 document is "enotify".
1463.1. Notify Action Syntax and Semantics
148 Usage: notify [":from" string]
149 [":importance" <"1" / "2" / "3">]
150 [":options" string-list]
154 The "notify" action specifies that a notification should be sent to a
155 user. The format of the notification is implementation-defined and
156 is also affected by the notification method used (see Section 3.2).
157 However, all content specified in the ":message" parameter SHOULD be
1603.2. Notify Parameter "method"
162 The "method" positional parameter identifies the notification method
163 that will be used; it is a URI [URI]. For example, the notification
164 method can be a tel URI [TEL-URI] with a phone number to send SMS
165 messages to, or an XMPP [XMPP] URI containing an XMPP identifier
170Melnikov, et al. Standards Track [Page 3]
172RFC 5435 Sieve Extension: Notifications January 2009
175 The supported URI values will be site-specific, but support for the
176 [MailTo] method is REQUIRED in order to ensure interoperability. If
177 a URI schema is specified that the implementation does not support,
178 the notification MUST cause an error condition at run time. Sieve
179 scripts can check the supported methods using the valid_notify_method
180 test to be sure that they only use supported ones, to avoid such
183 If the "method" parameter contains a supported URI schema, then the
184 URI MUST be checked for syntactic validity. Invalid URI syntax or an
185 unsupported URI extension MUST cause an error. An implementation MAY
186 enforce other semantic restrictions on URIs -- for example, to
187 restrict phone numbers in a tel: URI to a particular geographical
188 region -- and will treat violations of such semantic restrictions as
1913.3. Notify Tag ":from"
193 A ":from" tag may be used to specify an author of the notification.
194 The syntax of this parameter's value is method-specific.
195 Implementations SHOULD check the syntax according to the notification
196 method specification and generate an error when a syntactically
197 invalid ":from" tag is specified.
199 In order to minimize/prevent forgery of the author value,
200 implementations SHOULD impose restrictions on what values can be
201 specified in a ":from" tag. For example, an implementation may
202 restrict this value to be a member of a list of known author
203 addresses or to belong to a particular domain. It is suggested that
204 values that don't satisfy such restrictions simply be ignored rather
205 than causing the "notify" action to fail.
2073.4. Notify Tag ":importance"
209 The ":importance" tag specifies the importance of quick delivery of
210 the notification, as perceived by the Sieve script owner. The
211 ":importance" tag is followed by a numeric value represented as a
212 string: "1" (high importance), "2" (normal importance), and "3" (low
213 importance). If no importance is given, the default value "2" SHOULD
214 be assumed. A notification method MAY treat the importance value as
215 a transport indicator. For example, it might deliver notifications
216 of high importance quicker than notifications of normal or low
217 importance. Some notification methods allow users to specify their
218 state of activity (for example, "busy" or "away from keyboard"). If
219 the notification method provides this information, it SHOULD be used
220 to selectively send notifications. If, for example, the user marks
226Melnikov, et al. Standards Track [Page 4]
228RFC 5435 Sieve Extension: Notifications January 2009
231 herself as "busy", a notification method can require that a
232 notification with importance of "3" is not to be sent; however, the
233 user might be notified of a notification with higher importance.
235 If the notification method allows users to filter messages based upon
236 certain parameters in the message, users SHOULD be able to filter
237 based upon importance. If the notification method does not support
238 importance, then this parameter MUST be ignored. An implementation
239 MAY include the importance value in the default message, Section 3.6,
240 if one is not provided.
2423.5. Notify Tag ":options"
244 The ":options" tag is used to send additional parameters to the
245 notification method. Interpretation of the parameters is method-
246 specific. This document doesn't specify any such additional
249 Each string in the options string list has the following syntax:
250 "<optionname>=<value>"
251 where optionname has the following ABNF [ABNF]:
255 l-d-p = l-d / "." / "-" / "_"
256 optionname = l-d *l-d-p
257 value = *(%x01-09 / %x0B-0C / %x0E-FF)
2593.6. Notify Tag ":message"
261 The ":message" tag specifies the message data to be included in the
262 notification. The entirety of the string SHOULD be sent, but
263 implementations MAY shorten the message for technical or aesthetic
264 reasons. If the ":message" parameter is absent, a default
265 implementation-specific message is used. Unless otherwise specified
266 by a particular notification mechanism, an implementation default
267 containing at least the value of the "From" header field and the
268 value of the "Subject" header field is RECOMMENDED.
270 In order to construct more complex messages, the notify extension can
271 be used together with the Sieve variables extension [Variables], as
272 shown in the examples below.
282Melnikov, et al. Standards Track [Page 5]
284RFC 5435 Sieve Extension: Notifications January 2009
290 require ["enotify", "fileinto", "variables"];
292 if header :contains "from" "boss@example.org" {
293 notify :importance "1"
294 :message "This is probably very important"
295 "mailto:alm@example.com";
296 # Don't send any further notifications
300 if header :contains "to" "sievemailinglist@example.org" {
301 # :matches is used to get the value of the Subject header
302 if header :matches "Subject" "*" {
303 set "subject" "${1}";
306 # :matches is used to get the value of the From header
307 if header :matches "From" "*" {
311 notify :importance "3"
312 :message "[SIEVE] ${from}: ${subject}"
313 "mailto:alm@example.com";
314 fileinto "INBOX.sieve";
318 require ["enotify", "fileinto", "variables", "envelope"];
320 if header :matches "from" "*@*.example.org" {
321 # :matches is used to get the MAIL FROM address
322 if envelope :all :matches "from" "*" {
323 set "env_from" " [really: ${1}]";
326 # :matches is used to get the value of the Subject header
327 if header :matches "Subject" "*" {
328 set "subject" "${1}";
331 # :matches is used to get the address from the From header
332 if address :matches :all "from" "*" {
333 set "from_addr" "${1}";
338Melnikov, et al. Standards Track [Page 6]
340RFC 5435 Sieve Extension: Notifications January 2009
343 notify :message "${from_addr}${env_from}: ${subject}"
344 "mailto:alm@example.com";
348 require ["enotify", "variables"];
351 "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail";
353 if header :contains "subject" "Your dog" {
354 set "notif_method" "tel:+14085551212";
357 if header :contains "to" "sievemailinglist@example.org" {
358 set "notif_method" "";
361 if not string :is "${notif_method}" "" {
362 notify "${notif_method}";
365 if header :contains "from" "boss@example.org" {
366 # :matches is used to get the value of the Subject header
367 if header :matches "Subject" "*" {
368 set "subject" "${1}";
371 # don't need high importance notification for
372 # a 'for your information'
373 if not header :contains "subject" "FYI:" {
374 notify :importance "1" :message "BOSS: ${subject}"
3793.8. Requirements on Notification Methods Specifications
381 This section describes requirements for documents that define
382 specific Sieve notification methods.
384 Notification mechanisms MUST NOT add new Sieve tags to the "notify"
387 A notification method MAY allow modification of the final
388 notification text -- for example, truncating it if it exceeds a
389 length limit or modifying characters that can not be represented in
390 the target character set. Characters in the notification text that
394Melnikov, et al. Standards Track [Page 7]
396RFC 5435 Sieve Extension: Notifications January 2009
399 can't be represented by the notification method SHOULD be replaced
400 with a symbol indicating an unknown character. Allowed modifications
401 MUST be documented in the document describing the notification
404 A notification method MAY ignore parameters specified in the "notify"
407 A notification method MAY recommend the default message value to be
408 used if the ":message" argument is not specified.
410 Notifications SHOULD include timestamps, if the notification method
411 allows for their transmission outside of the textual message.
412 Implementation methods that can only transmit timestamps in the
413 textual message MAY include them in the textual message.
415 A notification MUST include means to identify/track its origin in
416 order to allow a recipient to stop notifications or find out how to
417 contact the sender. This requirement is to help with tracking a
418 misconfigured or abusive origin of notifications.
420 Methods SHOULD NOT include any other extraneous information not
421 specified in parameters to the "notify" action.
423 Methods MUST specify which URI parameters (if any) must be ignored,
424 which ones must be used in the resulting notification, and which ones
427 Methods MUST specify what values are returned by the
428 notify_method_capability test, Section 5, in particular for the
429 "online" notification-capability.
431 If there are errors sending the notification, the Sieve interpreter
432 SHOULD ignore the notification and not retry indefinitely. The Sieve
433 interpreter MAY throttle notifications; if it does, a request to send
434 a notification MAY be silently ignored. Documents describing
435 notification methods SHOULD describe how retries, throttling,
436 duplicate suppression (if any), etc. are to be handled by
4394. Test valid_notify_method
441 Usage: valid_notify_method <notification-uris: string-list>
443 The valid_notify_method test is true if the notification methods
444 listed in the notification-uris argument are supported and they are
445 valid both syntactically (including URI parameters) and semantically
450Melnikov, et al. Standards Track [Page 8]
452RFC 5435 Sieve Extension: Notifications January 2009
455 (including implementation-specific semantic restrictions). This test
456 MUST perform exactly the same validation as would be performed on the
457 "method" parameter to the "notify" action.
459 The test is true only if ALL of the listed notification methods are
463 if not valid_notify_method ["mailto:",
464 "http://gw.example.net/notify?test"] {
4685. Test notify_method_capability
470 Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE]
471 <notification-uri: string>
472 <notification-capability: string>
473 <key-list: string-list>
475 The notify_method_capability test retrieves the notification
476 capability specified by the notification-capability string that is
477 specific to the notification-uri and matches it to the values
478 specified in the key-list. The test succeeds if a match occurs. The
479 type of match defaults to ":is", and the default comparator is
482 The notification-capability parameter is case insensitive.
484 The notify_method_capability test MUST fail unconditionally if the
485 specified notification-uri is syntactically invalid (as determined by
486 the valid_notify_method test, Section 4) or specifies an unsupported
487 notification method. However this MUST NOT cause an error.
489 The notify_method_capability test MUST fail unconditionally if the
490 specified notification-capability item is not known to the Sieve
491 interpreter. A script MUST NOT fail with an error if the item does
492 not exist. This allows scripts to be written that handle nonexistent
495 This document defines a single notification-capability value
496 "online", which is described below. Additional notification-
497 capability values may be defined by using the procedure defined in
500 The "relational" extension [Relational] adds a match type called
501 ":count". The count of an notify_method_capability test is 0, if the
502 returned information is the empty string, or 1.
506Melnikov, et al. Standards Track [Page 9]
508RFC 5435 Sieve Extension: Notifications January 2009
511 For the "online" notification-capability, the
512 notify_method_capability test can match one of the following key-list
515 o "yes" - the entity identified by the notification-uri can receive
516 a notify notification immediately. Note that even after this
517 value is returned, there is no guarantee that the entity would
518 actually be able to receive any notification immediately or even
519 receive it at all. Transport errors, recipient policy, etc. can
522 o "no" - the entity identified by the notification-uri is not
523 currently available to receive an immediate notification.
525 o "maybe" - the Sieve interpreter can't determine if the entity
526 identified by the notification-uri is online or not.
531 if notify_method_capability
532 "xmpp:tim@example.com?message;subject=SIEVE"
535 notify :importance "1" :message "You got mail"
536 "xmpp:tim@example.com?message;subject=SIEVE";
538 notify :message "You got mail" "tel:+14085551212";
5416. Modifier encodeurl to the 'set' Action
545 When the Sieve script specifies both "variables" [Variables] and
546 "enotify" capabilities in the "require", a new "set" action modifier
547 (see [Variables]) ":encodeurl" becomes available to Sieve scripts.
548 This modifier performs percent-encoding of any octet in the string
549 that doesn't belong to the "unreserved" set (see [URI]). The
550 percent-encoding procedure is described in [URI].
552 The ":encodeurl" modifier has precedence 15.
562Melnikov, et al. Standards Track [Page 10]
564RFC 5435 Sieve Extension: Notifications January 2009
568 require ["enotify", "variables"];
570 set :encodeurl "body_param" "Safe body&evil=evilbody";
572 notify "mailto:tim@example.com?body=${body_param}";
5747. Interactions with Other Sieve Actions
576 The "notify" action is compatible with all other actions, and does
577 not affect the operation of other actions. In particular, the
578 "notify" action MUST NOT cancel the implicit keep.
580 Multiple executed "notify" actions are allowed. Specific
581 notification methods MAY allow multiple notifications from the same
582 script to be collapsed into one.
5848. Security Considerations
586 Security considerations are discussed in [Sieve]. Additionally,
587 implementations must be careful to follow the security considerations
588 of the specific notification methods.
590 The "notify" action is potentially very dangerous. The path the
591 notification takes through the network may not be secure. An error
592 in the options string may cause the message to be transmitted to
593 someone it was not intended for, or may expose information to
596 Just because a notification is received doesn't mean that it was sent
597 by the Sieve implementation. It might be possible to forge
598 notifications or modify parts of valid notifications with some
599 notification methods.
601 Forgery of the ":importance" value (for example, by unauthorized
602 script modification) can potentially result in slowdown in
603 notification delivery.
605 Note that some components of notifications should not be trusted.
606 For example, the timestamp field can be easily forged or modified
607 when some notification transports are used. Even if the timestamp is
608 believed to be correct by the sender and is not modified in transit,
609 it might be misleading on the receiving system due to clock
618Melnikov, et al. Standards Track [Page 11]
620RFC 5435 Sieve Extension: Notifications January 2009
623 An organization may have a policy about the forwarding of classified
624 information to unclassified networks. Unless the policy is also
625 enforced in the module responsible for the generating (or sending) of
626 notifications, users can use the extension defined in this document
627 to extract classified information and bypass the policy.
629 Notifications can result in loops and bounces. Also, allowing a
630 single script to notify multiple destinations can be used as a means
631 of amplifying the number of messages in an attack. Moreover, if loop
632 detection is not properly implemented, it may be possible to set up
633 exponentially growing notification loops. Accordingly, Sieve
634 notification methods:
636 1. MUST provide mechanisms for avoiding notification loops.
638 2. MUST provide the means for administrators to limit the ability of
639 users to abuse notify. In particular, it MUST be possible to
640 limit the number of "notify" actions a script can perform.
641 Additionally, if no use cases exist for using "notify" with
642 multiple destinations, this limit SHOULD be set to 1. Additional
643 limits, such as the ability to restrict "notify" to local users,
644 MAY also be implemented.
646 3. MUST provide facilities to log the use of "notify" in order to
647 facilitate tracking down abuse.
649 4. MAY use script analysis to determine whether or not a given
650 script can be executed safely. While the Sieve language is
651 sufficiently complex so that full analysis of all possible
652 scripts is computationally infeasible, the majority of real-world
653 scripts are amenable to analysis. For example, an implementation
654 might allow scripts that it has determined to be safe to run
655 unhindered, block scripts that are potentially problematic, and
656 subject unclassifiable scripts to additional auditing and
659 Allowing "notify" action at all may not be appropriate in situations
660 where Sieve scripts are associated with email accounts that are
661 freely-available and/or not trackable to a human who can be held
662 accountable for creating message bombs or other abuse.
664 Implementations that construct URIs internally from various notify
665 parameters MUST make sure that all components of such URIs are
666 properly percent-encoded (see [URI]). In particular, this applies to
667 values of the ":from" and ":message" tagged arguments and may apply
668 to the ":options" values.
674Melnikov, et al. Standards Track [Page 12]
676RFC 5435 Sieve Extension: Notifications January 2009
679 Header/envelope tests [Sieve], together with Sieve variables, can be
680 used to extract the list of users to receive notifications from the
681 incoming email message or its envelope. This is potentially quite
682 dangerous, as this can be used for denial-of-service attacks on
683 recipients controlled by the message sender. For this reason,
684 implementations SHOULD NOT allow the use of variables containing
685 values extracted from the email message in the "method" parameter to
686 the "notify" action. Note that violation of this SHOULD NOT may
687 result in the creation of an open relay, i.e., any sender would be
688 able to create specially crafted email messages that would result in
689 notifications delivered to recipients under the control of the
690 sender. In the worst case, this might result in financial loss by
691 the user controlling the Sieve script and/or by recipients of
692 notifications (e.g., if a notification is an SMS message).
694 Note that the last SHOULD NOT is not a generic prohibition of use of
695 variables in the "notify" action, as controlling the target of a
696 notification by extracting it from user-owned data stores (such as
697 user's Lightweight Directory Access Protocol (LDAP) entry) is
698 considered to be useful.
700 It is imperative that whatever implementations use to store the user-
701 defined filtering scripts protect them from unauthorized
702 modification, to preserve the integrity of the mail system. An
703 attacker who can modify a script can cause mail to be discarded,
704 rejected, or forwarded to an unauthorized recipient. In addition,
705 it's possible that Sieve scripts might expose private information,
706 such as mailbox names or email addresses of favored (or disfavored)
707 correspondents. Because of that, scripts SHOULD also be protected
708 from unauthorized retrieval.
7109. IANA Considerations
7129.1. Registration of Sieve Extension
715 Subject: Registration of new Sieve extension
716 Capability name: enotify
717 Description: adds the "notify" action for notifying user about the
718 received message. It also provides two new tests:
719 valid_notify_method checks notification URIs for validity;
720 notify_method_capability can check recipients capabilities.
722 Contact address: The Sieve discussion list
723 <ietf-mta-filters@imc.org>
725 This information has been added to the list of Sieve extensions
726 available from http://www.iana.org/.
730Melnikov, et al. Standards Track [Page 13]
732RFC 5435 Sieve Extension: Notifications January 2009
7359.2. New Registry for Sieve Notification Mechanisms
737 IANA has created a new registry for Sieve notification mechanisms.
738 This registry contains both vendor-controlled notification mechanism
739 names (beginning with "vnd.") and IETF-controlled notification
740 mechanism names. Vendor-controlled notification mechanism names have
741 the format as defined in the following paragraph and may be
742 registered on a "First Come First Served" basis [IANA-GUIDELINES], by
743 applying to IANA with the form specified later in this section.
744 Registration of notification mechanisms that do not begin with "vnd."
745 are registered using a "Specification Required" policy
748 Vendor-controlled notification mechanism names MUST have the form
749 "vnd.<vendor-name>.<mechanism-name>", where <vendor-name> is as
750 specified in the Application Configuration Access Protocol (ACAP)
751 Vendor Subtree registry [ACAP].
753 This defines the template for a new registry for Sieve notification
754 mechanisms, which has been created and is available from
755 http://www.iana.org/. There are no initial entries for this
759 Subject: Registration of new Sieve notification mechanism
760 Mechanism name: [the name of the mechanism]
761 Mechanism URI: [the RFC number of the document that defines the URI
762 used by this mechanism. Different mechanisms MUST use different
764 Mechanism-specific options: [the names of any Sieve notify options
765 (as used in the ":options" parameter) that are specific to this
766 mechanism, or "none"]
767 Permanent and readily available reference: [the RFC number or an URL
768 of the document that defines this notification mechanism]
769 Person and email address to contact for further information: [the
770 name and email address of the technical contact for information
771 about this mechanism]
7739.3. New Registry for Notification-Capability Parameters
775 IANA has created a new registry for the notification-capability
776 parameters of the notify_method_capability test. This registry
777 contains both vendor-controlled notification-capability values
778 (beginning with "vnd.") and IETF-controlled notification-capability
779 values. Vendor-controlled notification-capability values have the
780 format as defined in the following paragraph and may be registered on
781 a "First Come First Served" basis [IANA-GUIDELINES], by applying to
782 IANA with the form specified later in this section. Registration of
786Melnikov, et al. Standards Track [Page 14]
788RFC 5435 Sieve Extension: Notifications January 2009
791 notification-capability values that do not begin with "vnd." are
792 registered using the "Specification Required" policy
795 Vendor-controlled notification-capability values MUST have the form
796 "vnd.<vendor-name>.<capability-name>", where <vendor-name> is as
797 specified in the ACAP Vendor Subtree registry [ACAP].
799 The following template must be used for registering notification-
800 capability parameters:
803 Subject: Registration of a new notification-capability parameter
804 Capability name: [the name of the notification-capability]
805 Description: [an explanation of the purpose of the notification-
807 Syntax: [formal definition of allowed values and their syntax]
808 Permanent and readily available reference(s): [the RFC number(s) or
809 an URL of the document that defines this notification mechanism]
810 Contact information: [the name and email address of the technical
811 contact for information about this mechanism]
813 Below is the registration form for the "online" notification-
817 Subject: Registration of a new notification-capability parameter
818 Capability name: online
819 Description: Returns whether the entity identified by the
820 notification-uri parameter to the notify_method_capability test
821 can receive a notify notification immediately.
822 Syntax: Can contain one of three values: "yes", "no", and, "maybe".
823 Values MUST be in lowercase.
824 Permanent and readily available reference(s): This RFC
825 Contact information: The Sieve discussion list
826 <ietf-mta-filters@imc.org>
830 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus
831 Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E.
832 Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt
833 Gulbrandsen, Peter Saint-Andre, Sean Turner, Cullen Jennings, and
834 Pasi Eronen for help with this document.
842Melnikov, et al. Standards Track [Page 15]
844RFC 5435 Sieve Extension: Notifications January 2009
84911.1. Normative References
851 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
852 for Syntax Specifications: ABNF", STD 68,
853 RFC 5234, January 2008.
855 [Kwds] Bradner, S., "Key words for use in RFCs to
856 Indicate Requirement Levels", BCP 14, RFC 2119,
859 [MailTo] Leiba, B. and M. Haardt, "Sieve Notification
860 Mechanism: mailto", RFC 5436, January 2009.
862 [Relational] Segmuller, W. and B. Leiba, "Sieve Extension:
863 Relational Tests", RFC 5231, January 2008.
865 [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve:
866 An Email Filtering Language", RFC 5228,
869 [URI] Berners-Lee, T., Fielding, R., and L. Masinter,
870 "Uniform Resource Identifier (URI): Generic
871 Syntax", STD 66, RFC 3986, January 2005.
873 [Variables] Homme, K., "Sieve Extension: Variables", RFC 5229,
87611.2. Informative References
878 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
879 Configuration Access Protocol", RFC 2244,
882 [IANA-GUIDELINES] Narten, T. and H. Alvestrand, "Guidelines for
883 Writing an IANA Considerations Section in RFCs",
884 BCP 26, RFC 5226, May 2008.
886 [TEL-URI] Schulzrinne, H., "The tel URI for Telephone
887 Numbers", RFC 3966, December 2004.
889 [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and
890 Presence Protocol (XMPP): Core", RFC 3920,
898Melnikov, et al. Standards Track [Page 16]
900RFC 5435 Sieve Extension: Notifications January 2009
903 [XMPP-URI] Saint-Andre, P., "Internationalized Resource
904 Identifiers (IRIs) and Uniform Resource
905 Identifiers (URIs) for the Extensible Messaging
906 and Presence Protocol (XMPP)", RFC 5122,
911 Alexey Melnikov (editor)
913 5 Castle Business Village
915 Hampton, Middlesex TW12 2BX
918 EMail: Alexey.Melnikov@isode.com
922 IBM T.J. Watson Research Center
927 Phone: +1 914 784 7941
928 EMail: leiba@watson.ibm.com
932 IBM T.J. Watson Research Center
937 Phone: +1 914 784 7408
938 EMail: werewolf@us.ibm.com
944 San Francisco, CA 94117
947 Phone: +1 510 260-4175
948 EMail: timmartin@alumni.cmu.edu
954Melnikov, et al. Standards Track [Page 17]