Skip to main content

Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality
draft-ietf-sieve-autoreply-04

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6133.
Authors Barry Leiba , Robins George , Alexey Melnikov
Last updated 2015-10-14 (Latest revision 2011-01-10)
Replaces draft-george-sieve-autoreply
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 6133 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Peter Saint-Andre
IESG note ** No value found for 'doc.notedoc.note' **
Send notices to (None)
draft-ietf-sieve-autoreply-04
Sieve working group                                            R. George
Internet-Draft                                                  B. Leiba
Intended status: Informational                       Huawei Technologies
Expires: July 14, 2011                                       A. Melnikov
                                                           Isode Limited
                                                        January 10, 2011

 Sieve Email Filtering: Use of Presence Information with Auto Responder
                             functionality
                     draft-ietf-sieve-autoreply-04

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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on July 14, 2011.

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

George, et al.            Expires July 14, 2011                 [Page 1]
Internet-Draft                Auto Response                 January 2011

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  How To Create Auto Replies . . . . . . . . . . . . . . . . . .  4

   3.  Example Use Cases for Auto Replies . . . . . . . . . . . . . .  4

   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9

   6.  Normative References . . . . . . . . . . . . . . . . . . . . .  9

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10

George, et al.            Expires July 14, 2011                 [Page 2]
Internet-Draft                Auto Response                 January 2011

1.  Introduction

   This document describes how the Sieve email filtering language
   [RFC5228], along with some extensions [RFC5230] [RFC5435]
   [I-D.ietf-sieve-external-lists] [I-D.ietf-sieve-notify-presence]
   [I-D.ietf-sieve-vacation-seconds] 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 to
   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
   might be hidden behind an "advanced" button, and users might be
   warned of the consequences, and advised of the considerations in the
   previous paragraph.

George, et al.            Expires July 14, 2011                 [Page 3]
Internet-Draft                Auto Response                 January 2011

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
   [I-D.ietf-sieve-notify-presence] makes additional presence, such as
   "away" and "do not disturb" status, available.  The script can use
   the External-lists extension [I-D.ietf-sieve-external-lists] 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
   [I-D.ietf-sieve-vacation-seconds] 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] and
   it can use that 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 [I-D.ietf-sieve-external-lists] and that
       the recipient's presence shows "extended
       away".[I-D.ietf-sieve-notify-presence] 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.[I-D.ietf-sieve-vacation-seconds] 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.            Expires July 14, 2011                 [Page 4]
Internet-Draft                Auto Response                 January 2011

   require ["envelope", "extlists", "enotify", "variables",
            "vacation-seconds"];
   if allof (
       envelope :list "from" "tag:example.com,2009-05-28:AddrBook",
       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.

George, et al.            Expires July 14, 2011                 [Page 5]
Internet-Draft                Auto Response                 January 2011

   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.";
         }
     }
   elsif envelope :list "from" ["tag:example.com,2009-05-28:family",
                                "tag:example.com,2009-05-28: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.";
     }

George, et al.            Expires July 14, 2011                 [Page 6]
Internet-Draft                Auto Response                 January 2011

   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" "tag:example.com,2009-05-28: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
       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" "tag:example.com,2009-05-28: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.";
     }

George, et al.            Expires July 14, 2011                 [Page 7]
Internet-Draft                Auto Response                 January 2011

   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" ["tag:example.com,2009-05-28:customers",
                              "tag:example.com,2009-05-28: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:
   Sieve base specification [RFC5228]
   Sieve Vacation extension [RFC5230]
   Vacation "Seconds" parameter [I-D.ietf-sieve-vacation-seconds]
   Sieve Externally Stored Lists extension
   [I-D.ietf-sieve-external-lists]
   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

George, et al.            Expires July 14, 2011                 [Page 8]
Internet-Draft                Auto Response                 January 2011

   be sent to someone who has no need to know about it, and shouldn't.

   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 autoresponder 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 an
   cryptographic operation, an attacker may obtain information about the
   secret key.  An autoresponder that doesn't take timing into account
   could accidentally leak this kind of information.

   Moreover, if an autoresponder 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 in what
   information they return to senders.

5.  IANA Considerations

   There are no IANA actions required by this document.

6.  Normative References

   [I-D.ietf-sieve-external-lists]
              Melnikov, A. and B. Leiba, "Sieve Extension: Externally
              Stored Lists", draft-ietf-sieve-external-lists-02 (work in
              progress), May 2010.

   [I-D.ietf-sieve-notify-presence]
              George, R. and B. Leiba, "Sieve Notification Using
              Presence Information", draft-ietf-sieve-notify-presence-01
              (work in progress), October 2010.

   [I-D.ietf-sieve-vacation-seconds]

George, et al.            Expires July 14, 2011                 [Page 9]
Internet-Draft                Auto Response                 January 2011

              George, R. and B. Leiba, "Sieve Vacation Extension:
              "Seconds" parameter", draft-ietf-sieve-vacation-seconds-01
              (work in progress), October 2010.

   [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.

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.            Expires July 14, 2011                [Page 10]