idnits 2.17.1 draft-ietf-sieve-autoreply-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2010) is 4945 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-sieve-external-lists-02 == Outdated reference: A later version (-04) exists of draft-ietf-sieve-notify-presence-01 == Outdated reference: A later version (-03) exists of draft-ietf-sieve-vacation-seconds-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve working group R. George 3 Internet-Draft 4 Intended status: Informational B. Leiba 5 Expires: April 15, 2011 Huawei Technologies 6 A. Melnikov 7 Isode Limited 8 October 12, 2010 10 Sieve Email Filtering: Use of Presence Information with Auto Responder 11 functionality 12 draft-ietf-sieve-autoreply-02 14 Abstract 16 This document describes how the Sieve email filtering language, along 17 with some extensions, can be used to create automatic replies to 18 incoming electronic mail messages based on the address book and 19 presence information of the recipient. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 15, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. How To Create Auto Replies . . . . . . . . . . . . . . . . . . 3 59 3. Example Use Cases for Auto Replies . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 This document describes how the Sieve email filtering language 72 [RFC5228], along with some extensions [RFC5230] [RFC5435] 73 [I-D.ietf-sieve-external-lists] [I-D.ietf-sieve-notify-presence] 74 [I-D.ietf-sieve-vacation-seconds] can be used to generate automatic 75 replies to incoming electronic mail messages based on the presence 76 information of the recipient. This can be used, for example, to 77 inform the sender that messages will not be answered immediately 78 because the recipient is busy or away. 80 The auto-reply message can additionally be based on information about 81 the sender from the recipient's address book, sub-lists therefrom, or 82 other lists available to the recipient, so that different senders 83 might get different responses. The recipient can create separate 84 rules for friends, family members, colleagues, and so on. 86 This can be used in mail filtering software, email-based information 87 services, and other automatic responder situations. There are many 88 programs currently in use that automatically respond to email. Some 89 of them send many useless or unwanted responses, or send responses to 90 inappropriate addresses. The mechanism described herein will help to 91 avoid those problems (but see the discussion in Section 4). 92 Implementations need to take care of tracking previous messages 93 received from the same sender and they will start or stop sending 94 responses as the presence status of the recipient changes. 96 2. How To Create Auto Replies 98 When an email message arrives, the Sieve script can use the 99 notify_method_capability of the Notify extension [RFC5435] to check 100 the recipient's presence information. The Notify-presence extension 101 [I-D.ietf-sieve-notify-presence] makes additional presence, such as 102 "away" and "do not disturb" status, available. The script can use 103 the External-lists extension [I-D.ietf-sieve-external-lists] to look 104 the sender up in the recipient's address book or other list. If the 105 information retrieved warrants an auto-reply message, the message can 106 then be composed based on that information. 108 The Vacation extension [RFC5230] provides an easy way to send the 109 auto-reply message to the sender, as it automatically keeps track of 110 the automatic replies and attempts to avoid excessive messages and 111 mail loops. The Vacation-seconds extension 112 [I-D.ietf-sieve-vacation-seconds] allows auto-replies to be sent this 113 way more frequently than once per day, when that's appropriate. 114 (Alternatively, the script can use the Notify extension,[RFC5435] and 115 it can use that to send a notification by a means other than email.) 116 Personal and Group Responders can refuse to generate responses except 117 to known correspondents or addresses otherwise known to the 118 recipient. Such responders can also generate different kinds of 119 responses for "trusted" vs "untrusted" addresses. This might be 120 useful, for instance, to avoid inappropriate disclosure of personal 121 or confidential information to arbitrary addresses. 123 3. Example Use Cases for Auto Replies 125 1. In this example, we check that the envelope "from" is in the 126 recipient's address book [I-D.ietf-sieve-external-lists] and that 127 the recipient's presence shows "extended 128 away".[I-D.ietf-sieve-notify-presence] If both of those are true, 129 the "vacation" action [RFC5230] is used to send an auto-reply, 130 making sure we don't reply to the same sender more than once 131 every half hour.[I-D.ietf-sieve-vacation-seconds] The variables 132 extension [RFC5229] is used to extract the value of the 133 recipient's natural-language presence status message, which will 134 be used as the response to the sender. 136 require ["envelope", "extlists", "enotify", "variables", 137 "vacation-seconds"]; 138 if allof ( 139 envelope :list "from" "tag:example.com,2009-05-28:AddrBook", 140 notify_method_capability "xmpp:me@example.com" "show" "xa" 141 ) { 142 # :matches "*" is used here to extract the value 143 if notify_method_capability :matches 144 "xmpp:myjid@example.com" "status" "*" { 145 set "resp_msg" "${1}"; 146 } else { 147 set "resp_msg" "Away for a while, without access to email."; 148 } 149 vacation :handle "ext-away" :seconds 1800 "${resp_msg}"; 150 } 152 2. In the next example, we'll check several lists or sublists, auto- 153 replying to everyone, but sending more detail about the 154 recipient's status to senders who are found in the recipient's 155 address book, and still more detail to those in the "family" and 156 "friends" lists. 158 require ["envelope", "extlists", "enotify", "vacation-seconds"]; 160 if envelope :list "from" ["tag:example.com,2009-05-28:family", 161 "tag:example.com,2009-05-28:friends"] 162 { 163 if notify_method_capability "xmpp:me@example.com" "show" "away" 164 { 165 vacation :handle "away" :seconds 600 166 "I'm away for now, but I'll be back soon."; 167 } 168 elsif notify_method_capability "xmpp:me@example.com" "show" "dnd" 169 { 170 vacation :handle "dnd" :seconds 1800 171 "I'm not to be disturbed. I'll check mail later."; 172 } 173 elsif notify_method_capability "xmpp:me@example.com" "show" "xa" 174 { 175 vacation :handle "ext-away" :seconds 3600 176 "I'm away for a while, without access to email."; 177 } 178 elsif notify_method_capability "xmpp:me@example.com" "busy" "yes" 179 { 180 vacation :handle "busy" :seconds 1800 181 "I'm very busy, but might check email now and then."; 182 } 183 } 184 elsif envelope :list "from" "tag:example.com,2009-05-28:AddrBook" 185 { 186 if notify_method_capability "xmpp:me@example.com" "show" 187 ["away", "dnd", "xa"] 188 { 189 vacation :handle "away" :seconds 3600 190 "I'm not available to respond to email."; 191 } 192 } 193 else # the sender is not in the address book 194 { 195 vacation :handle "catchall" :days 1 196 "I got your message, and might read it eventually."; 197 } 199 3. For this example, if the sender is a work colleague and the 200 recipient is on extended away status, then reply with a message 201 giving alternative contact information. The message might also 202 include details about the reason for the absence, or other 203 personal or confidential information that shouldn't be shared 204 with senders who aren't associated with the recipient's company. 206 require ["envelope", "extlists", "enotify", "vacation"]; 208 if envelope :list "from" "tag:example.com,2009-05-28:co-workers" 209 { 210 if notify_method_capability "xmpp:me@example.com" "show" "xa" 211 { 212 vacation :handle "bigtrip" :days 3 213 "I'm on an extended business trip to Texas for the Foo 214 project. Contact my backup, Susan , 215 or call my assistant on +1 666 555 1234 if you urgently 216 need to contact me."; 217 } 218 } 220 4. This example is used to send an acknowledgment to every message 221 received. A :seconds value of zero is used to reply to every 222 message, with no removal of duplicates to the same sender. This 223 requires that the Sieve engine allow an interval of zero; if it 224 does not, and it imposes a minimum value, not every message will 225 receive an auto-reply. 227 require ["envelope", "extlists", "vacation-seconds"]; 229 if not envelope :list "from" "tag:example.com,2009-05-28:staff" 230 { 231 vacation :handle "auto-resp" :seconds 0 232 "Your request has been received. A service 233 representative will contact you as soon as 234 possible, usually within one business day."; 235 } 237 5. This example uses the same structure to automatically send a copy 238 of each incoming message to the recipient's backup, if the sender 239 is a customer contact or co-worker, or if the message's subject 240 includes the word "urgent". 242 require ["envelope", "extlists", "enotify"]; 244 if anyof ( 245 envelope :list "from" ["tag:example.com,2009-05-28:customers", 246 "tag:example.com,2009-05-28:co-workers"], 247 header :contains "subject" "urgent" 248 ) { 249 if notify_method_capability "xmpp:me@example.com" "show" "xa" 250 { 251 redirect "susan@example.com"; # send a copy to my backup 252 keep; # also keep a copy for myself 253 } 254 } 255 } 257 4. Security Considerations 259 See the Security Considerations sections of the following 260 specifications for discussion of security considerations not covered 261 here: 262 Sieve base specification [RFC5228] 263 Sieve Vacation extension [RFC5230] 264 Vacation "Seconds" parameter [I-D.ietf-sieve-vacation-seconds] 265 Sieve Externally Stored Lists extension 266 [I-D.ietf-sieve-external-lists] 267 Sieve Notify extension [RFC5435] (and any applicable notification 268 methods) 270 This document describes how to set up a system that creates automatic 271 replies in an intelligent way. Despite the "intelligence", errors in 272 scripts can result in too many auto-reply messages, especially when 273 the reply interval is minimal (using the "notify" action, or the 274 "vacation" action with a small value for ":seconds"). 276 Despite the "intelligence", too, errors in scripts can result in 277 private information getting to senders inappropriately. In example 3 278 in Section 3, for instance, if the :list test checks the wrong list, 279 or none at all, information about the recipient's business trip might 280 be sent to someone who has no need to know about it, and shouldn't. 282 Even without errors in scripts, a sender who recognizes that auto- 283 replies are dependent upon the recipient's presence can use that fact 284 to probe the presence information. One result of that can be that 285 the sender discerns changes in the recipient's presence that the 286 sender would normally not be allowed to see, making this an 287 unintentional back door into the user's presence information. 288 Another result is that this can create a "covert channel", allowing 289 the recipient to send information to a sender by changing his 290 presence information, his address book, and/or his Sieve script 291 (though in this regard, the exposure is comparable to any other case 292 of shared presence information). 294 Finally, users of any auto-reply mechanism should really think about 295 whether automatic replies are necessary, and at what interval they 296 make sense when they are. Email is not Instant Messaging, and 297 senders generally expect that replies might take a while. Consider 298 whether it's truly important to tell people that you'll read their 299 mail in an hour or so, or whether that can just be taken as how email 300 works. There are times when this makes sense, but let's not use it 301 to exacerbate information overload. 303 5. IANA Considerations 305 There are no IANA actions required by this document. 307 6. Normative References 309 [I-D.ietf-sieve-external-lists] 310 Melnikov, A. and B. Leiba, "Sieve Extension: Externally 311 Stored Lists", draft-ietf-sieve-external-lists-02 (work in 312 progress), May 2010. 314 [I-D.ietf-sieve-notify-presence] 315 George, R. and B. Leiba, "Sieve Notification Using 316 Presence Information", draft-ietf-sieve-notify-presence-01 317 (work in progress), October 2010. 319 [I-D.ietf-sieve-vacation-seconds] 320 George, R. and B. Leiba, "Sieve Vacation Extension: 321 "Seconds" parameter", draft-ietf-sieve-vacation-seconds-01 322 (work in progress), October 2010. 324 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 325 Language", RFC 5228, January 2008. 327 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 328 RFC 5229, January 2008. 330 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 331 Vacation Extension", RFC 5230, January 2008. 333 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 334 "Sieve Email Filtering: Extension for Notifications", 335 RFC 5435, January 2009. 337 Authors' Addresses 339 Robins George 341 Email: robinsgv@gmail.com 343 Barry Leiba 344 Huawei Technologies 346 Phone: +1 646 827 0648 347 Email: barryleiba@computer.org 348 URI: http://internetmessagingtechnology.org/ 350 Alexey Melnikov 351 Isode Limited 352 5 Castle Business Village, 36 Station Road 353 Hampton, Middlesex TW12 2BX 354 UK 356 Email: Alexey.Melnikov@isode.com 357 URI: http://www.melnikov.ca/