summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6133.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6133.txt')
-rw-r--r--doc/rfc/rfc6133.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc6133.txt b/doc/rfc/rfc6133.txt
new file mode 100644
index 0000000..1314a3c
--- /dev/null
+++ b/doc/rfc/rfc6133.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. George
+Request for Comments: 6133 B. Leiba
+Category: Informational Huawei Technologies
+ISSN: 2070-1721 A. Melnikov
+ Isode Limited
+ July 2011
+
+
+ Sieve Email Filtering:
+ Use of Presence Information with Auto-Responder Functionality
+
+Abstract
+
+ This document describes how the Sieve email filtering language, along
+ with some extensions, can be used to create automatic replies to
+ incoming electronic mail messages based on the address book and
+ presence information of the recipient.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6133.
+
+Copyright Notice
+
+ Copyright (c) 2011 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. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+George, et al. Informational [Page 1]
+
+RFC 6133 Auto Response July 2011
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. How To Create Auto-Replies . . . . . . . . . . . . . . . . . . 3
+ 3. Example Use Cases for Auto-Replies . . . . . . . . . . . . . . 3
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8
+
+1. Introduction
+
+ This document describes how the Sieve email filtering language
+ [RFC5228], along with some extensions [RFC5230] [RFC5435] [RFC6134]
+ [RFC6132] [RFC6131], can be used to generate automatic replies to
+ incoming electronic mail messages based on the presence information
+ of the recipient. This can be used, for example, to inform the
+ sender that messages will not be answered immediately because the
+ recipient is busy or away.
+
+ The auto-reply message can additionally be based on information about
+ the sender from the recipient's address book, sub-lists therefrom, or
+ other lists available to the recipient, so that different senders
+ might get different responses. The recipient can create separate
+ rules for friends, family members, colleagues, and so on.
+
+ This can be used in mail filtering software, email-based information
+ services, and other automatic responder situations. There are many
+ programs currently in use that automatically respond to email. Some
+ of them send many useless or unwanted responses, or send responses to
+ inappropriate addresses. The mechanism described herein will help
+ avoid those problems (but see the discussion in Section 4).
+ Implementations need to take care of tracking previous messages
+ received from the same sender, and they will start or stop sending
+ responses as the presence status of the recipient changes.
+
+ An important note, though: users of any auto-reply mechanism should
+ really think about whether automatic replies are necessary, and at
+ what interval they make sense when they are. Email is not Instant
+ Messaging, and senders generally expect that replies might take a
+ while. Consider whether it's truly important to tell people that
+ you'll read their mail in an hour or so, or whether that can just be
+ taken as how email works. There are times when this makes sense, but
+ let's not use it to exacerbate information overload. Judicious use
+ of appropriate presence information might serve to mitigate these
+ issues.
+
+ Implementors, therefore, need to consider this with respect to the
+ features they expose to users, and the potential for inappropriate
+ use those features represent. The ability to create auto responders
+
+
+
+George, et al. Informational [Page 2]
+
+RFC 6133 Auto Response July 2011
+
+
+ might be hidden behind an "advanced" button, and users might be
+ warned of the consequences and advised of the considerations in the
+ previous paragraph.
+
+2. How To Create Auto-Replies
+
+ When an email message arrives, the Sieve script can use the
+ notify_method_capability of the Notify extension [RFC5435] to check
+ the recipient's presence information. The Notify-presence extension
+ [RFC6132] makes additional presence, such as "away" and "do not
+ disturb" status, available. The script can use the External-lists
+ extension [RFC6134] to look the sender up in the recipient's address
+ book or other list. If the information retrieved warrants an auto-
+ reply message, the message can then be composed based on that
+ information.
+
+ The Vacation extension [RFC5230] provides an easy way to send the
+ auto-reply message to the sender, as it automatically keeps track of
+ the automatic replies and attempts to avoid excessive messages and
+ mail loops. The Vacation-seconds extension [RFC6131] allows auto-
+ replies to be sent this way more frequently than once per day, when
+ that's appropriate. (Alternatively, the script can use the Notify
+ extension [RFC5435] to send a notification by a means other than
+ email.)
+
+ Personal and Group Responders can refuse to generate responses except
+ to known correspondents or addresses otherwise known to the
+ recipient. Such responders can also generate different kinds of
+ responses for "trusted" vs. "untrusted" addresses. This might be
+ useful, for instance, to avoid inappropriate disclosure of personal
+ or confidential information to arbitrary addresses.
+
+3. Example Use Cases for Auto-Replies
+
+ 1. In this example, we check that the envelope "from" is in the
+ recipient's address book [RFC6134] and that the recipient's
+ presence shows "extended away" [RFC6132]. If both of those are
+ true, the "vacation" action [RFC5230] is used to send an auto-
+ reply, making sure we don't reply to the same sender more than
+ once every half hour [RFC6131]. The variables extension
+ [RFC5229] is used to extract the value of the recipient's
+ natural-language presence status message, which will be used as
+ the response to the sender.
+
+
+
+
+
+
+
+
+George, et al. Informational [Page 3]
+
+RFC 6133 Auto Response July 2011
+
+
+ require ["envelope", "extlists", "enotify", "variables",
+ "vacation-seconds"];
+ if allof (
+ envelope :list "from" ":addrbook:default",
+ notify_method_capability "xmpp:me@example.com" "show" "xa"
+ ) {
+ # :matches "*" is used here to extract the value
+ if notify_method_capability :matches
+ "xmpp:myjid@example.com" "status" "*" {
+ set "resp_msg" "${1}";
+ } else {
+ set "resp_msg" "Away for a while, without access to email.";
+ }
+ vacation :handle "ext-away" :seconds 1800 "${resp_msg}";
+ }
+
+
+ 2. In the next example, we'll check for the recipient's personal
+ assistant, and give very detailed information about the
+ recipient's status to that sender. For other senders in the
+ "family" and "friends" lists, we'll also send an auto-reply.
+ Other senders will be considered less important, and don't need
+ auto-replies.
+
+ require ["envelope", "extlists", "enotify", "vacation-seconds"];
+
+ if envelope :is "from" "assistant@example.com"
+ {
+ if notify_method_capability "xmpp:me@example.com" "show" "away"
+ {
+ vacation :handle "away" :seconds 600
+ "I'm away for now, but I'll be back soon.";
+ }
+ elsif notify_method_capability "xmpp:me@example.com" "show" "dnd"
+ {
+ vacation :handle "dnd" :seconds 1800
+ "I'm not to be disturbed. I'll check mail later.";
+ }
+ elsif notify_method_capability "xmpp:me@example.com" "show" "xa"
+ {
+ vacation :handle "ext-away" :seconds 3600
+ "I'm away for a while, without access to email.";
+ }
+ elsif notify_method_capability "xmpp:me@example.com" "busy" "yes"
+ {
+ vacation :handle "busy" :seconds 1800
+ "I'm very busy, but might check email now and then.";
+ }
+
+
+
+George, et al. Informational [Page 4]
+
+RFC 6133 Auto Response July 2011
+
+
+ }
+ elsif envelope :list "from" [":addrbook:family",
+ ":addrbook:friends"]
+ {
+ if notify_method_capability "xmpp:me@example.com" "show"
+ ["away", "dnd", "xa"]
+ {
+ vacation :handle "away" :seconds 3600
+ "I'm not available to respond to email.";
+ }
+ }
+ else
+ { # We could respond as below, making it only once a day
+ # for less important senders. Better to just omit
+ # that, though (see the end of the Introduction section).
+ #
+ # vacation :handle "catchall" :days 1
+ # "I got your message, and might read it eventually.";
+ }
+
+
+ 3. For this example, if the sender is a work colleague and the
+ recipient is on extended away status, then reply with a message
+ giving alternative contact information. The message might also
+ include details about the reason for the absence, or other
+ personal or confidential information that shouldn't be shared
+ with senders who aren't associated with the recipient's company.
+
+
+ require ["envelope", "extlists", "enotify", "vacation"];
+
+ if envelope :list "from" ":addrbook:co-workers"
+ {
+ if notify_method_capability "xmpp:me@example.com" "show" "xa"
+ {
+ vacation :handle "bigtrip" :days 3
+ "I'm on an extended business trip to Texas for the Foo
+ project. Contact my backup, Susan <susan@example.com>,
+ or call my assistant on +1 666 555 1234 if you urgently
+ need to contact me.";
+ }
+ }
+
+
+ 4. This example is used to send an acknowledgment to every message
+ received. A :seconds value of zero is used to reply to every
+ message, with no removal of duplicates to the same sender. This
+ requires that the Sieve engine allow an interval of zero; if it
+
+
+
+George, et al. Informational [Page 5]
+
+RFC 6133 Auto Response July 2011
+
+
+ does not, and it imposes a minimum value, not every message will
+ receive an auto-reply.
+
+
+ require ["envelope", "extlists", "vacation-seconds"];
+
+ if not envelope :list "from" ":addrbook:staff"
+ {
+ vacation :handle "auto-resp" :seconds 0
+ "Your request has been received. A service
+ representative will contact you as soon as
+ possible, usually within one business day.";
+ }
+
+
+ 5. This example uses the same structure to automatically send a copy
+ of each incoming message to the recipient's backup, if the sender
+ is a customer contact or co-worker, or if the message's subject
+ includes the word "urgent".
+
+ require ["envelope", "extlists", "enotify"];
+
+ if anyof (
+ envelope :list "from" [":addrbook:customers",
+ ":addrbook:co-workers"],
+ header :contains "subject" "urgent"
+ ) {
+ if notify_method_capability "xmpp:me@example.com" "show" "xa"
+ {
+ redirect "susan@example.com"; # send a copy to my backup
+ keep; # also keep a copy for myself
+ }
+ }
+ }
+
+
+4. Security Considerations
+
+ See the Security Considerations sections of the following
+ specifications for discussion of security considerations not covered
+ here:
+
+ o Sieve base specification [RFC5228]
+
+ o Sieve Vacation extension [RFC5230]
+
+ o Vacation "Seconds" parameter [RFC6131]
+
+
+
+
+George, et al. Informational [Page 6]
+
+RFC 6133 Auto Response July 2011
+
+
+ o Sieve Externally Stored Lists extension [RFC6134]
+
+ o Sieve Notify extension [RFC5435] (and any applicable notification
+ methods)
+
+ This document describes how to set up a system that creates automatic
+ replies in an intelligent way. Despite the "intelligence", errors in
+ scripts can result in too many auto-reply messages, especially when
+ the reply interval is minimal (using the "notify" action, or the
+ "vacation" action with a small value for ":seconds").
+
+ Despite the "intelligence", too, errors in scripts can result in
+ private information getting to senders inappropriately. In example 3
+ in Section 3, for instance, if the :list test checks the wrong list,
+ or none at all, information about the recipient's business trip might
+ be sent to someone who has no need to know about it, and that
+ information should not have been sent.
+
+ Even without errors in scripts, a sender who recognizes that auto-
+ replies are dependent upon the recipient's presence can use that fact
+ to probe the presence information. One result of that can be that
+ the sender discerns changes in the recipient's presence that the
+ sender would normally not be allowed to see, making this an
+ unintentional back door into the user's presence information.
+ Another result is that this can create a "covert channel", allowing
+ the recipient to send information to a sender by changing his
+ presence information, his address book, and/or his Sieve script
+ (though in this regard, the exposure is comparable to any other case
+ of shared presence information).
+
+ An auto responder can cause leaks of other pieces of information,
+ including potentially providing the ability to attack cryptographic
+ keying material. For example, using the time it takes to perform a
+ cryptographic operation, an attacker may obtain information about the
+ secret key. An auto responder that doesn't take timing into account
+ could accidentally leak this kind of information.
+
+ Moreover, if an auto responder script directly returns the results of
+ a cryptographic operation, that could also provide an attack vector.
+ For example, if a script returns the results of a decryption
+ operation, an attacker can send an arbitrarily encrypted message and
+ use the results as a chosen cyphertext attack to decode the
+ encryption key. Authors of scripts should be careful about what
+ information they return to senders.
+
+
+
+
+
+
+
+George, et al. Informational [Page 7]
+
+RFC 6133 Auto Response July 2011
+
+
+5. Normative References
+
+ [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
+ Language", RFC 5228, January 2008.
+
+ [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
+ RFC 5229, January 2008.
+
+ [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering:
+ Vacation Extension", RFC 5230, January 2008.
+
+ [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
+ "Sieve Email Filtering: Extension for Notifications",
+ RFC 5435, January 2009.
+
+ [RFC6131] George, R. and B. Leiba, "Sieve Vacation Extension:
+ "Seconds" Parameter", RFC 6131, July 2011.
+
+ [RFC6132] George, R. and B. Leiba, "Sieve Notification Using
+ Presence Information", RFC 6132, July 2011.
+
+ [RFC6134] Melnikov, A. and B. Leiba, "Sieve Extension: Externally
+ Stored Lists", RFC 6134, July 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al. Informational [Page 8]
+
+RFC 6133 Auto Response July 2011
+
+
+Authors' Addresses
+
+ Robins George
+ Huawei Technologies
+ Bangalore, Karnataka 560071
+ India
+
+ Phone: +91-080-41117676
+ EMail: robinsgv@gmail.com
+
+
+ Barry Leiba
+ Huawei Technologies
+
+ Phone: +1 646 827 0648
+ EMail: barryleiba@computer.org
+ URI: http://internetmessagingtechnology.org/
+
+
+ Alexey Melnikov
+ Isode Limited
+ 5 Castle Business Village, 36 Station Road
+ Hampton, Middlesex TW12 2BX
+ UK
+
+ EMail: Alexey.Melnikov@isode.com
+ URI: http://www.melnikov.ca/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George, et al. Informational [Page 9]
+