SIEVE                                                          R. George
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                             A. Melnikov
Expires: December 27, 2009                                 Isode Limited
                                                           June 25, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 December 27, 2009.

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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document describes how Sieve email filtering language can be



George & Melnikov       Expires December 27, 2009               [Page 1]


Internet-Draft                Auto Response                    June 2009


   used for automatically responding to an incoming electronic mail
   messages based on the presence information of the user.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology Used in This Document . . . . . . . . . . . . . . . 3
   3.  Example use cases of Auto Replies . . . . . . . . . . . . . . . 3
   4.  Sieve Extensions  . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  When (not) to Send Automatic Reply  . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9


































George & Melnikov       Expires December 27, 2009               [Page 2]


Internet-Draft                Auto Response                    June 2009


1.  Introduction

   This document describes how extension to the Sieve language defined
   in [RFC5228] can be used for immediate email notification messages
   based on the presence information [RFC3856] to a particular
   recipient, for example to convey that an email message will not be
   answered immediately.

   Here the purpose is to create a response message with necessary
   details and to send correspondents a notification.  The notification
   message is based on the presence information of the user and sender's
   information which has been set in the receiver's address book that
   the user is away (away/busy/offline) from the mailbox for a period of
   time.  This way each and every sender may get a different and
   personalized response based on the receiver's statistics.

   Implementation should take care of tracking previous messages
   received from the same sender and should be able to send the response
   if the previous status of the user has changed.

   This can be used in mail filtering software, email-based information
   services, and other automatic responders.  Many programs which
   automatically respond to email are currently in use.  Some of them
   send significant numbers of useless or unwanted response and
   responses sent to inappropriate addresses.

   The auto responders can be Service Responders, Personal Responders,
   and Group Responders.  When a mail comes, analyze and classify the
   contents based on the presence information, and then issues a
   response which is dependent on that classification.  The user can
   create separate rules for the friends, family members, colleagues
   etc.

   Behavior for a responder varies from one class to another.  The
   response may vary based on the different presence information of the
   user and the sender information.


2.  Terminology Used in This Document

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


3.  Example use cases of Auto Replies

   When a mail comes, the presence information, instead of scanning



George & Melnikov       Expires December 27, 2009               [Page 3]


Internet-Draft                Auto Response                    June 2009


   thousands of users, directly ping and identify the presence
   information of the receiver.  Then checks whether a response message
   has to be sent by identifying the receiver's presence information and
   sender's information in receiver's contact list which has been set
   previously.  Then it sends out a response message to the sender if
   the given criterion requires a reply, else sending no response
   message.

   Personal and Group Responders can refuse to generate responses except
   to known correspondents or addresses of otherwise "trusted"
   individuals.  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 the arbitrary addresses.

   For example,


  Here is a simple use of autoreply.

  require ["extlists", "enotify", "vacation"];

  # Check if the sender is in "mylist" addressbook
  if allof (envelope :list "from" "mylist",
      notify_method_capability
             "xmpp:myjid@example.com"
             "Status"
             "Away") {
  vacation :handle "ran-away" "Hello. I'm out and can't meet for lunch";
  }


   In the same way each user can set some rules based on their presence
   information to tell the mail server whether or not a response to be
   sent and what should be the content of the response message.  However
   the user can predefine different rules according to different sender,
   based on their presence information.

   The presence information can be obtained by using existing
   techniques, for example the ones defined in the [RFC3265].  If the
   mail system detects that the user's state has been changed to online,
   then the mail system can automatically stop sending autoreply to the
   correspondent.

   A more complicated example can look like this: If the sender is in
   the address book and the presence status of the receiver is 'AWAY'
   then reply with a response message msg1 (The message may contain some
   details about owner's vacation and returning date as well, and some



George & Melnikov       Expires December 27, 2009               [Page 4]


Internet-Draft                Auto Response                    June 2009


   other relevant information).



   require ["extlists", "enotify", "vacation"];

   # Check if the sender is in "mylist" addressbook
   if allof (envelope :list "from" "mylist",
       notify_method_capability
              "xmpp:myjid@example.com"
              "Status"
              "Away") {
   vacation :handle "ran-away"
   "Hello. I'm out and can't meet for lunch";
   }


   If the sender is not in the address book and the presence status of
   the receiver is 'BUSY' then reply with a response message msg2 (Here
   the message can be empty or very primitive information that the owner
   wishes to share)



   require ["extlists", "enotify", "vacation"];

     # Check if the sender is in "mylist" addressbook
     if allof (not envelope :list "from" "mylist",
               notify_method_capability
                      "xmpp:myjid@example.com"
                      "Status"
                      "Busy") {
         vacation :handle "ran-away" "I don't have access to my mail
         at the moment. Sorry for the delay.";
   }


   If the sender is a family member or a friend and the presence status
   of the receiver is 'BUSY' then reply with a response message msg3
   (These quick response message may include personal and private
   information).










