diff --git a/doc/rfc/draft-ietf-sieve-notify-12.txt b/doc/rfc/draft-ietf-sieve-notify-12.txt
deleted file mode 100644
index 8d32092daac622e3b04aaad39f13084369b8cce2..0000000000000000000000000000000000000000
--- a/doc/rfc/draft-ietf-sieve-notify-12.txt
+++ /dev/null
@@ -1,1289 +0,0 @@
-
-
-
-Sieve Working Group A. Melnikov, Ed.
-Internet-Draft Isode Limited
-Intended status: Standards Track B. Leiba, Ed.
-Expires: June 26, 2008 W. Segmuller
- IBM T.J. Watson Research Center
- T. Martin
- BeThereBeSquare Inc.
- December 24, 2007
-
-
- SIEVE Email Filtering: Extension for Notifications
- draft-ietf-sieve-notify-12
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on June 26, 2008.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-Abstract
-
- Users go to great lengths to be notified as quickly as possible that
- they have received new mail. Most of these methods involve polling
- to check for new messages periodically. A push method handled by the
- final delivery agent gives users quicker notifications and saves
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 1]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- server resources. This document does not specify the notification
- method but it is expected that using existing instant messaging
- infrastructure such as XMPP, or GSM Short Message Service (SMS)
- messages will be popular. This draft describes an extension to the
- Sieve mail filtering language that allows users to give specific
- rules for how and when notifications should be sent.
-
-Changes since draft-ietf-sieve-notify-11
-
- o [As per DISCUSS from Cullen] Changed a SHOULD to a MUST in the
- following requirement: A notification SHOULD include means to
- identify/track its origin.
-
- o [As per DISCUSS from Cullen] Changed sms: URIs to tel: URIs.
-
- o [As per COMMENT from Chris] Updated the notify mechanism IANA
- registration template to allow for specifications which are not
- RFCs.
-
- o Additional security considerations as per SecDir review from Sean
- Turner.
-
- o Added a new registry for the notification-capability parameter of
- the notify_method_capability test (as per Pasi Eronen gen-art
- review).
-
-Changes since draft-ietf-sieve-notify-10
-
- o Updated IANA registration template as per discussion in Vancouver.
-
- o Added ABNF for :options names.
-
- o Prohibit notification methods from defining new Sieve tags.
-
-Changes since draft-ietf-sieve-notify-09
-
- o Extended requirements for avoiding loops and amplification
- attacks.
-
- o Other minor editorial changes as per AD's (Lisa) review.
-
-Changes since draft-ietf-sieve-notify-08
-
- o Added missing IANA registry for notification methods.
-
-
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 2]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
-Changes since draft-ietf-sieve-notify-07
-
- o Added a new "set" modifier for URL percent-encoding.
-
- o Clarified that notification methods must address notification
- loops.
-
- o Added an implementation consideration for implementations that use
- URIs internally.
-
-Changes since draft-ietf-sieve-notify-06
-
- o Remove extract_text. The WG consensus was to move it to another
- document, such as Sieve MIME loops.
-
- o Deleted markers for open issues from the document.
-
- o Clarified that a notification mechanism can treat some URI
- parameters as an error.
-
- o Added notify_method_capability test and example.
-
- o Minor corrections to the IANA registration as a result of other
- changes.
-
-Changes since draft-ietf-sieve-notify-05
-
- o Fixed XMPP URI in one example.
-
- o Addressed Michael's issue with how timestamp are described.
-
- o Renamed "valid_notif_method" to "valid_notify_method".
-
- o Added text about truncation of a textual part when it is stored in
- a variable using extract_text.
-
- o Changed tagged :method argument to positional argument.
-
- o Added text about notification throttling, identifying notification
- source and restricting values of the :from parameter.
-
- o Added a requirement on documents describing notification methods
- to list which URI parameters must be ignored.
-
-Changes since draft-ietf-sieve-notify-04
-
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 3]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- o Made notification method required.
-
- o Defined "mailto" as a mandatory-to-implement method.
-
- o Added normative reference to mailto.
-
- o Clarified that :importance may be treated as a transport
- indicator.
-
- o Clarified that :importance value can be included in the default
- :message, if one is not specified.
-
- o Made the default :message implementation specific.
-
- o Renamed the capability name from "notify" to "enotify"
-
- o Updated IANA registration.
-
- o Moved text about ManageSieve capability to the ManageSieve
- document itself.
-
- o Removed reference to IANA registry for options.
-
- o Some miscellaneous text cleanup and clarification.
-
-Changes since draft-ietf-sieve-notify-03
-
- o Added a warning that "notify" must not be used as a crappy form of
- "redirect".
-
- o Added a warning about using "notify" to forward confidential
- information in order to bypass organization's policy.
-
- o Fixed syntax of the :options argument - it is a string list, each
- string containing "<attribute>=<value>"
-
- o Renamed :priority to :importance
-
- o Cleaned up section about requirements on methods.
-
-Changes since draft-ietf-sieve-notify-02
-
- o Added :from tagged argument.
-
- o Added Extract_text action, which allows to extract content of the
- first text/* part.
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 4]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- o Added back the ":options" parameter to the notify action.
-
- o Added new section talking about requirements on notification
- method specs.
-
- o Added more examples.
-
-Changes since draft-ietf-sieve-notify-00
-
- o Updated references, etc.
-
- o Added IANA considerations section.
-
- o Removed denotify action.
-
- o Updated examples to use the variables extension.
-
- o Replaced notification method with URI.
-
- o Removed text suggesting that this extension can be used to track
- all Sieve actions taken.
-
- o Changed priority to be a string.
-
- o Added text about URI verification.
-
- o Clarified that a notification method is allowed to perform
- adaptation of notification context (e.g. truncation, charset
- conversion, etc.). These adaptations must be documented in a
- document describing the notification method.
-
- o Clarified that notify is compatible with all existing actions.
-
- o Removed the :id parameter to the notify action.
-
- o Added valid_notif_method test that allows to test if an
- notification method (URI) is supported.
-
- o Added a new capability response to ManageSieve that allows to
- report supported notification types.
-
-
-
-
-
-
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 5]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
- 1.1. Conventions used in this document . . . . . . . . . . . . . 7
-
- 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 7
-
- 3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.1. Notify Action Syntax and Semantics . . . . . . . . . . . . . 7
- 3.2. Notify parameter "method" . . . . . . . . . . . . . . . . . 7
- 3.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 8
- 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 8
- 3.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 9
- 3.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 9
- 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 3.8. Requirements on notification methods specifications . . . . 12
-
- 4. Test valid_notify_method . . . . . . . . . . . . . . . . . . 13
-
- 5. Test notify_method_capability . . . . . . . . . . . . . . . 14
-
- 6. Modifier encodeurl to the 'set' action . . . . . . . . . . . 15
-
- 7. Interactions with Other Sieve Actions . . . . . . . . . . . 16
-
- 8. Security Considerations . . . . . . . . . . . . . . . . . . 16
-
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
- 9.1. Registration of Sieve extension . . . . . . . . . . . . . . 18
- 9.2. New registry for Sieve notification mechanisms . . . . . . . 18
- 9.3. New registry for notification-capability parameters . . . . 19
-
- 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
-
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 20
- 11.2. Informative References . . . . . . . . . . . . . . . . . . . 21
-
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
- Intellectual Property and Copyright Statements . . . . . . . 23
-
-
-
-
-
-
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 6]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
-1. Introduction
-
- This is an extension to the Sieve language defined by [Sieve] for
- providing instant notifications. It defines the new action "notify".
-
- This document does not specify the notification methods. Examples of
- possible notification methods are email and XMPP. To allow a
- mechanism for portability of scripts that use notifications,
- implementation of the [MailTo] method is mandatory. Other available
- methods shall depend upon the implementation and configuration of the
- system.
-
-1.1. Conventions used in this document
-
- Conventions for notations are as in [Sieve] section 1.1, including
- the use of [ABNF].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [Kwds].
-
-
-2. Capability Identifier
-
- The capability string associated with the extension defined in this
- document is "enotify".
-
-
-3. Notify Action
-
-3.1. Notify Action Syntax and Semantics
-
- Usage: notify [":from" string]
- [":importance" <"1" / "2" / "3">]
- [":options" string-list]
- [":message" string]
- <method: string>
-
- The Notify action specifies that a notification should be sent to a
- user. The format of the notification is implementation-defined and
- is also affected by the notification method used (see Section 3.2).
- However, all content specified in the :message parameter SHOULD be
- included.
-
-3.2. Notify parameter "method"
-
- The method positional parameter identifies the notification method
- that will be used; it is a URI [URI]. For example, the notification
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 7]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- method can be a tel URI [TEL-URI] with a phone number to send SMS
- messages to, or an XMPP [XMPP] URI containing an XMPP identifier
- [XMPP-URI].
-
- The supported URI values will be site-specific, but support for the
- [MailTo] method is REQUIRED in order to insure interoperability. If
- a URI schema is specified that the implementation does not support,
- the notification MUST cause an error condition. Sieve scripts can
- check the supported methods using the "valid_notify_method" test to
- be sure that they only use supported ones, to avoid such error
- conditions.
-
- If the method parameter contains a supported URI schema, then the URI
- MUST be checked for syntactic validity. An invalid URI syntax or an
- unsupported URI extension MUST cause an error. An implementation MAY
- enforce other semantic restrictions on URIs -- for example to
- restrict phone numbers in a tel: URI to a particular geographical
- region -- and will treat violations of such semantic restrictions as
- errors.
-
-3.3. Notify tag ":from"
-
- A ":from" parameter may be used to specify an author of the
- notification. The syntax of this parameter's value is method-
- specific. Implementations SHOULD check the syntax according to the
- notification method specification and generate an error when a
- syntactically invalid ":from" parameter is specified.
-
- In order to minimize/prevent forgery of the author value,
- implementations SHOULD impose restrictions on what values can
- specified in a ":from" parameter. For example, an implementation may
- restrict this value to be a member of a list of known author
- addresses or to belong to a particular domain. It is suggested that
- values which don't satisfy such restrictions simply be ignored rather
- than causing the notify action to fail.
-
-3.4. Notify tag ":importance"
-
- The :importance tag specifies the importance of quick delivery of the
- notification as perceived by the Sieve script owner. The :importance
- tag is followed by a numeric value represented as a string: "1" (high
- importance), "2" (normal importance), and "3" (low importance). If
- no importance is given, the default value "2" SHOULD be assumed. A
- notification method MAY treat the importance value as a transport
- indicator. For example, it might deliver notifications of high
- importance quicker than notifications of normal or low importance.
- Some notification methods allow users to specify their state of
- activity (for example "busy" or "away from keyboard"). If the
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 8]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- notification method provides this information it SHOULD be used to
- selectively send notifications. If, for example, the user marks
- herself as "busy", a notification method can require that a
- notification with importance of "3" is not to be sent, however the
- user should be notified of a notification with higher importance.
-
- If the notification method allows users to filter messages based upon
- certain parameters in the message, users SHOULD be able to filter
- based upon importance. If the notification method does not support
- importance, then this parameter MUST be ignored. An implementation
- MAY include the importance value in the default message Section 3.6,
- if one is not provided.
-
-3.5. Notify tag ":options"
-
- The :options tag is used to send additional parameters to the
- notification method. Interpretation of the parameters is method-
- specific. This document doesn't specify any such additional
- parameter.
-
- Each string in the options string list has the following syntax:
- "<optionname>=<value>".
- where optionname has the following ABNF [ABNF]:
- l-d = ALPHA / DIGIT
- l-d-p = l-d / "." / "-" / "_"
- optionname = l-d *l-d-p
- value = *(%x01-09 / %x0B-0C / %x0E-FF)
-
-3.6. Notify tag ":message"
-
- The :message tag specifies the message data to be included in the
- notification. The entirety of the string SHOULD be sent but
- implementations MAY shorten the message for technical or aesthetic
- reasons. If the message parameter is absent, a default
- implementation-specific message is used. Unless specified otherwise
- by a particular notification mechanism, an implementation default
- containing at least the value of the "From" header field and the
- value of the "Subject" header field is RECOMMENDED.
-
- In order to construct more complex messages the notify extension can
- be used together with the Sieve variables extension [Variables], as
- shown in the examples below.
-
-3.7. Examples
-
-
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 9]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- Example 1:
- require ["enotify", "fileinto", "variables"];
-
- if header :contains "from" "boss@example.org" {
- notify :importance "1"
- :message "This is probably very important"
- "mailto:alm@example.com";
- # Don't send any further notifications
- stop;
- }
-
- if header :contains "to" "sievemailinglist@example.org" {
- # :matches is used to get the value of the Subject header
- if header :matches "Subject" "*" {
- set "subject" "${1}";
- }
-
- # :matches is used to get the value of the From header
- if header :matches "From" "*" {
- set "from" "${1}";
- }
-
- notify :importance "3"
- :message "[SIEVE] ${from}: ${subject}"
- "mailto:alm@example.com";
- fileinto "INBOX.sieve";
- }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 10]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- Example 2:
- require ["enotify", "fileinto", "variables", "envelope"];
-
- if header :matches "from" "*@*.example.org" {
- # :matches is used to get the MAIL FROM address
- if envelope :all :matches "from" "*" {
- set "env_from" " [really: ${1}]";
- }
-
- # :matches is used to get the value of the Subject header
- if header :matches "Subject" "*" {
- set "subject" "${1}";
- }
-
- # :matches is used to get the address from the From header
- if address :matches :all "from" "*" {
- set "from_addr" "${1}";
- }
-
- notify :message "${from_addr}${env_from}: ${subject}"
- "mailto:alm@example.com";
- }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 11]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- Example 3:
- require ["enotify", "variables"];
-
- set "notif_method"
- "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail";
-
- if header :contains "subject" "Your dog" {
- set "notif_method" "tel:+14085551212";
- }
-
- if header :contains "to" "sievemailinglist@example.org" {
- set "notif_method" "";
- }
-
- if not string :is "${notif_method}" "" {
- notify "${notif_method}";
- }
-
- if header :contains "from" "boss@example.org" {
- # :matches is used to get the value of the Subject header
- if header :matches "Subject" "*" {
- set "subject" "${1}";
- }
-
- # don't need high importance notification for
- # a 'for your information'
- if not header :contains "subject" "FYI:" {
- notify :importance "1" :message "BOSS: ${subject}"
- "tel:+14085551212";
- }
- }
-
-3.8. Requirements on notification methods specifications
-
- This section describes requirements for documents that define
- specific Sieve notification methods.
-
- Notification mechanisms MUST NOT add new Sieve tags to the notify
- action.
-
- A notification method MAY allow modification of the final
- notification text -- for example, truncating it if it exceeds a
- length limit, or modifying characters that can not be represented in
- the target character set. Characters in the notification text which
- can't be represented by the notification method SHOULD be replaced
- with a symbol indicating an unknown character. Allowed modifications
- MUST be documented in the document describing the notification
- method.
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 12]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- A notification method MAY ignore parameters specified in the Notify
- action.
-
- A notification method MAY recommend the default message value to be
- used if the :message argument is not specified.
-
- Notifications SHOULD include timestamps, if the notification method
- allows for their transmission outside of the textual message.
- Implementation methods which can only transmit timestamps in the
- textual message MAY include them in the textual message.
-
- A notification MUST include means to identify/track its origin, in
- order to allow a recipient to stop notifications or find out how to
- contact the sender. This requirement is to help tracking a
- misconfigured or abusive origin of notifications.
-
- Methods SHOULD NOT include any other extraneous information not
- specified in parameters to the notify action.
-
- Methods MUST specify which URI parameters (if any) must be ignored,
- which ones must be used in the resulting notification and which ones
- must cause an error.
-
- Methods MUST specify what values are returned by the
- notify_method_capability test Section 5, in particular for the
- "online" notification-capability.
-
- If there are errors sending the notification, the Sieve interpreter
- SHOULD ignore the notification and not retry indefinitely. The Sieve
- interpreter MAY throttle notifications; if it does, a request to send
- a notification MAY be silently ignored. Documents describing
- notification methods SHOULD describe how retries, throttling,
- duplicate suppression (if any), etc. are to be handled by
- implementations.
-
-
-4. Test valid_notify_method
-
- Usage: valid_notify_method <notification-uris: string-list>
-
- The "valid_notify_method" test is true if the notification methods
- listed in the notification-uris argument are supported and they are
- valid both syntactically (including URI parameters) and semantically
- (including implementation-specific semantic restrictions). This test
- MUST perform exactly the same validation as would be performed on the
- "method" parameter to the "notify" action.
-
- The test is true only if ALL of the listed notification methods are
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 13]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- supported and valid.
-
-
-
- Example 4 (partial):
- if not valid_notify_method ["mailto:",
- "http://gw.example.net/notify?test"] {
- stop;
- }
-
-
-5. Test notify_method_capability
-
- Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE]
- <notification-uri: string>
- <notification-capability: string>
- <key-list: string-list>
-
- The "notify_method_capability" test retrieves the notification
- capability specified by the notification-capability string that is
- specific to the notification-uri and matches it to the values
- specified in the key-list. The test succeeds if a match occurs. The
- type of match defaults to ":is" and the default comparator is
- "i;ascii-casemap".
-
- The notification-capability parameter is case insensitive.
-
- The notify_method_capability test MUST fail unconditionally if the
- specified notification-uri is syntactically invalid (as determined by
- the valid_notify_method test Section 4) or specifies an unsupported
- notification method. However this MUST NOT cause an error.
-
- The notify_method_capability test MUST fail unconditionally if the
- specified notification-capability item is not known to the Sieve
- interpreter. A script MUST NOT fail with an error if the item does
- not exist. This allows scripts to be written that handle nonexistent
- items gracefully.
-
- This document defines a single notification-capability value
- "online", which is described below. Additional notification-
- capability values may be defined by using the procedure defined in
- Section 9.3.
-
- The "relational" extension [Relational] adds a match type called
- ":count". The count of an notify_method_capability test is 0 if the
- returned information is the empty string, or 1 otherwise.
-
- For the "online" notification-capability the notify_method_capability
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 14]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- test can match one of the following key-list values:
-
- o "yes" - the entity identified by the notification-uri can receive
- a notify notification immediately. Note that even after this
- value is returned, there is no guarantee that the entity would
- actually be able to receive any notification immediately or even
- receive it at all. Transport errors, recipient policy, etc. can
- prevent that.
-
- o "no" - the entity identified by the notification-uri is not
- currently available to receive an immediate notification.
-
- o "maybe" - Sieve interpreter can't determine if the the entity
- identified by the notification-uri is online or not.
-
-
-
- Example 5:
- require ["enotify"];
-
- if notify_method_capability
- "xmpp:tim@example.com?message;subject=SIEVE"
- "Online"
- "yes" {
- notify :importance "1" :message "You got mail"
- "xmpp:tim@example.com?message;subject=SIEVE";
- } else {
- notify :message "You got mail" "tel:+14085551212";
- }
-
-
-6. Modifier encodeurl to the 'set' action
-
- Usage: ":encodeurl"
-
- When the Sieve script specifies both "variables" [Variables] and
- "enotify" capabilities in the "require", a new "set" action modifier
- (see [Variables]) ":encodeurl" becomes available to Sieve scripts.
- This modifier performs percent-encoding of any octet in the string
- which doesn't belong to the "unreserved" set (see [URI]). The
- percent-encoding procedure is described in [URI].
-
- The ":encodeurl" modifier has precedence 15.
-
-
-
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 15]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- Example 6:
- require ["enotify", "variables"];
-
- set :encodeurl "body_param" "Safe body&evil=evilbody";
-
- notify "mailto:tim@example.com?body=${body_param}";
-
-
-7. Interactions with Other Sieve Actions
-
- The notify action is compatible with all other actions, and does not
- affect the operation of other actions. In particular, the notify
- action MUST NOT cancel the implicit keep.
-
- Multiple executed notify actions are allowed. Specific notification
- methods MAY allow multiple notifications from the same script to be
- collapsed into one.
-
-
-8. Security Considerations
-
- Security considerations are discussed in [Sieve]. Additionally,
- implementations must be careful to follow the security considerations
- of the specific notification methods.
-
- The notify action is potentially very dangerous. The path the
- notification takes through the network may not be secure. An error
- in the options string may cause the message to be transmitted to
- someone it was not intended for, or may expose information to
- eavesdroppers.
-
- Just because a notification is received doesn't mean that it was sent
- by the Sieve implementation. It might be possible to forge
- notifications or modify parts of valid notifications with some
- notification methods.
-
- Forgery of the :importance value (for example by unauthorized script
- modification) can potentially result in slow down in notification
- delivery.
-
- Note that some components of notifications should not be trusted.
- For example the timestamp field can be easily forged or modified when
- some notification transports are used. Even if the timestamp is
- believed to be correct by the sender and is not modified in transit,
- it might be misleading on the receiving system due to clock
- differences.
-
- An organization may have a policy about the forwarding of classified
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 16]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- information to unclassified networks. Unless the policy is also
- enforced in the module responsible for generating (or sending) of
- notifications, users can use the extension defined in this document
- to extract classified information and bypass the policy.
-
- Notifications can result in loops and bounces. Also, allowing a
- single script to notify multiple destinations can be used as a means
- of amplifying the number of messages in an attack. Moreover, if loop
- detection is not properly implemented it may be possible to set up
- exponentially growing notification loops. Accordingly, Sieve
- notification methods:
-
- 1. MUST provide mechanisms for avoiding notification loops.
-
- 2. MUST provide the means for administrators to limit the ability of
- users to abuse notify. In particular, it MUST be possible to
- limit the number of notify actions a script can perform.
- Additionally, if no use cases exist for using notify with
- multiple destinations, this limit SHOULD be set to 1. Additional
- limits, such as the ability to restrict notify to local users MAY
- also be implemented.
-
- 3. MUST provide facilities to log use of notify in order to
- facilitate tracking down abuse.
-
- 4. MAY use script analysis to determine whether or not a given
- script can be executed safely. While the Sieve language is
- sufficiently complex that full analysis of all possible scripts
- is computationally infeasible, the majority of real-world scripts
- are amenable to analysis. For example, an implementation might
- allow scripts that it has determined are safe to run unhindered,
- block scripts that are potentially problematic, and subject
- unclassifiable scripts to additional auditing and logging.
-
- Allowing notify action at all may not be appropriate in situations
- where Sieve scripts are associated with email accounts which are
- freely-available and/or not trackable to a human who can be held
- accountable for creating message bombs or other abuse.
-
- Implementations that construct URIs internally from various notify
- parameters MUST make sure that all components of such URIs are
- properly percent-encoded (see [URI]). In particular this applies to
- values of the :from and the :message tagged arguments and may apply
- to the :options values.
-
- Header/envelope tests [Sieve] together with Sieve variables can be
- used to extract the list of users to receive notifications from the
- incoming email message or its envelope. This is potentially quite
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 17]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- dangerous, as this can be used for Deny Of Service attacks on
- recipients controlled by the message sender. For this reason
- implementations SHOULD NOT allow use of variables containing values
- extracted from the email message in the method parameter to the
- notify action. Note that violation of this SHOULD NOT may result in
- the creation of an open relay, i.e. any sender would be able to
- create specially crafted email messages that would result in
- notifications delivered to recipients under the control of the
- sender. In worst case this might result in financial loss by user
- controlling the Sieve script and/or by recipients of notifications
- (e.g. if a notification is an SMS message).
-
- Note that the last SHOULD NOT is not a generic prohibition of use of
- variables in the notify action, as controlling the target of a
- notification by extracting it from user owned data stores (such as
- user's LDAP entry) is considered to be useful.
-
-
-9. IANA Considerations
-
-9.1. Registration of Sieve extension
-
- To: iana@iana.org
- Subject: Registration of new Sieve extension
- Capability name: enotify
- Description: adds the 'notify' action for notifying user about the
- received message. It also provides two new test: valid_notify_method
- checks notification URIs for validity; notify_method_capability can
- check recipients capabilities.
- RFC number: this RFC
- Contact address:
- The Sieve discussion list <ietf-mta-filters@imc.org>
-
- This information should be added to the list of sieve extensions
- given on http://www.iana.org/assignments/sieve-extensions.
-
-9.2. New registry for Sieve notification mechanisms
-
- IANA is requested to create a new registry for Sieve notification
- mechanisms. This registry contains both vendor-controlled
- notification mechanism names (beginning with "vnd.") and IETF-
- controlled notification mechanism names. Vendor-controlled
- notification mechanism names have the format as defined in the
- following paragraph and may be registered on a "First Come First
- Served" basis [IANA-GUIDELINES], by applying to IANA with the form
- specified later in this section. Registration of notification
- mechanisms that do not begin with "vnd." are registered using the
- "Specification Required" policy [IANA-GUIDELINES].
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 18]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- Vendor-controlled notification mechanism names MUST have the form
- "vnd.<vendor-name>.<mechanism-name>", where <vendor-name> is as
- specified in the ACAP Vendor Subtree registry [ACAP].
-
- This defines the template for a new registry for Sieve notification
- mechanisms, to be created as
- http://www.iana.org/assignments/sieve-notification. There are no
- initial entries for this registry.
-
- To: iana@iana.org
- Subject: Registration of new Sieve notification mechanism
- Mechanism name: [the name of the mechanism]
- Mechanism URI: [the RFC number of the document that defines the URI
- used by this mechanism. Different mechanisms MUST use different URI
- schema.]
- Mechanism-specific options: [the names of any Sieve notify option
- names (as used in the :options parameter) that are specific to this
- mechanism, or "none"]
- Permanent and readily available reference: [the RFC number or an URL
- of the document that defines this notification mechanism]
- Person and email address to contact for further information: [the
- name and email address of the technical contact for information about
- this mechanism]
-
-9.3. New registry for notification-capability parameters
-
- IANA is requested to create a new registry for notification-
- capability parameter of the notify_method_capability test. This
- registry contains both vendor-controlled notification-capability
- values (beginning with "vnd.") and IETF-controlled notification-
- capability values. Vendor-controlled notification-capability values
- have the format as defined in the following paragraph and may be
- registered on a "First Come First Served" basis [IANA-GUIDELINES], by
- applying to IANA with the form specified later in this section.
- Registration of notification-capability values that do not begin with
- "vnd." are registered using the "Specification Required" policy
- [IANA-GUIDELINES].
-
- Vendor-controlled notification-capability values MUST have the form
- "vnd.<vendor-name>.<capability-name>", where <vendor-name> is as
- specified in the ACAP Vendor Subtree registry [ACAP].
-
- The following template must be used for registering notification-
- capability parameters:
-
- To: iana@iana.org
- Subject: Registration of a new notification-capability parameter
- Capability name: [the name of the notification-capability]
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 19]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- Description: [a description of what the notification-capability is
- for]
- Syntax: [formal definition of allowed values and their syntax]
- Permanent and readily available reference(s): [the RFC number(s) or
- an URL of the document that defines this notification mechanism]
- Contact information: [the name and email address of the technical
- contact for information about this mechanism]
-
- Below is the registration form for the "online" notification-
- capability:
- To: iana@iana.org
- Subject: Registration of a new notification-capability parameter
- Capability name: online
- Description: Returns whether the entity identified by the
- notification-uri parameter to the notify_method_capability test can
- receive a notify notification immediately.
- Syntax: Can contain one of three values: "yes", "no" and "maybe".
- Values MUST be in lowercase.
- Permanent and readily available reference(s): This RFC
- Contact information: The Sieve discussion list
- <ietf-mta-filters@imc.org>
-
-
-10. Acknowledgements
-
- Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus
- Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E.
- Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt
- Gulbrandsen, Peter Saint-Andre, Sean Turner, Cullen Jennings and Pasi
- Eronen for help with this document.
-
-
-11. References
-
-11.1. Normative References
-
- [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 4234, October 2005.
-
- [Kwds] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [MailTo] Leiba, B. and M. Haardt, "Sieve Notification Mechanism:
- mailto", work in progress, draft-ietf-sieve-notify-mailto,
- October 2006.
-
- [Relational]
- Segmuller, W. and B. Leiba, "Sieve Extension: Relational
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 20]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
- Tests", work in progress, draft-ietf-sieve-3431bis,
- December 2005.
-
- [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
- Language", work in progress, draft-ietf-sieve-3028bis,
- August 2006.
-
- [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifier (URI): Generic Syntax", STD 66,
- RFC 3986, January 2005.
-
- [Variables]
- Homme, K., "Sieve Extension: Variables", work in
- progress, draft-ietf-sieve-variables, December 2005.
-
-11.2. Informative References
-
- [ACAP] Newman, C. and J. Myers, "ACAP -- Application
- Configuration Access Protocol", RFC 2244, November 1997.
-
- [IANA-GUIDELINES]
- Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [TEL-URI] Schulzrinne, H., "The tel URI for Telephone Numbers",
- RFC 3966, December 2004.
-
- [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence
- Protocol (XMPP): Core", RFC 3920, October 2004.
-
- [XMPP-URI]
- Saint-Andre, P., "Internationalized Resource Identifiers
- (IRIs) and Uniform Resource Identifiers (URIs) for the
- Extensible Messaging and Presence Protocol (XMPP)", work
- in progress, draft-saintandre-rfc4622bis, June 2007.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 21]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
-Authors' Addresses
-
- Alexey Melnikov (editor)
- Isode Limited
- 5 Castle Business Village
- 36 Station Road
- Hampton, Middlesex TW12 2BX
- UK
-
- Email: Alexey.Melnikov@isode.com
-
-
- Barry Leiba (editor)
- IBM T.J. Watson Research Center
- 19 Skyline Drive
- Hawthorne, NY 10532
- US
-
- Phone: +1 914 784 7941
- Email: leiba@watson.ibm.com
-
-
- Wolfgang Segmuller
- IBM T.J. Watson Research Center
- 19 Skyline Drive
- Hawthorne, NY 10532
- US
-
- Phone: +1 914 784 7408
- Email: werewolf@us.ibm.com
-
-
- Tim Martin
- BeThereBeSquare Inc.
- 672 Haight st.
- San Francisco, CA 94117
- US
-
- Phone: +1 510 260-4175
- Email: timmartin@alumni.cmu.edu
-
-
-
-
-
-
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 22]
-
-Internet-Draft Sieve Extension: Notifications December 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-Melnikov, et al. Expires June 26, 2008 [Page 23]
-
-
diff --git a/doc/rfc/draft-ietf-sieve-notify-mailto-10.txt b/doc/rfc/notify-mailto.rfc5436.txt
similarity index 51%
rename from doc/rfc/draft-ietf-sieve-notify-mailto-10.txt
rename to doc/rfc/notify-mailto.rfc5436.txt
index 3c761da15a8aa484c9f0283f4a3c870516bae182..3665a7f7386b1fe2ad6b5e4315def0d1d82ca125 100644
--- a/doc/rfc/draft-ietf-sieve-notify-mailto-10.txt
+++ b/doc/rfc/notify-mailto.rfc5436.txt
@@ -1,61 +1,36 @@
-Sieve Working Group B. Leiba
-Internet-Draft IBM T.J. Watson Research Center
-Updates: 3834 (if approved) M. Haardt
-Intended status: Standards Track freenet.de GmbH
-Expires: June 7, 2009 December 4, 2008
-
-
- Sieve Notification Mechanism: mailto
- draft-ietf-sieve-notify-mailto-10
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on June 7, 2009.
-
-
-
-
-
-
-
+Network Working Group B. Leiba
+Request for Comments: 5436 IBM T.J. Watson Research Center
+Updates: 3834 M. Haardt
+Category: Standards Track freenet.de GmbH
+ January 2009
+ Sieve Notification Mechanism: mailto
+Status of This Memo
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+Copyright Notice
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
-Leiba & Haardt Expires June 7, 2009 [Page 1]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents (http://trustee.ietf.org/
+ license-info) in effect on the date of publication of this document.
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
Abstract
@@ -63,40 +38,12 @@ Abstract
notifications, to allow notifications to be sent by electronic mail.
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.2. Conventions used in this document . . . . . . . . . . . . 3
-
- 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1. Notify parameter "method" . . . . . . . . . . . . . . . . 4
- 2.2. Test notify_method_capability . . . . . . . . . . . . . . 4
- 2.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . 4
- 2.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . 4
- 2.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . 4
- 2.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . 4
- 2.7. Other Definitions . . . . . . . . . . . . . . . . . . . . 5
- 2.7.1. The Auto-Submitted header field . . . . . . . . . . . . . 7
- 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4. Internationalization Considerations . . . . . . . . . . . 10
- 5. Security Considerations . . . . . . . . . . . . . . . . . 11
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 13
- 6.1. Registration of notification mechanism . . . . . . . . . . 13
- 6.2. New registry for Auto-Submitted header field keywords . . 13
- 6.3. Initial registration of Auto-Submitted header field
- keywords . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . 15
- 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
- 7.2. Non-Normative References . . . . . . . . . . . . . . . . . 15
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . 16
- Intellectual Property and Copyright Statements . . . . . . 17
@@ -108,30 +55,36 @@ Table of Contents
-Leiba & Haardt Expires June 7, 2009 [Page 2]
+Leiba & Haardt Standards Track [Page 1]
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
-
-1. Introduction
-
-1.1. Overview
-
- The [Notify] extension to the [Sieve] mail filtering language is a
- framework for providing notifications by employing URIs to specify
- the notification mechanism. This document defines how [mailto] URIs
- are used to generate notifications by e-mail.
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
-1.2. Conventions used in this document
-
- Conventions for notations are as in [Sieve] section 1.1, including
- the use of [Kwds].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [Kwds].
+Table of Contents
+ 1. Introduction ....................................................3
+ 1.1. Overview ...................................................3
+ 1.2. Conventions Used in This Document ..........................3
+ 2. Definition ......................................................3
+ 2.1. Notify Parameter "method" ..................................3
+ 2.2. Test notify_method_capability ..............................3
+ 2.3. Notify Tag ":from" .........................................3
+ 2.4. Notify Tag ":importance" ...................................4
+ 2.5. Notify Tag ":options" ......................................4
+ 2.6. Notify Tag ":message" ......................................4
+ 2.7. Other Definitions ..........................................4
+ 2.7.1. The Auto-Submitted Header Field .....................6
+ 3. Examples ........................................................7
+ 4. Internationalization Considerations .............................8
+ 5. Security Considerations .........................................9
+ 6. IANA Considerations ............................................10
+ 6.1. Registration of Notification Mechanism ....................10
+ 6.2. New Registry for Auto-Submitted Header Field Keywords .....10
+ 6.3. Initial Registration of Auto-Submitted Header
+ Field Keywords ............................................11
+ 7. References .....................................................11
+ 7.1. Normative References ......................................11
+ 7.2. Informative References ....................................12
@@ -158,16 +111,28 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
+Leiba & Haardt Standards Track [Page 2]
+
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
+1. Introduction
+1.1. Overview
+ The [Notify] extension to the [Sieve] mail filtering language is a
+ framework for providing notifications by employing URIs to specify
+ the notification mechanism. This document defines how [mailto] URIs
+ are used to generate notifications by email.
+1.2. Conventions Used in This Document
-Leiba & Haardt Expires June 7, 2009 [Page 3]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
+ Conventions for notations are as in Section 1.1 of [Sieve], including
+ the use of [Kwds].
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [Kwds].
2. Definition
@@ -175,7 +140,7 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
"notification message") to notify a recipient about a "triggering
message".
-2.1. Notify parameter "method"
+2.1. Notify Parameter "method"
The mailto notification mechanism uses standard mailto URIs as
specified in [mailto]. mailto URIs may contain header fields
@@ -190,41 +155,41 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
logged in. Otherwise, the test returns "maybe" for this notification
method.
-2.3. Notify tag ":from"
+2.3. Notify Tag ":from"
- The :from tag overrides the default sender of the notification
+ The ":from" tag overrides the default sender of the notification
message. "Sender", here, refers to the value used in the [RFC5322]
"From" header. Implementations MAY also use this value in the
[RFC5321] "MAIL FROM" command (the "envelope sender"), or they may
prefer to establish a mailbox that receives bounces from notification
messages.
-2.4. Notify tag ":importance"
- The :importance tag has no special meaning for this notification
- mechanism, and this specification puts no restriction on its use.
- Implementations MAY use the value of :importance to set a priority or
- importance indication on the notification message (perhaps a visual
- indication, or perhaps making use of one of the non-standard but
- commonly used message headers).
-2.5. Notify tag ":options"
- This tag is not used by the mailto method.
+Leiba & Haardt Standards Track [Page 3]
+
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
-2.6. Notify tag ":message"
- The value of this tag, if it is present, is used as the subject of
- the notification message, and overrides all other mechanisms for
- determining the subject (as described below). Its value SHOULD NOT
+2.4. Notify Tag ":importance"
+ The ":importance" tag has no special meaning for this notification
+ mechanism, and this specification puts no restriction on its use.
+ Implementations MAY use the value of ":importance" to set a priority
+ or importance indication on the notification message (perhaps a
+ visual indication, or perhaps making use of one of the non-standard
+ but commonly used message headers).
+2.5. Notify Tag ":options"
-Leiba & Haardt Expires June 7, 2009 [Page 4]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
+ This tag is not used by the mailto method.
+2.6. Notify Tag ":message"
+ The value of this tag, if it is present, is used as the subject of
+ the notification message, and overrides all other mechanisms for
+ determining the subject (as described below). Its value SHOULD NOT
normally be truncated, though it may be sensible to truncate an
excessively long value.
@@ -252,35 +217,43 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
is likely to result in multiple notifications, and increases the
danger of message loops.
+ Implementations SHOULD consider limiting notification messages. In
+ particular, they SHOULD NOT sent duplicate notifications to the same
+ address from the same script invocation. Batching of notifications
+
+
+
+Leiba & Haardt Standards Track [Page 4]
+
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
+
+
+ within a short time to the same address might also be useful.
+ Different implementations, different administrative domains, and
+ different users may have different needs; configuration options are a
+ good idea here.
+
The overall notification message is composed using the following
guidelines (see [RFC5322] for references to message header fields):
o If the envelope sender of the triggering message is empty, the
envelope sender of the notification message MUST be empty as well,
to avoid message loops. Otherwise, the envelope sender of the
- notification message SHOULD be set to the value of the ":from"
- parameter to the notify action, if one is specified, has email
- address syntax and is valid according to the implementation
- specific security checks (see Section 3.3 of [Notify]). If
- ":from" is not specified or is not valid, the envelope sender of
- the notification message SHOULD be set either to the envelope "to"
- field from the triggering message, as used by Sieve, or to an
- email address associated with the notification system, at the
- discretion of the implementation. This MUST NOT be overridden by
- a "from" URI header, and any such URI header MUST be ignored.
+ notification message SHOULD be set to the value of the ":from" tag
+ to the notify action, if one is specified, has email address
+ syntax, and is valid according to the implementation-specific
+ security checks (see Section 3.3 of [Notify]). If ":from" is not
+ specified or is not valid, the envelope sender of the notification
+ message SHOULD be set either to the envelope "to" field from the
+ triggering message, as used by Sieve, or to an email address
+ associated with the notification system, at the discretion of the
+ implementation. This MUST NOT be overridden by a "from" URI
+ header, and any such URI header MUST be ignored.
o The envelope recipient(s) of the notification message SHOULD be
set to the address(es) specified in the URI (including any URI
headers where the hname is "to" or "cc").
-
-
-
-Leiba & Haardt Expires June 7, 2009 [Page 5]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
-
o The header field "Auto-Submitted: auto-notified" MUST be included
in the notification message (see Section 2.7.1). This is to
reduce the likelihood of message loops, by tagging this as an
@@ -290,9 +263,9 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
considered unsafe and MUST be ignored.
o The "From:" header field of the notification message SHOULD be set
- to the value of the ":from" parameter to the notify action, if one
- is specified, has email address syntax and is valid according to
- the implementation specific security checks (see Section 3.3 of
+ to the value of the ":from" tag to the notify action, if one is
+ specified, has email address syntax, and is valid according to the
+ implementation-specific security checks (see Section 3.3 of
[Notify]). If ":from" is not specified or is not valid, the
"From:" header field of the notification message SHOULD be set
either to the envelope "to" field from the triggering message, as
@@ -301,15 +274,25 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
This MUST NOT be overridden by a "from" URI header, and any such
URI header MUST be ignored.
+
+
+
+
+
+Leiba & Haardt Standards Track [Page 5]
+
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
+
+
o The "To:" header field of the notification message SHOULD be set
to the address(es) specified in the URI (including any URI headers
where the hname is "to").
o The "Subject:" field of the notification message SHOULD contain
- the value defined by the :message notify tag, as described in
- [Notify]. If there is no :message tag and there is a "subject"
- header on the URI, then that value SHOULD be used. If that is
- also absent, the subject SHOULD be retained from the triggering
+ the value defined by the ":message" tag, as described in [Notify].
+ If there is no ":message" tag and there is a "subject" header on
+ the URI, then that value SHOULD be used. If the "subject" header
+ is also absent, the subject SHOULD be retained from the triggering
message. Note that Sieve [Variables] can be used to advantage
here, as shown in the example in Section 3.
@@ -329,14 +312,6 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
MUST be placed above these (see Section 2.7.1). URI headers with
hname "received" are considered unsafe, and MUST be ignored.
-
-
-
-Leiba & Haardt Expires June 7, 2009 [Page 6]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
-
o Other header fields of the notification message that are normally
related to an individual new message (such as "Message-ID" and
"Date") are generated for the notification message in the normal
@@ -352,50 +327,49 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
value when adding URI headers to the message, to be consistent
with common practice in email headers.
-2.7.1. The Auto-Submitted header field
+2.7.1. The Auto-Submitted Header Field
The header field "Auto-Submitted: auto-notified" MUST be included in
the notification message (see [RFC3834]). The "Auto-Submitted"
header field is considered a "trace field", similar to "Received"
+
+
+
+Leiba & Haardt Standards Track [Page 6]
+
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
+
+
header fields (see [RFC5321]). If the implementation retains the
"Received" fields from the triggering message (see above), the "Auto-
Submitted" field MUST be placed above those "Received" fields,
serving as a boundary between the ones from the triggering message
and those that will be part of the notification message.
- The auto-notified Auto-Submitted field MUST include one or both of
- the following parameters:
+ The header field "Auto-Submitted: auto-notified" MUST include one or
+ both of the following parameters:
- o owner-email - specifies an email address of the owner of the Sieve
- script that generated this notification. If specified, it might
- be used to identify or contact the script's owner. The parameter
- attribute is "owner-email", and the parameter value is a quoted
- string containing an email address, as defined by "addr-spec" in
- [RFC5322]. Example:
+ o owner-email - specifies an email address, determined by the
+ implementation, of the owner of the Sieve script that generated
+ this notification. If specified, it might be used to identify or
+ contact the script's owner. The parameter attribute is "owner-
+ email", and the parameter value is a quoted string containing an
+ email address, as defined by "addr-spec" in [RFC5322]. Example:
Auto-Submitted: auto-notified; owner-email="me@example.com"
- o owner-token - specifies an opaque token that the administrative
- domain of the owner of the Sieve script that generated this
- notification can identify the owner with. This might be used to
- allow identification of the owner while protecting the owner's
- privacy. The parameter attribute is "owner-token", and the
- parameter value is as defined by "token" in [RFC3834]. Example:
+ o owner-token - specifies an opaque token, determined by the
+ implementation, that the administrative domain of the owner of the
+ Sieve script that generated this notification can use to identify
+ the owner. This might be used to allow identification of the
+ owner while protecting the owner's privacy. The parameter
+ attribute is "owner-token", and the parameter value is as defined
+ by "token" in [RFC3834]. Example:
Auto-Submitted: auto-notified; owner-token=af3NN2pK5dDXI0W
See Section 5 for discussion of possible uses of these parameters.
-
-
-
-
-Leiba & Haardt Expires June 7, 2009 [Page 7]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
-
3. Examples
-
Triggering message (received by recipient@example.org):
Return-Path: <knitting-bounces@example.com>
@@ -416,9 +390,15 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
I just finished a great new sweater!
+
+Leiba & Haardt Standards Track [Page 7]
+
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
+
+
Sieve script (run on behalf of recipient@example.org):
- require ["notify", "variables"];
+ require ["enotify", "variables"];
if header :contains "list-id" "knitting.example.com" {
if header :matches "Subject" "[*] *" {
@@ -442,13 +422,6 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
To: 0123456789@sms.example.net, backup@example.com
Subject: From Knitting list: A new sweater
-
-
-Leiba & Haardt Expires June 7, 2009 [Page 8]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
-
Note that:
o Fields such as "Message-ID:" and "Date:" were generated afresh for
@@ -457,7 +430,7 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
o Additional "Received:" fields will be added to the notification
message in transit; the ones shown were copied from the triggering
- message. New ones will be added above the "Auto-Submitted:"
+ message. New ones will be added above the Auto-Submitted: header
field.
o If this message should appear at the mail.example.org server
@@ -467,44 +440,6 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
notification, and it includes an optional owner-email parameter
for identification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leiba & Haardt Expires June 7, 2009 [Page 9]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
-
4. Internationalization Considerations
This specification introduces no specific internationalization issues
@@ -512,53 +447,9 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leiba & Haardt Expires June 7, 2009 [Page 10]
+Leiba & Haardt Standards Track [Page 8]
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
5. Security Considerations
@@ -574,12 +465,12 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
Section 2.7 for discussion of this and some suggestions. Other
possible mitigations for mail loops involve types of service
limitations. For example, the number of notifications generated for
- a single user might be limited to no more than, say, 30 in a 60-
- minute period. Of course, this technique presents its own problems,
- in that the actual rate limit must be selected carefully, to allow
- most legitimate situations in the given environment, and even with
- careful selection it's inevitable that there will be false positives
- -- and false negatives.
+ a single user might be limited to no more than, say, 30 in a
+ 60-minute period. Of course, this technique presents its own
+ problems, in that the actual rate-limit must be selected carefully,
+ to allow most legitimate situations in the given environment. Even
+ with careful selection, it's inevitable that there will be false
+ positives -- and false negatives.
Ultimately, human intervention may be necessary to re-enable
notifications that have been disabled because a loop was detected, or
@@ -608,74 +499,30 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
MUST be prepared to respond to such complaints, in order to limit the
damage caused by a faulty script.
- Problems can also show up if notification messages are sent to a
-Leiba & Haardt Expires June 7, 2009 [Page 11]
+
+Leiba & Haardt Standards Track [Page 9]
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
+ Problems can also show up if notification messages are sent to a
gateway into another service, such as SMS. Information from the
- email message is often lost in the gateway translation, and in this
- case critical information needed to avoid loops, to contact the
+ email message is often lost in the gateway translation; and in this
+ case, critical information needed to avoid loops, to contact the
script owner, and to resolve other problems might be lost.
Developers of email gateways should consider these issues, and try to
- preseve as much information as possible, including what appears in
- email trace headers and Auto-Submitted.
+ preserve as much information as possible, including what appears in
+ email trace headers and the Auto-Submitted header field.
Additional security considerations are discussed in [Sieve] and in
[Notify].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leiba & Haardt Expires June 7, 2009 [Page 12]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
-
6. IANA Considerations
-6.1. Registration of notification mechanism
+6.1. Registration of Notification Mechanism
The following template specifies the IANA registration of the Sieve
notification mechanism specified in this document:
@@ -684,21 +531,20 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
Subject: Registration of new Sieve notification mechanism
Mechanism name: mailto
Mechanism URI: RFC2368
- Mechanism-specific tags: none
- Standards Track/IESG-approved experimental RFC number: this RFC
+ Mechanism-specific options: none
+ Permanent and readily available reference: RFC 5436
Person and email address to contact for further information:
- Michael Haardt <michael.haardt@freenet.ag>
+ Michael Haardt <michael.haardt@freenet.ag>
- This information should be added to the list of sieve notification
- mechanisms given on
- http://www.iana.org/assignments/sieve-notification.
+ This information should be added to the list of Sieve notification
+ mechanisms available from http://www.iana.org.
-6.2. New registry for Auto-Submitted header field keywords
+6.2. New Registry for Auto-Submitted Header Field Keywords
Because [RFC3834] does not define a registry for new keywords used in
- the Auto-Submitted header field, we define one here, to be created as
- http://www.iana.org/assignments/auto-submitted-keywords. Keywords
- are registered using the "Specification Required" policy [IANA].
+ the Auto-Submitted header field, we define one here, which has been
+ created and is available from http://www.iana.org. Keywords are
+ registered using the "Specification Required" policy [IANA].
This defines the template to be used to register new keywords.
Initial entries to this registry follow in Section 6.3.
@@ -708,138 +554,98 @@ Internet-Draft Sieve Notification Mechanism: mailto December 2008
Keyword value: [the text value of the field]
Description: [a brief explanation of the purpose of this value]
Parameters: [list any keyword-specific parameters, specify their
- meanings, specify whether they are required or optional; use "none"
- if there are none]
- Standards Track/IESG-approved experimental RFC number: [identifies
- the specification that defines the value being registered]
- Contact: [name and email address to contact for further information]
+ meanings, specify whether they are required or optional; use
+ "none" if there are none]
-6.3. Initial registration of Auto-Submitted header field keywords
- The following are the initial keywords to be registered for the Auto-
- Submitted header field, to be entered in
- http://www.iana.org/assignments/auto-submitted-keywords.
- Keyword value: no
+Leiba & Haardt Standards Track [Page 10]
+
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
+ Permanent and readily available reference: [identifies
+ the specification that defines the value being registered]
+ Contact: [name and email address to contact for further information]
-Leiba & Haardt Expires June 7, 2009 [Page 13]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
+6.3. Initial Registration of Auto-Submitted Header Field Keywords
+ The following are the initial keywords that have been registered in
+ the "Auto-Submitted Header Field Keywords" registry, available from
+ http://www.iana.org.
+ Keyword value: no
Description: Indicates that a message was NOT automatically
- generated, but was created by a human. It is the equivalent to the
- absence of an Auto-Submitted header altogether.
+ generated, but was created by a human. It is the equivalent to
+ the absence of an Auto-Submitted header altogether.
Parameters: none
- Standards Track/IESG-approved experimental RFC number: RFC3834
+ Permanent and readily available reference: RFC3834
Contact: Keith Moore <moore@network-heretics.com>
Keyword value: auto-generated
Description: Indicates that a message was generated by an automatic
- process, and is not a direct response to another message.
+ process, and is not a direct response to another message.
Parameters: none
- Standards Track/IESG-approved experimental RFC number: RFC3834
+ Permanent and readily available reference: RFC3834
Contact: Keith Moore <moore@network-heretics.com>
Keyword value: auto-replied
Description: Indicates that a message was automatically generated as
- a direct response to another message.
+ a direct response to another message.
Parameters: none
- Standards Track/IESG-approved experimental RFC number: RFC3834
+ Permanent and readily available reference: RFC3834
Contact: Keith Moore <moore@network-heretics.com>
Keyword value: auto-notified
Description: Indicates that a message was generated by a Sieve
- notification system.
- Parameters: owner-email, owner-token. Both optional, both refer to
- the owner of the Sieve script that generated this message. See the
- relevant RFC for details.
- Standards Track/IESG-approved experimental RFC number: this RFC
+ notification system.
+ Parameters: owner-email, owner-token. At least one is required;
+ both refer to the owner of the Sieve script that generated this
+ message. See the relevant RFC for details.
+ Permanent and readily available reference: RFC 5436
Contact: Michael Haardt <michael.haardt@freenet.ag>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leiba & Haardt Expires June 7, 2009 [Page 14]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
-
7. References
7.1. Normative References
- [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 5226,
- May 2008.
-
- [Kwds] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
- Martin, "Sieve Extension: Notifications", work in
- progress, draft-ietf-sieve-notify, December 2007.
-
- [RFC3834] Moore, K., "Recommendations for Automatic Responses to
- Electronic Mail", RFC 3834, August 2004.
-
- [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
- October 2008.
-
- [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
- Filtering Language", RFC 5228, January 2008.
-
- [mailto] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
- URL scheme", RFC 2368, July 1998.
-
-7.2. Non-Normative References
-
- [RFC5321] Klensin, J., Ed., "Simple Mail Transfer Protocol",
- RFC 5321, October 2008.
-
- [Variables]
- Homme, K., "Sieve Extension: Variables", RFC 5229,
- January 2008.
-
-
-
-
+ [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+Leiba & Haardt Standards Track [Page 11]
+
+RFC 5436 Sieve Notification Mechanism: mailto January 2009
+ [Kwds] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+ [Notify] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T.
+ Martin, "Sieve Email Filtering: Extension for
+ Notifications", RFC 5435, January 2009.
+ [RFC3834] Moore, K., "Recommendations for Automatic Responses to
+ Electronic Mail", RFC 3834, August 2004.
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ October 2008.
+ [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An
+ Email Filtering Language", RFC 5228, January 2008.
+ [mailto] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
+ URL scheme", RFC 2368, July 1998.
+7.2. Informative References
-Leiba & Haardt Expires June 7, 2009 [Page 15]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
+ [RFC5321] Klensin, J., Ed., "Simple Mail Transfer Protocol",
+ RFC 5321, October 2008.
+ [Variables] Homme, K., "Sieve Extension: Variables", RFC 5229,
+ January 2008.
Authors' Addresses
@@ -850,7 +656,7 @@ Authors' Addresses
US
Phone: +1 914 784 7941
- Email: leiba@watson.ibm.com
+ EMail: leiba@watson.ibm.com
Michael Haardt
@@ -860,93 +666,10 @@ Authors' Addresses
Germany
Phone: +49 241 53087 520
- Email: michael.haardt@freenet.ag
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leiba & Haardt Expires June 7, 2009 [Page 16]
-
-Internet-Draft Sieve Notification Mechanism: mailto December 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-
-
+ EMail: michael.haardt@freenet.ag
-Leiba & Haardt Expires June 7, 2009 [Page 17]
+Leiba & Haardt Standards Track [Page 12]
diff --git a/doc/rfc/notify.rfc5435.txt b/doc/rfc/notify.rfc5435.txt
new file mode 100644
index 0000000000000000000000000000000000000000..4623437d79e49f270e9f3c89448322e8a6fde064
--- /dev/null
+++ b/doc/rfc/notify.rfc5435.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group A. Melnikov, Ed.
+Request for Comments: 5435 Isode Limited
+Category: Standards Track B. Leiba, Ed.
+ W. Segmuller
+ IBM T.J. Watson Research Center
+ T. Martin
+ Endless Crossword
+ January 2009
+
+
+ Sieve Email Filtering: Extension for Notifications
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents (http://trustee.ietf.org/
+ license-info) in effect on the date of publication of this document.
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+Abstract
+
+ Users go to great lengths to be notified as quickly as possible that
+ they have received new mail. Most of these methods involve polling
+ to check for new messages periodically. A push method handled by the
+ final delivery agent gives users quicker notifications and saves
+ server resources. This document does not specify the notification
+ method, but it is expected that using existing instant messaging
+ infrastructure such as Extensible Messaging and Presence Protocol
+ (XMPP), or Global System for Mobile Communications (GSM) Short
+ Message Service (SMS) messages will be popular. This document
+ describes an extension to the Sieve mail filtering language that
+ allows users to give specific rules for how and when notifications
+ should be sent.
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 1]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Conventions Used in This Document ..........................3
+ 2. Capability Identifier ...........................................3
+ 3. Notify Action ...................................................3
+ 3.1. Notify Action Syntax and Semantics .........................3
+ 3.2. Notify Parameter "method" ..................................3
+ 3.3. Notify Tag ":from" .........................................4
+ 3.4. Notify Tag ":importance" ...................................4
+ 3.5. Notify Tag ":options" ......................................5
+ 3.6. Notify Tag ":message" ......................................5
+ 3.7. Examples ...................................................6
+ 3.8. Requirements on Notification Methods Specifications ........7
+ 4. Test valid_notify_method ........................................8
+ 5. Test notify_method_capability ...................................9
+ 6. Modifier encodeurl to the 'set' Action .........................10
+ 7. Interactions with Other Sieve Actions ..........................11
+ 8. Security Considerations ........................................11
+ 9. IANA Considerations ............................................13
+ 9.1. Registration of Sieve Extension ...........................13
+ 9.2. New Registry for Sieve Notification Mechanisms ............14
+ 9.3. New Registry for Notification-Capability Parameters .......14
+ 10. Acknowledgements ..............................................15
+ 11. References ....................................................16
+ 11.1. Normative References .....................................16
+ 11.2. Informative References ...................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 2]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+1. Introduction
+
+ This is an extension to the Sieve language defined by [Sieve] for
+ providing instant notifications. It defines the new action "notify".
+
+ This document does not specify the notification methods. Examples of
+ possible notification methods are email and XMPP. To allow for the
+ portability of scripts that use notifications, implementation of the
+ [MailTo] method is mandatory. Other available methods shall depend
+ upon the implementation and configuration of the system.
+
+1.1. Conventions Used in This Document
+
+ Conventions for notations are as in [Sieve], Section 1.1, including
+ the use of [ABNF].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [Kwds].
+
+2. Capability Identifier
+
+ The capability string associated with the extension defined in this
+ document is "enotify".
+
+3. Notify Action
+
+3.1. Notify Action Syntax and Semantics
+
+ Usage: notify [":from" string]
+ [":importance" <"1" / "2" / "3">]
+ [":options" string-list]
+ [":message" string]
+ <method: string>
+
+ The "notify" action specifies that a notification should be sent to a
+ user. The format of the notification is implementation-defined and
+ is also affected by the notification method used (see Section 3.2).
+ However, all content specified in the ":message" parameter SHOULD be
+ included.
+
+3.2. Notify Parameter "method"
+
+ The "method" positional parameter identifies the notification method
+ that will be used; it is a URI [URI]. For example, the notification
+ method can be a tel URI [TEL-URI] with a phone number to send SMS
+ messages to, or an XMPP [XMPP] URI containing an XMPP identifier
+ [XMPP-URI].
+
+
+
+Melnikov, et al. Standards Track [Page 3]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ The supported URI values will be site-specific, but support for the
+ [MailTo] method is REQUIRED in order to ensure interoperability. If
+ a URI schema is specified that the implementation does not support,
+ the notification MUST cause an error condition at run time. Sieve
+ scripts can check the supported methods using the valid_notify_method
+ test to be sure that they only use supported ones, to avoid such
+ error conditions.
+
+ If the "method" parameter contains a supported URI schema, then the
+ URI MUST be checked for syntactic validity. Invalid URI syntax or an
+ unsupported URI extension MUST cause an error. An implementation MAY
+ enforce other semantic restrictions on URIs -- for example, to
+ restrict phone numbers in a tel: URI to a particular geographical
+ region -- and will treat violations of such semantic restrictions as
+ errors.
+
+3.3. Notify Tag ":from"
+
+ A ":from" tag may be used to specify an author of the notification.
+ The syntax of this parameter's value is method-specific.
+ Implementations SHOULD check the syntax according to the notification
+ method specification and generate an error when a syntactically
+ invalid ":from" tag is specified.
+
+ In order to minimize/prevent forgery of the author value,
+ implementations SHOULD impose restrictions on what values can be
+ specified in a ":from" tag. For example, an implementation may
+ restrict this value to be a member of a list of known author
+ addresses or to belong to a particular domain. It is suggested that
+ values that don't satisfy such restrictions simply be ignored rather
+ than causing the "notify" action to fail.
+
+3.4. Notify Tag ":importance"
+
+ The ":importance" tag specifies the importance of quick delivery of
+ the notification, as perceived by the Sieve script owner. The
+ ":importance" tag is followed by a numeric value represented as a
+ string: "1" (high importance), "2" (normal importance), and "3" (low
+ importance). If no importance is given, the default value "2" SHOULD
+ be assumed. A notification method MAY treat the importance value as
+ a transport indicator. For example, it might deliver notifications
+ of high importance quicker than notifications of normal or low
+ importance. Some notification methods allow users to specify their
+ state of activity (for example, "busy" or "away from keyboard"). If
+ the notification method provides this information, it SHOULD be used
+ to selectively send notifications. If, for example, the user marks
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 4]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ herself as "busy", a notification method can require that a
+ notification with importance of "3" is not to be sent; however, the
+ user might be notified of a notification with higher importance.
+
+ If the notification method allows users to filter messages based upon
+ certain parameters in the message, users SHOULD be able to filter
+ based upon importance. If the notification method does not support
+ importance, then this parameter MUST be ignored. An implementation
+ MAY include the importance value in the default message, Section 3.6,
+ if one is not provided.
+
+3.5. Notify Tag ":options"
+
+ The ":options" tag is used to send additional parameters to the
+ notification method. Interpretation of the parameters is method-
+ specific. This document doesn't specify any such additional
+ parameter.
+
+ Each string in the options string list has the following syntax:
+ "<optionname>=<value>"
+ where optionname has the following ABNF [ABNF]:
+
+
+ l-d = ALPHA / DIGIT
+ l-d-p = l-d / "." / "-" / "_"
+ optionname = l-d *l-d-p
+ value = *(%x01-09 / %x0B-0C / %x0E-FF)
+
+3.6. Notify Tag ":message"
+
+ The ":message" tag specifies the message data to be included in the
+ notification. The entirety of the string SHOULD be sent, but
+ implementations MAY shorten the message for technical or aesthetic
+ reasons. If the ":message" parameter is absent, a default
+ implementation-specific message is used. Unless otherwise specified
+ by a particular notification mechanism, an implementation default
+ containing at least the value of the "From" header field and the
+ value of the "Subject" header field is RECOMMENDED.
+
+ In order to construct more complex messages, the notify extension can
+ be used together with the Sieve variables extension [Variables], as
+ shown in the examples below.
+
+
+
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 5]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+3.7. Examples
+
+ Example 1:
+ require ["enotify", "fileinto", "variables"];
+
+ if header :contains "from" "boss@example.org" {
+ notify :importance "1"
+ :message "This is probably very important"
+ "mailto:alm@example.com";
+ # Don't send any further notifications
+ stop;
+ }
+
+ if header :contains "to" "sievemailinglist@example.org" {
+ # :matches is used to get the value of the Subject header
+ if header :matches "Subject" "*" {
+ set "subject" "${1}";
+ }
+
+ # :matches is used to get the value of the From header
+ if header :matches "From" "*" {
+ set "from" "${1}";
+ }
+
+ notify :importance "3"
+ :message "[SIEVE] ${from}: ${subject}"
+ "mailto:alm@example.com";
+ fileinto "INBOX.sieve";
+ }
+
+ Example 2:
+ require ["enotify", "fileinto", "variables", "envelope"];
+
+ if header :matches "from" "*@*.example.org" {
+ # :matches is used to get the MAIL FROM address
+ if envelope :all :matches "from" "*" {
+ set "env_from" " [really: ${1}]";
+ }
+
+ # :matches is used to get the value of the Subject header
+ if header :matches "Subject" "*" {
+ set "subject" "${1}";
+ }
+
+ # :matches is used to get the address from the From header
+ if address :matches :all "from" "*" {
+ set "from_addr" "${1}";
+ }
+
+
+
+Melnikov, et al. Standards Track [Page 6]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ notify :message "${from_addr}${env_from}: ${subject}"
+ "mailto:alm@example.com";
+ }
+
+ Example 3:
+ require ["enotify", "variables"];
+
+ set "notif_method"
+ "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail";
+
+ if header :contains "subject" "Your dog" {
+ set "notif_method" "tel:+14085551212";
+ }
+
+ if header :contains "to" "sievemailinglist@example.org" {
+ set "notif_method" "";
+ }
+
+ if not string :is "${notif_method}" "" {
+ notify "${notif_method}";
+ }
+
+ if header :contains "from" "boss@example.org" {
+ # :matches is used to get the value of the Subject header
+ if header :matches "Subject" "*" {
+ set "subject" "${1}";
+ }
+
+ # don't need high importance notification for
+ # a 'for your information'
+ if not header :contains "subject" "FYI:" {
+ notify :importance "1" :message "BOSS: ${subject}"
+ "tel:+14085551212";
+ }
+ }
+
+3.8. Requirements on Notification Methods Specifications
+
+ This section describes requirements for documents that define
+ specific Sieve notification methods.
+
+ Notification mechanisms MUST NOT add new Sieve tags to the "notify"
+ action.
+
+ A notification method MAY allow modification of the final
+ notification text -- for example, truncating it if it exceeds a
+ length limit or modifying characters that can not be represented in
+ the target character set. Characters in the notification text that
+
+
+
+Melnikov, et al. Standards Track [Page 7]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ can't be represented by the notification method SHOULD be replaced
+ with a symbol indicating an unknown character. Allowed modifications
+ MUST be documented in the document describing the notification
+ method.
+
+ A notification method MAY ignore parameters specified in the "notify"
+ action.
+
+ A notification method MAY recommend the default message value to be
+ used if the ":message" argument is not specified.
+
+ Notifications SHOULD include timestamps, if the notification method
+ allows for their transmission outside of the textual message.
+ Implementation methods that can only transmit timestamps in the
+ textual message MAY include them in the textual message.
+
+ A notification MUST include means to identify/track its origin in
+ order to allow a recipient to stop notifications or find out how to
+ contact the sender. This requirement is to help with tracking a
+ misconfigured or abusive origin of notifications.
+
+ Methods SHOULD NOT include any other extraneous information not
+ specified in parameters to the "notify" action.
+
+ Methods MUST specify which URI parameters (if any) must be ignored,
+ which ones must be used in the resulting notification, and which ones
+ must cause an error.
+
+ Methods MUST specify what values are returned by the
+ notify_method_capability test, Section 5, in particular for the
+ "online" notification-capability.
+
+ If there are errors sending the notification, the Sieve interpreter
+ SHOULD ignore the notification and not retry indefinitely. The Sieve
+ interpreter MAY throttle notifications; if it does, a request to send
+ a notification MAY be silently ignored. Documents describing
+ notification methods SHOULD describe how retries, throttling,
+ duplicate suppression (if any), etc. are to be handled by
+ implementations.
+
+4. Test valid_notify_method
+
+ Usage: valid_notify_method <notification-uris: string-list>
+
+ The valid_notify_method test is true if the notification methods
+ listed in the notification-uris argument are supported and they are
+ valid both syntactically (including URI parameters) and semantically
+
+
+
+
+Melnikov, et al. Standards Track [Page 8]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ (including implementation-specific semantic restrictions). This test
+ MUST perform exactly the same validation as would be performed on the
+ "method" parameter to the "notify" action.
+
+ The test is true only if ALL of the listed notification methods are
+ supported and valid.
+
+ Example 4 (partial):
+ if not valid_notify_method ["mailto:",
+ "http://gw.example.net/notify?test"] {
+ stop;
+ }
+
+5. Test notify_method_capability
+
+ Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE]
+ <notification-uri: string>
+ <notification-capability: string>
+ <key-list: string-list>
+
+ The notify_method_capability test retrieves the notification
+ capability specified by the notification-capability string that is
+ specific to the notification-uri and matches it to the values
+ specified in the key-list. The test succeeds if a match occurs. The
+ type of match defaults to ":is", and the default comparator is
+ "i;ascii-casemap".
+
+ The notification-capability parameter is case insensitive.
+
+ The notify_method_capability test MUST fail unconditionally if the
+ specified notification-uri is syntactically invalid (as determined by
+ the valid_notify_method test, Section 4) or specifies an unsupported
+ notification method. However this MUST NOT cause an error.
+
+ The notify_method_capability test MUST fail unconditionally if the
+ specified notification-capability item is not known to the Sieve
+ interpreter. A script MUST NOT fail with an error if the item does
+ not exist. This allows scripts to be written that handle nonexistent
+ items gracefully.
+
+ This document defines a single notification-capability value
+ "online", which is described below. Additional notification-
+ capability values may be defined by using the procedure defined in
+ Section 9.3.
+
+ The "relational" extension [Relational] adds a match type called
+ ":count". The count of an notify_method_capability test is 0, if the
+ returned information is the empty string, or 1.
+
+
+
+Melnikov, et al. Standards Track [Page 9]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ For the "online" notification-capability, the
+ notify_method_capability test can match one of the following key-list
+ values:
+
+ o "yes" - the entity identified by the notification-uri can receive
+ a notify notification immediately. Note that even after this
+ value is returned, there is no guarantee that the entity would
+ actually be able to receive any notification immediately or even
+ receive it at all. Transport errors, recipient policy, etc. can
+ prevent that.
+
+ o "no" - the entity identified by the notification-uri is not
+ currently available to receive an immediate notification.
+
+ o "maybe" - the Sieve interpreter can't determine if the entity
+ identified by the notification-uri is online or not.
+
+ Example 5:
+ require ["enotify"];
+
+ if notify_method_capability
+ "xmpp:tim@example.com?message;subject=SIEVE"
+ "Online"
+ "yes" {
+ notify :importance "1" :message "You got mail"
+ "xmpp:tim@example.com?message;subject=SIEVE";
+ } else {
+ notify :message "You got mail" "tel:+14085551212";
+ }
+
+6. Modifier encodeurl to the 'set' Action
+
+ Usage: ":encodeurl"
+
+ When the Sieve script specifies both "variables" [Variables] and
+ "enotify" capabilities in the "require", a new "set" action modifier
+ (see [Variables]) ":encodeurl" becomes available to Sieve scripts.
+ This modifier performs percent-encoding of any octet in the string
+ that doesn't belong to the "unreserved" set (see [URI]). The
+ percent-encoding procedure is described in [URI].
+
+ The ":encodeurl" modifier has precedence 15.
+
+
+
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 10]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ Example 6:
+ require ["enotify", "variables"];
+
+ set :encodeurl "body_param" "Safe body&evil=evilbody";
+
+ notify "mailto:tim@example.com?body=${body_param}";
+
+7. Interactions with Other Sieve Actions
+
+ The "notify" action is compatible with all other actions, and does
+ not affect the operation of other actions. In particular, the
+ "notify" action MUST NOT cancel the implicit keep.
+
+ Multiple executed "notify" actions are allowed. Specific
+ notification methods MAY allow multiple notifications from the same
+ script to be collapsed into one.
+
+8. Security Considerations
+
+ Security considerations are discussed in [Sieve]. Additionally,
+ implementations must be careful to follow the security considerations
+ of the specific notification methods.
+
+ The "notify" action is potentially very dangerous. The path the
+ notification takes through the network may not be secure. An error
+ in the options string may cause the message to be transmitted to
+ someone it was not intended for, or may expose information to
+ eavesdroppers.
+
+ Just because a notification is received doesn't mean that it was sent
+ by the Sieve implementation. It might be possible to forge
+ notifications or modify parts of valid notifications with some
+ notification methods.
+
+ Forgery of the ":importance" value (for example, by unauthorized
+ script modification) can potentially result in slowdown in
+ notification delivery.
+
+ Note that some components of notifications should not be trusted.
+ For example, the timestamp field can be easily forged or modified
+ when some notification transports are used. Even if the timestamp is
+ believed to be correct by the sender and is not modified in transit,
+ it might be misleading on the receiving system due to clock
+ differences.
+
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 11]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ An organization may have a policy about the forwarding of classified
+ information to unclassified networks. Unless the policy is also
+ enforced in the module responsible for the generating (or sending) of
+ notifications, users can use the extension defined in this document
+ to extract classified information and bypass the policy.
+
+ Notifications can result in loops and bounces. Also, allowing a
+ single script to notify multiple destinations can be used as a means
+ of amplifying the number of messages in an attack. Moreover, if loop
+ detection is not properly implemented, it may be possible to set up
+ exponentially growing notification loops. Accordingly, Sieve
+ notification methods:
+
+ 1. MUST provide mechanisms for avoiding notification loops.
+
+ 2. MUST provide the means for administrators to limit the ability of
+ users to abuse notify. In particular, it MUST be possible to
+ limit the number of "notify" actions a script can perform.
+ Additionally, if no use cases exist for using "notify" with
+ multiple destinations, this limit SHOULD be set to 1. Additional
+ limits, such as the ability to restrict "notify" to local users,
+ MAY also be implemented.
+
+ 3. MUST provide facilities to log the use of "notify" in order to
+ facilitate tracking down abuse.
+
+ 4. MAY use script analysis to determine whether or not a given
+ script can be executed safely. While the Sieve language is
+ sufficiently complex so that full analysis of all possible
+ scripts is computationally infeasible, the majority of real-world
+ scripts are amenable to analysis. For example, an implementation
+ might allow scripts that it has determined to be safe to run
+ unhindered, block scripts that are potentially problematic, and
+ subject unclassifiable scripts to additional auditing and
+ logging.
+
+ Allowing "notify" action at all may not be appropriate in situations
+ where Sieve scripts are associated with email accounts that are
+ freely-available and/or not trackable to a human who can be held
+ accountable for creating message bombs or other abuse.
+
+ Implementations that construct URIs internally from various notify
+ parameters MUST make sure that all components of such URIs are
+ properly percent-encoded (see [URI]). In particular, this applies to
+ values of the ":from" and ":message" tagged arguments and may apply
+ to the ":options" values.
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 12]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ Header/envelope tests [Sieve], together with Sieve variables, can be
+ used to extract the list of users to receive notifications from the
+ incoming email message or its envelope. This is potentially quite
+ dangerous, as this can be used for denial-of-service attacks on
+ recipients controlled by the message sender. For this reason,
+ implementations SHOULD NOT allow the use of variables containing
+ values extracted from the email message in the "method" parameter to
+ the "notify" action. Note that violation of this SHOULD NOT may
+ result in the creation of an open relay, i.e., any sender would be
+ able to create specially crafted email messages that would result in
+ notifications delivered to recipients under the control of the
+ sender. In the worst case, this might result in financial loss by
+ the user controlling the Sieve script and/or by recipients of
+ notifications (e.g., if a notification is an SMS message).
+
+ Note that the last SHOULD NOT is not a generic prohibition of use of
+ variables in the "notify" action, as controlling the target of a
+ notification by extracting it from user-owned data stores (such as
+ user's Lightweight Directory Access Protocol (LDAP) entry) is
+ considered to be useful.
+
+ It is imperative that whatever implementations use to store the user-
+ defined filtering scripts protect them from unauthorized
+ modification, to preserve the integrity of the mail system. An
+ attacker who can modify a script can cause mail to be discarded,
+ rejected, or forwarded to an unauthorized recipient. In addition,
+ it's possible that Sieve scripts might expose private information,
+ such as mailbox names or email addresses of favored (or disfavored)
+ correspondents. Because of that, scripts SHOULD also be protected
+ from unauthorized retrieval.
+
+9. IANA Considerations
+
+9.1. Registration of Sieve Extension
+
+ To: iana@iana.org
+ Subject: Registration of new Sieve extension
+ Capability name: enotify
+ Description: adds the "notify" action for notifying user about the
+ received message. It also provides two new tests:
+ valid_notify_method checks notification URIs for validity;
+ notify_method_capability can check recipients capabilities.
+ RFC number: this RFC
+ Contact address: The Sieve discussion list
+ <ietf-mta-filters@imc.org>
+
+ This information has been added to the list of Sieve extensions
+ available from http://www.iana.org/.
+
+
+
+Melnikov, et al. Standards Track [Page 13]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+9.2. New Registry for Sieve Notification Mechanisms
+
+ IANA has created a new registry for Sieve notification mechanisms.
+ This registry contains both vendor-controlled notification mechanism
+ names (beginning with "vnd.") and IETF-controlled notification
+ mechanism names. Vendor-controlled notification mechanism names have
+ the format as defined in the following paragraph and may be
+ registered on a "First Come First Served" basis [IANA-GUIDELINES], by
+ applying to IANA with the form specified later in this section.
+ Registration of notification mechanisms that do not begin with "vnd."
+ are registered using a "Specification Required" policy
+ [IANA-GUIDELINES].
+
+ Vendor-controlled notification mechanism names MUST have the form
+ "vnd.<vendor-name>.<mechanism-name>", where <vendor-name> is as
+ specified in the Application Configuration Access Protocol (ACAP)
+ Vendor Subtree registry [ACAP].
+
+ This defines the template for a new registry for Sieve notification
+ mechanisms, which has been created and is available from
+ http://www.iana.org/. There are no initial entries for this
+ registry.
+
+ To: iana@iana.org
+ Subject: Registration of new Sieve notification mechanism
+ Mechanism name: [the name of the mechanism]
+ Mechanism URI: [the RFC number of the document that defines the URI
+ used by this mechanism. Different mechanisms MUST use different
+ URI schema.]
+ Mechanism-specific options: [the names of any Sieve notify options
+ (as used in the ":options" parameter) that are specific to this
+ mechanism, or "none"]
+ Permanent and readily available reference: [the RFC number or an URL
+ of the document that defines this notification mechanism]
+ Person and email address to contact for further information: [the
+ name and email address of the technical contact for information
+ about this mechanism]
+
+9.3. New Registry for Notification-Capability Parameters
+
+ IANA has created a new registry for the notification-capability
+ parameters of the notify_method_capability test. This registry
+ contains both vendor-controlled notification-capability values
+ (beginning with "vnd.") and IETF-controlled notification-capability
+ values. Vendor-controlled notification-capability values have the
+ format as defined in the following paragraph and may be registered on
+ a "First Come First Served" basis [IANA-GUIDELINES], by applying to
+ IANA with the form specified later in this section. Registration of
+
+
+
+Melnikov, et al. Standards Track [Page 14]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ notification-capability values that do not begin with "vnd." are
+ registered using the "Specification Required" policy
+ [IANA-GUIDELINES].
+
+ Vendor-controlled notification-capability values MUST have the form
+ "vnd.<vendor-name>.<capability-name>", where <vendor-name> is as
+ specified in the ACAP Vendor Subtree registry [ACAP].
+
+ The following template must be used for registering notification-
+ capability parameters:
+
+ To: iana@iana.org
+ Subject: Registration of a new notification-capability parameter
+ Capability name: [the name of the notification-capability]
+ Description: [an explanation of the purpose of the notification-
+ capability]
+ Syntax: [formal definition of allowed values and their syntax]
+ Permanent and readily available reference(s): [the RFC number(s) or
+ an URL of the document that defines this notification mechanism]
+ Contact information: [the name and email address of the technical
+ contact for information about this mechanism]
+
+ Below is the registration form for the "online" notification-
+ capability:
+
+ To: iana@iana.org
+ Subject: Registration of a new notification-capability parameter
+ Capability name: online
+ Description: Returns whether the entity identified by the
+ notification-uri parameter to the notify_method_capability test
+ can receive a notify notification immediately.
+ Syntax: Can contain one of three values: "yes", "no", and, "maybe".
+ Values MUST be in lowercase.
+ Permanent and readily available reference(s): This RFC
+ Contact information: The Sieve discussion list
+ <ietf-mta-filters@imc.org>
+
+10. Acknowledgements
+
+ Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus
+ Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E.
+ Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt
+ Gulbrandsen, Peter Saint-Andre, Sean Turner, Cullen Jennings, and
+ Pasi Eronen for help with this document.
+
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 15]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+11. References
+
+11.1. Normative References
+
+ [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
+ for Syntax Specifications: ABNF", STD 68,
+ RFC 5234, January 2008.
+
+ [Kwds] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [MailTo] Leiba, B. and M. Haardt, "Sieve Notification
+ Mechanism: mailto", RFC 5436, January 2009.
+
+ [Relational] Segmuller, W. and B. Leiba, "Sieve Extension:
+ Relational Tests", RFC 5231, January 2008.
+
+ [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve:
+ An Email Filtering Language", RFC 5228,
+ January 2008.
+
+ [URI] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic
+ Syntax", STD 66, RFC 3986, January 2005.
+
+ [Variables] Homme, K., "Sieve Extension: Variables", RFC 5229,
+ January 2008.
+
+11.2. Informative References
+
+ [ACAP] Newman, C. and J. Myers, "ACAP -- Application
+ Configuration Access Protocol", RFC 2244,
+ November 1997.
+
+ [IANA-GUIDELINES] Narten, T. and H. Alvestrand, "Guidelines for
+ Writing an IANA Considerations Section in RFCs",
+ BCP 26, RFC 5226, May 2008.
+
+ [TEL-URI] Schulzrinne, H., "The tel URI for Telephone
+ Numbers", RFC 3966, December 2004.
+
+ [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and
+ Presence Protocol (XMPP): Core", RFC 3920,
+ October 2004.
+
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 16]
+
+RFC 5435 Sieve Extension: Notifications January 2009
+
+
+ [XMPP-URI] Saint-Andre, P., "Internationalized Resource
+ Identifiers (IRIs) and Uniform Resource
+ Identifiers (URIs) for the Extensible Messaging
+ and Presence Protocol (XMPP)", RFC 5122,
+ February 2008.
+
+Authors' Addresses
+
+ Alexey Melnikov (editor)
+ Isode Limited
+ 5 Castle Business Village
+ 36 Station Road
+ Hampton, Middlesex TW12 2BX
+ UK
+
+ EMail: Alexey.Melnikov@isode.com
+
+
+ Barry Leiba (editor)
+ IBM T.J. Watson Research Center
+ 19 Skyline Drive
+ Hawthorne, NY 10532
+ US
+
+ Phone: +1 914 784 7941
+ EMail: leiba@watson.ibm.com
+
+
+ Wolfgang Segmuller
+ IBM T.J. Watson Research Center
+ 19 Skyline Drive
+ Hawthorne, NY 10532
+ US
+
+ Phone: +1 914 784 7408
+ EMail: werewolf@us.ibm.com
+
+
+ Tim Martin
+ Endless Crossword
+ 672 Haight st.
+ San Francisco, CA 94117
+ US
+
+ Phone: +1 510 260-4175
+ EMail: timmartin@alumni.cmu.edu
+
+
+
+
+
+Melnikov, et al. Standards Track [Page 17]
+
diff --git a/src/lib-sieve/plugins/enotify/ext-enotify.c b/src/lib-sieve/plugins/enotify/ext-enotify.c
index c0658e78056d17a313bf90add26345365ec84b65..2ed08298d2be95fdb88f13899c4de4c30a7c11d6 100644
--- a/src/lib-sieve/plugins/enotify/ext-enotify.c
+++ b/src/lib-sieve/plugins/enotify/ext-enotify.c
@@ -5,9 +5,9 @@
* ------------------
*
* Authors: Stephan Bosch
- * Specification: draft-ietf-sieve-notify-12.txt
- * Implementation: almost full, mailto method only
- * Status: under development
+ * Specification: RFC 5435
+ * Implementation: full
+ * Status: testing
*
*/
diff --git a/src/lib-sieve/plugins/enotify/ntfy-mailto.c b/src/lib-sieve/plugins/enotify/ntfy-mailto.c
index ecb5f7003466dc980ccf19af6754618fea5136d8..87262bf62cb17eb1d75be969ae94ff8a6dc0a083 100644
--- a/src/lib-sieve/plugins/enotify/ntfy-mailto.c
+++ b/src/lib-sieve/plugins/enotify/ntfy-mailto.c
@@ -5,9 +5,9 @@
* --------------------
*
* Authors: Stephan Bosch
- * Specification: draft-ietf-sieve-notify-mailto-10.txt
- * Implementation: almost full
- * Status: under development
+ * Specification: RFC 5436
+ * Implementation: full
+ * Status: testing
*
*/