draft-ietf-sieve-autoreply-00.txt   draft-ietf-sieve-autoreply-01.txt 
Sieve working group R. George Sieve working group R. George
Internet-Draft B. Leiba Internet-Draft
Intended status: Informational Huawei Technologies Intended status: Informational B. Leiba
Expires: December 25, 2010 A. Melnikov Expires: April 15, 2011 Huawei Technologies
A. Melnikov
Isode Limited Isode Limited
June 23, 2010 October 12, 2010
Sieve Email Filtering: Use of Presence Information with Auto Responder Sieve Email Filtering: Use of Presence Information with Auto Responder
functionality functionality
draft-ietf-sieve-autoreply-00 draft-ietf-sieve-autoreply-01
Abstract Abstract
This document describes how the Sieve email filtering language, along This document describes how the Sieve email filtering language, along
with some extensions, can be used to create automatic replies to with some extensions, can be used to create automatic replies to
incoming electronic mail messages based on the address book and incoming electronic mail messages based on the address book and
presence information of the recipient. presence information of the recipient.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2010. This Internet-Draft will expire on April 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 22
2. How To Create Auto Replies . . . . . . . . . . . . . . . . . . 3 2. How To Create Auto Replies . . . . . . . . . . . . . . . . . . 3
3. Example Use Cases for Auto Replies . . . . . . . . . . . . . . 4 3. Example Use Cases for Auto Replies . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
This document describes how the Sieve email filtering language This document describes how the Sieve email filtering language
[RFC5228], along with some extensions [RFC5230] [RFC5435] [RFC5228], along with some extensions [RFC5230] [RFC5435]
[I-D.ietf-sieve-external-lists] [I-D.ietf-sieve-notify-presence] [I-D.ietf-sieve-external-lists] [I-D.ietf-sieve-notify-presence]
[I-D.ietf-sieve-vacation-seconds] can be used to generate automatic [I-D.ietf-sieve-vacation-seconds] can be used to generate automatic
replies to incoming electronic mail messages based on the presence replies to incoming electronic mail messages based on the presence
information of the recipient. This can be used, for example, to information of the recipient. This can be used, for example, to
inform the sender that messages will not be answered immediately inform the sender that messages will not be answered immediately
skipping to change at page 3, line 32 skipping to change at page 3, line 32
This can be used in mail filtering software, email-based information This can be used in mail filtering software, email-based information
services, and other automatic responder situations. There are many services, and other automatic responder situations. There are many
programs currently in use that automatically respond to email. Some programs currently in use that automatically respond to email. Some
of them send many useless or unwanted responses, or send responses to of them send many useless or unwanted responses, or send responses to
inappropriate addresses. The mechanism described herein will help to inappropriate addresses. The mechanism described herein will help to
avoid those problems (but see the discussion in Section 4). avoid those problems (but see the discussion in Section 4).
Implementations need to take care of tracking previous messages Implementations need to take care of tracking previous messages
received from the same sender and they will start or stop sending received from the same sender and they will start or stop sending
responses as the presence status of the recipient changes. responses as the presence status of the recipient changes.
[[Barry's question: One thing this makes me think of is whether we
want the ability to extract information from an external list. For
instance, it'd be nice to be able to go into the recipient's address
book for the sender's real name, or for a personalized message for
the sender. Not all lists will support this; should it be possible,
for lists that do?]]
2. How To Create Auto Replies 2. How To Create Auto Replies
When an email message arrives, the Sieve script can use the When an email message arrives, the Sieve script can use the
notify_method_capability of the Notify extension [RFC5435] to check notify_method_capability of the Notify extension [RFC5435] to check
the recipient's presence information. The Notify-presence extension the recipient's presence information. The Notify-presence extension
[I-D.ietf-sieve-notify-presence] makes additional presence, such as [I-D.ietf-sieve-notify-presence] makes additional presence, such as
"away" and "do not disturb" status, available. The script can use "away" and "do not disturb" status, available. The script can use
the External-lists extension [I-D.ietf-sieve-external-lists] to look 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 the sender up in the recipient's address book or other list. If the
information retrieved warrants an auto-reply message, the message can information retrieved warrants an auto-reply message, the message can
skipping to change at page 4, line 24 skipping to change at page 4, line 16
recipient. Such responders can also generate different kinds of recipient. Such responders can also generate different kinds of
responses for "trusted" vs "untrusted" addresses. This might be responses for "trusted" vs "untrusted" addresses. This might be
useful, for instance, to avoid inappropriate disclosure of personal useful, for instance, to avoid inappropriate disclosure of personal
or confidential information to arbitrary addresses. or confidential information to arbitrary addresses.
3. Example Use Cases for Auto Replies 3. Example Use Cases for Auto Replies
1. In this example, we check that the envelope "from" is in the 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 recipient's address book [I-D.ietf-sieve-external-lists] and that
the recipient's presence shows "extended the recipient's presence shows "extended
away".[I-D.ietf-sieve-notify-presence] If both of those are away".[I-D.ietf-sieve-notify-presence] If both of those are true,
true, the "vacation" action [RFC5230] is used to send an auto- the "vacation" action [RFC5230] is used to send an auto-reply,
reply, making sure we don't reply to the same sender more than making sure we don't reply to the same sender more than once
once every half hour.[I-D.ietf-sieve-vacation-seconds] The every half hour.[I-D.ietf-sieve-vacation-seconds] The variables
variables extension [RFC5229] is used to extract the value of the extension [RFC5229] is used to extract the value of the
recipient's natural-language presence status message, which will recipient's natural-language presence status message, which will
be used in the response to the sender. be used in the response to the sender.
require ["extlists", "enotify", "variables", "vacation-seconds"]; require ["extlists", "enotify", "variables", "vacation-seconds"];
if allof ( if allof (
envelope :list "from" "tag:example.com,2009-05-28:AddrBook", envelope :list "from" "tag:example.com,2009-05-28:AddrBook",
notify_method_capability "xmpp:me@example.com" "show" "xa" notify_method_capability "xmpp:me@example.com" "show" "xa"
) { ) {
# :matches "*" is used here to extract the value # :matches "*" is used here to extract the value
if notify_method_capability :matches if notify_method_capability :matches
skipping to change at page 7, line 41 skipping to change at page 7, line 36
This document describes how to set up a system that creates automatic This document describes how to set up a system that creates automatic
replies in an intelligent way. Despite the "intelligence", errors in replies in an intelligent way. Despite the "intelligence", errors in
scripts can result in too many auto-reply messages, especially when scripts can result in too many auto-reply messages, especially when
the reply interval is minimal (using the "notify" action, or the the reply interval is minimal (using the "notify" action, or the
"vacation" action with a small value for ":seconds"). "vacation" action with a small value for ":seconds").
Despite the "intelligence", too, errors in scripts can result in Despite the "intelligence", too, errors in scripts can result in
private information getting to senders inappropriately. In example 3 private information getting to senders inappropriately. In example 3
in Section 3, for instance, if the :list test checks the wrong list, 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 or none at all, information about the recipient's business trip might
be send to someone who has no need to know about it, and shouldn't. 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- Even without errors in scripts, a sender who recognizes that auto-
replies are dependent upon the recipient's presence can use that fact replies are dependent upon the recipient's presence can use that fact
to probe the presence information. One result of that can be that to probe the presence information. One result of that can be that
the sender discerns changes in the recipient's presence that the the sender discerns changes in the recipient's presence that the
sender would normally not be allowed to see, making this an sender would normally not be allowed to see, making this an
unintentional back door into the user's presence information. unintentional back door into the user's presence information.
Another result is that this can create a "covert channel", allowing Another result is that this can create a "covert channel", allowing
the recipient to send information to a sender by changing his the recipient to send information to a sender by changing his
presence information, his address book, and/or his Sieve script presence information, his address book, and/or his Sieve script
skipping to change at page 8, line 26 skipping to change at page 8, line 20
mail in an hour or so, or whether that can just be taken as how email 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 works. There are times when this makes sense, but let's not use it
to exacerbate information overload. to exacerbate information overload.
5. IANA Considerations 5. IANA Considerations
There are no IANA actions required by this document. There are no IANA actions required by this document.
6. Normative References 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] [I-D.ietf-sieve-notify-presence]
George, R. and B. Leiba, "Sieve Notification Using George, R. and B. Leiba, "Sieve Notification Using
Presence Information", Presence Information", draft-ietf-sieve-notify-presence-00
draft-ietf-sieve-notify-presence-00 (work in progress), (work in progress), June 2010.
June 2010.
[I-D.ietf-sieve-vacation-seconds] [I-D.ietf-sieve-vacation-seconds]
George, R. and B. Leiba, "Sieve Vacation Extension: George, R. and B. Leiba, "Sieve Vacation Extension:
"Seconds" parameter", draft-ietf-sieve-vacation-seconds-00 "Seconds" parameter", draft-ietf-sieve-vacation-seconds-00
(work in progress), June 2010. (work in progress), June 2010.
[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.
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008. Language", RFC 5228, January 2008.
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
RFC 5229, January 2008. RFC 5229, January 2008.
[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering:
Vacation Extension", RFC 5230, January 2008. Vacation Extension", RFC 5230, January 2008.
[RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
"Sieve Email Filtering: Extension for Notifications", "Sieve Email Filtering: Extension for Notifications",
RFC 5435, January 2009. RFC 5435, January 2009.
Authors' Addresses Authors' Addresses
Robins George Robins George
Huawei Technologies
Huawei Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
P. R. China
Phone: +86-755-28788314 Email: robinsgv@gmail.com
Email: robinsg@huawei.com
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
 End of changes. 13 change blocks. 
34 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/