Sieve Notification Mechanism: mailto
RFC 5436
Document | Type |
RFC - Proposed Standard
(January 2009; No errata)
Updates RFC 3834
|
|
---|---|---|---|
Authors | Barry Leiba , Michael Haardt | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5436 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Lisa Dusseault | ||
Send notices to | (None) |
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. 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 This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. Leiba & Haardt Standards Track [Page 1] RFC 5436 Sieve Notification Mechanism: mailto January 2009 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 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 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 The mailto mechanism results in the sending of a new email message (a "notification message") to notify a recipient about a "triggering message". 2.1. Notify Parameter "method" The mailto notification mechanism uses standard mailto URIs as specified in [mailto]. mailto URIs may contain header fields consisting of a header name and value. These header fields are called "URI headers" to distinguish them from "message headers". 2.2. Test notify_method_capability The notify_method_capability test for "online" may return "yes" or "no" only if the Sieve processor can determine with certainty whether or not the recipients of the notification message are online and logged in. Otherwise, the test returns "maybe" for this notification method. 2.3. Notify Tag ":from" The ":from" tag overrides the default sender of the notification message. "Sender", here, refers to the value used in the [RFC5322]Show full document text