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]