George & Melnikov       Expires December 27, 2009               [Page 5]


Internet-Draft                Auto Response                    June 2009


   require ["extlists", "enotify", "vacation"];

   if allof (envelope :list "from" ["family", "friends"],
       notify_method_capability
              "xmpp:myjid@example.com"
              "Status"
              "Busy") {
   vacation :handle "ran-away" "Hello friend. I am swamped at work
   with my project, so I can't go out for beer tonight".;
   }


   If the sender is a colleague and the presence status of the receiver
   is 'OFFLINE' then reply with a msg4 (Those message may contain the
   details about owner's business trip, contact information while on
   travel, other confidential information about the work, etc).



   require ["extlists", "enotify", "vacation"];

   if allof (envelope :list "from" "work",
       notify_method_capability
              "xmpp:myjid@example.com"
              "online"
              "no") {
   vacation :handle "ran-away" "If you need to get information
   on project Foo please contact Stacy at +123456789";
   }


   Another example: In organizations where time critical handling of
   certain messages is required, there is a mechanism to forward an
   incoming mail to a particular address if it is not answered for a
   particular period of time, since immediate response to these mails
   are more important.  However, Auto Reply mechanism can be used to
   handle such scenarios.  When a mail arrives and the user is not
   available (offline/busy/away) the Auto Reply can play a major role to
   take necessary decisions, either send response, not send response or
   perform some other action.  And can decide what response should be
   send and what action(s) to be performed.










George & Melnikov       Expires December 27, 2009               [Page 6]


Internet-Draft                Auto Response                    June 2009


   require ["enotify"];

   if anyof (notify_method_capability
              "xmpp:myjid@example.com"
              "online"
              "no",
       notify_method_capability
              "xmpp:myjid@example.com"
              "Status"
              "Away",
       notify_method_capability
              "xmpp:myjid@example.com"
              "Status"
              "Busy") {
   redirect "backup@example.com";
   }


   It's not a good practice to share the private information with
   everybody, but it might be necessary for details to reach the
   intended sender when user is on vacation or away from the mailbox.
   This can be achieved if the user can personalize mailbox by the above
   mentioned method.  At the same time user can modify and update the
   vacation responses if user gets a chance to access the mailbox.  The
   updated information may include, the new contact number, and address
   for communication, business updates, health status (if someone is
   worried about) etc.  Thus the proposed method could ensure that the
   each and every sender will get an accurate, intended and personalized
   response from the receiver.


4.  Sieve Extensions

   Currently this document defines no extensions to Sieve.  However,
   some extensions might be necessary to make examples shown above
   correct/complete:

   There may be requirements, where user would like to possibly send
   multiple autoreplies to the same sender in a day based on the
   presence information changes.  In this scenario, we need to consider
   something more granular than the ":days" parameter to the "vacation"
   action.


5.  When (not) to Send Automatic Reply

   [[Open Issue: This section looks fairly normative.  Might need to
   reword this based on final publication status of this document.]]  An



George & Melnikov       Expires December 27, 2009               [Page 7]


Internet-Draft                Auto Response                    June 2009


   automatic responder MUST NOT blindly send a response for every
   message received.  Implementations MAY refuse to send an autoresponse
   to a message that contains any header or content that makes it appear
   that a response would not be appropriate.  In practice there are
   always reasons to refuse respond to some kinds of received messages,
   e.g., for loop prevention, to avoid responding to "spam" or viruses,
   to avoid being used as a means to launder or amplify abusive
   messages, to avoid inappropriately revealing personal information
   about the recipient (e.g., to avoid an automatic indication that a
   recipient has not read his/her mail recently), and to prevent attacks
   against the responder.  The criteria for deciding whether to respond
   will differ from one responder to another, according to the
   responder's purpose.  In general, care should be taken to avoid
   sending useless or redundant responses.

   Implementations MUST have a list of addresses that "autoreply" MUST
   NOT send mail to.  However, the contents of this list are
   implementation defined.


6.  Security Considerations

   TBD


7.  IANA Considerations

   [[TBD: The "Status" notification capability needs to be registered
   with IANA.]]


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5228]  Guenther, P. and T. Showalter, "Sieve: An Email Filtering
              Language", RFC 5228, 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.




George & Melnikov       Expires December 27, 2009               [Page 8]


Internet-Draft                Auto Response                    June 2009


8.2.  Informative References

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

   [RFC3834]  Moore, K., "Recommendations for Automatic Responses to
              Electronic Mail", RFC 3834, August 2004.

   [RFC3856]  Rosenberg, J., "A Presence Event Package for the Session
              Initiation Protocol (SIP)", RFC 3856, August 2004.


Authors' Addresses

   Robins George
   Huawei Technologies
   Huawei Base, Bantian, Longgang District
   Shenzhen, Guangdong  518129
   P. R. China

   Phone: +86-755-28788314
   Email: robinsg@huawei.com


   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 & Melnikov       Expires December 27, 2009               [Page 9]