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]