idnits 2.17.1 draft-ietf-sieve-autoreply-04.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 (January 10, 2011) is 4852 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 B. Leiba 4 Intended status: Informational Huawei Technologies 5 Expires: July 14, 2011 A. Melnikov 6 Isode Limited 7 January 10, 2011 9 Sieve Email Filtering: Use of Presence Information with Auto Responder 10 functionality 11 draft-ietf-sieve-autoreply-04 13 Abstract 15 This document describes how the Sieve email filtering language, along 16 with some extensions, can be used to create automatic replies to 17 incoming electronic mail messages based on the address book and 18 presence information of the recipient. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 14, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. How To Create Auto Replies . . . . . . . . . . . . . . . . . . 4 58 3. Example Use Cases for Auto Replies . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 This document describes how the Sieve email filtering language 71 [RFC5228], along with some extensions [RFC5230] [RFC5435] 72 [I-D.ietf-sieve-external-lists] [I-D.ietf-sieve-notify-presence] 73 [I-D.ietf-sieve-vacation-seconds] can be used to generate automatic 74 replies to incoming electronic mail messages based on the presence 75 information of the recipient. This can be used, for example, to 76 inform the sender that messages will not be answered immediately 77 because the recipient is busy or away. 79 The auto-reply message can additionally be based on information about 80 the sender from the recipient's address book, sub-lists therefrom, or 81 other lists available to the recipient, so that different senders 82 might get different responses. The recipient can create separate 83 rules for friends, family members, colleagues, and so on. 85 This can be used in mail filtering software, email-based information 86 services, and other automatic responder situations. There are many 87 programs currently in use that automatically respond to email. Some 88 of them send many useless or unwanted responses, or send responses to 89 inappropriate addresses. The mechanism described herein will help to 90 avoid those problems (but see the discussion in Section 4). 91 Implementations need to take care of tracking previous messages 92 received from the same sender and they will start or stop sending 93 responses as the presence status of the recipient changes. 95 An important note, though: users of any auto-reply mechanism should 96 really think about whether automatic replies are necessary, and at 97 what interval they make sense when they are. Email is not Instant 98 Messaging, and senders generally expect that replies might take a 99 while. Consider whether it's truly important to tell people that 100 you'll read their mail in an hour or so, or whether that can just be 101 taken as how email works. There are times when this makes sense, but 102 let's not use it to exacerbate information overload. Judicious use 103 of appropriate presence information might serve to mitigate these 104 issues. 106 Implementors, therefore, need to consider this with respect to the 107 features they expose to users, and the potential for inappropriate 108 use those features represent. The ability to create auto-responders 109 might be hidden behind an "advanced" button, and users might be 110 warned of the consequences, and advised of the considerations in the 111 previous paragraph. 113 2. How To Create Auto Replies 115 When an email message arrives, the Sieve script can use the 116 notify_method_capability of the Notify extension [RFC5435] to check 117 the recipient's presence information. The Notify-presence extension 118 [I-D.ietf-sieve-notify-presence] makes additional presence, such as 119 "away" and "do not disturb" status, available. The script can use 120 the External-lists extension [I-D.ietf-sieve-external-lists] to look 121 the sender up in the recipient's address book or other list. If the 122 information retrieved warrants an auto-reply message, the message can 123 then be composed based on that information. 125 The Vacation extension [RFC5230] provides an easy way to send the 126 auto-reply message to the sender, as it automatically keeps track of 127 the automatic replies and attempts to avoid excessive messages and 128 mail loops. The Vacation-seconds extension 129 [I-D.ietf-sieve-vacation-seconds] allows auto-replies to be sent this 130 way more frequently than once per day, when that's appropriate. 131 (Alternatively, the script can use the Notify extension,[RFC5435] and 132 it can use that to send a notification by a means other than email.) 134 Personal and Group Responders can refuse to generate responses except 135 to known correspondents or addresses otherwise known to the 136 recipient. Such responders can also generate different kinds of 137 responses for "trusted" vs "untrusted" addresses. This might be 138 useful, for instance, to avoid inappropriate disclosure of personal 139 or confidential information to arbitrary addresses. 141 3. Example Use Cases for Auto Replies 143 1. In this example, we check that the envelope "from" is in the 144 recipient's address book [I-D.ietf-sieve-external-lists] and that 145 the recipient's presence shows "extended 146 away".[I-D.ietf-sieve-notify-presence] If both of those are true, 147 the "vacation" action [RFC5230] is used to send an auto-reply, 148 making sure we don't reply to the same sender more than once 149 every half hour.[I-D.ietf-sieve-vacation-seconds] The variables 150 extension [RFC5229] is used to extract the value of the 151 recipient's natural-language presence status message, which will 152 be used as the response to the sender. 154 require ["envelope", "extlists", "enotify", "variables", 155 "vacation-seconds"]; 156 if allof ( 157 envelope :list "from" "tag:example.com,2009-05-28:AddrBook", 158 notify_method_capability "xmpp:me@example.com" "show" "xa" 159 ) { 160 # :matches "*" is used here to extract the value 161 if notify_method_capability :matches 162 "xmpp:myjid@example.com" "status" "*" { 163 set "resp_msg" "${1}"; 164 } else { 165 set "resp_msg" "Away for a while, without access to email."; 166 } 167 vacation :handle "ext-away" :seconds 1800 "${resp_msg}"; 168 } 170 2. In the next example, we'll check for the recipient's personal 171 assistant, and give very detailed information about the 172 recipient's status to that sender. For other senders in the 173 "family" and "friends" lists we'll also send an auto-reply. 174 Other senders will be considered less important, and don't need 175 auto-replies. 177 require ["envelope", "extlists", "enotify", "vacation-seconds"]; 179 if envelope :is "from" "assistant@example.com" 180 { 181 if notify_method_capability "xmpp:me@example.com" "show" "away" 182 { 183 vacation :handle "away" :seconds 600 184 "I'm away for now, but I'll be back soon."; 185 } 186 elsif notify_method_capability "xmpp:me@example.com" "show" "dnd" 187 { 188 vacation :handle "dnd" :seconds 1800 189 "I'm not to be disturbed. I'll check mail later."; 190 } 191 elsif notify_method_capability "xmpp:me@example.com" "show" "xa" 192 { 193 vacation :handle "ext-away" :seconds 3600 194 "I'm away for a while, without access to email."; 195 } 196 elsif notify_method_capability "xmpp:me@example.com" "busy" "yes" 197 { 198 vacation :handle "busy" :seconds 1800 199 "I'm very busy, but might check email now and then."; 200 } 201 } 202 elsif envelope :list "from" ["tag:example.com,2009-05-28:family", 203 "tag:example.com,2009-05-28:friends"] 204 { 205 if notify_method_capability "xmpp:me@example.com" "show" 206 ["away", "dnd", "xa"] 207 { 208 vacation :handle "away" :seconds 3600 209 "I'm not available to respond to email."; 210 } 211 } 212 else 213 { # We could respond as below, making it only once a day 214 # for less important senders. Better to just omit 215 # that, though (see the end of the Introduction section). 216 # 217 # vacation :handle "catchall" :days 1 218 # "I got your message, and might read it eventually."; 219 } 221 3. For this example, if the sender is a work colleague and the 222 recipient is on extended away status, then reply with a message 223 giving alternative contact information. The message might also 224 include details about the reason for the absence, or other 225 personal or confidential information that shouldn't be shared 226 with senders who aren't associated with the recipient's company. 228 require ["envelope", "extlists", "enotify", "vacation"]; 230 if envelope :list "from" "tag:example.com,2009-05-28:co-workers" 231 { 232 if notify_method_capability "xmpp:me@example.com" "show" "xa" 233 { 234 vacation :handle "bigtrip" :days 3 235 "I'm on an extended business trip to Texas for the Foo 236 project. Contact my backup, Susan , 237 or call my assistant on +1 666 555 1234 if you urgently 238 need to contact me."; 239 } 240 } 242 4. This example is used to send an acknowledgment to every message 243 received. A :seconds value of zero is used to reply to every 244 message, with no removal of duplicates to the same sender. This 245 requires that the Sieve engine allow an interval of zero; if it 246 does not, and it imposes a minimum value, not every message will 247 receive an auto-reply. 249 require ["envelope", "extlists", "vacation-seconds"]; 251 if not envelope :list "from" "tag:example.com,2009-05-28:staff" 252 { 253 vacation :handle "auto-resp" :seconds 0 254 "Your request has been received. A service 255 representative will contact you as soon as 256 possible, usually within one business day."; 257 } 259 5. This example uses the same structure to automatically send a copy 260 of each incoming message to the recipient's backup, if the sender 261 is a customer contact or co-worker, or if the message's subject 262 includes the word "urgent". 264 require ["envelope", "extlists", "enotify"]; 266 if anyof ( 267 envelope :list "from" ["tag:example.com,2009-05-28:customers", 268 "tag:example.com,2009-05-28:co-workers"], 269 header :contains "subject" "urgent" 270 ) { 271 if notify_method_capability "xmpp:me@example.com" "show" "xa" 272 { 273 redirect "susan@example.com"; # send a copy to my backup 274 keep; # also keep a copy for myself 275 } 276 } 277 } 279 4. Security Considerations 281 See the Security Considerations sections of the following 282 specifications for discussion of security considerations not covered 283 here: 284 Sieve base specification [RFC5228] 285 Sieve Vacation extension [RFC5230] 286 Vacation "Seconds" parameter [I-D.ietf-sieve-vacation-seconds] 287 Sieve Externally Stored Lists extension 288 [I-D.ietf-sieve-external-lists] 289 Sieve Notify extension [RFC5435] (and any applicable notification 290 methods) 292 This document describes how to set up a system that creates automatic 293 replies in an intelligent way. Despite the "intelligence", errors in 294 scripts can result in too many auto-reply messages, especially when 295 the reply interval is minimal (using the "notify" action, or the 296 "vacation" action with a small value for ":seconds"). 298 Despite the "intelligence", too, errors in scripts can result in 299 private information getting to senders inappropriately. In example 3 300 in Section 3, for instance, if the :list test checks the wrong list, 301 or none at all, information about the recipient's business trip might 302 be sent to someone who has no need to know about it, and shouldn't. 304 Even without errors in scripts, a sender who recognizes that auto- 305 replies are dependent upon the recipient's presence can use that fact 306 to probe the presence information. One result of that can be that 307 the sender discerns changes in the recipient's presence that the 308 sender would normally not be allowed to see, making this an 309 unintentional back door into the user's presence information. 310 Another result is that this can create a "covert channel", allowing 311 the recipient to send information to a sender by changing his 312 presence information, his address book, and/or his Sieve script 313 (though in this regard, the exposure is comparable to any other case 314 of shared presence information). 316 An autoresponder can cause leaks of other pieces of information, 317 including potentially providing the ability to attack cryptographic 318 keying material. For example, using the time it takes to perform an 319 cryptographic operation, an attacker may obtain information about the 320 secret key. An autoresponder that doesn't take timing into account 321 could accidentally leak this kind of information. 323 Moreover, if an autoresponder script directly returns the results of 324 a cryptographic operation, that could also provide an attack vector. 325 For example, if a script returns the results of a decryption 326 operation, an attacker can send an arbitrarily encrypted message and 327 use the results as a chosen cyphertext attack to decode the 328 encryption key. Authors of scripts should be careful in what 329 information they return to senders. 331 5. IANA Considerations 333 There are no IANA actions required by this document. 335 6. Normative References 337 [I-D.ietf-sieve-external-lists] 338 Melnikov, A. and B. Leiba, "Sieve Extension: Externally 339 Stored Lists", draft-ietf-sieve-external-lists-02 (work in 340 progress), May 2010. 342 [I-D.ietf-sieve-notify-presence] 343 George, R. and B. Leiba, "Sieve Notification Using 344 Presence Information", draft-ietf-sieve-notify-presence-01 345 (work in progress), October 2010. 347 [I-D.ietf-sieve-vacation-seconds] 348 George, R. and B. Leiba, "Sieve Vacation Extension: 349 "Seconds" parameter", draft-ietf-sieve-vacation-seconds-01 350 (work in progress), October 2010. 352 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 353 Language", RFC 5228, January 2008. 355 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 356 RFC 5229, January 2008. 358 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 359 Vacation Extension", RFC 5230, January 2008. 361 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 362 "Sieve Email Filtering: Extension for Notifications", 363 RFC 5435, January 2009. 365 Authors' Addresses 367 Robins George 368 Huawei Technologies 369 Bangalore, Karnataka 560071 370 India 372 Phone: +91-080-41117676 373 Email: robinsgv@gmail.com 375 Barry Leiba 376 Huawei Technologies 378 Phone: +1 646 827 0648 379 Email: barryleiba@computer.org 380 URI: http://internetmessagingtechnology.org/ 382 Alexey Melnikov 383 Isode Limited 384 5 Castle Business Village, 36 Station Road 385 Hampton, Middlesex TW12 2BX 386 UK 388 Email: Alexey.Melnikov@isode.com 389 URI: http://www.melnikov.ca/