idnits 2.17.1 draft-degener-sieve-copy-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 246 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 26 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2004) is 7253 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'SIEVE' on line 186 looks like a reference -- Missing reference section? 'KEYWORDS' on line 180 looks like a reference -- Missing reference section? 'LDAP' on line 183 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jutta Degener 2 Internet Draft Sendmail, Inc. 3 Expires: December 2004 June 2004 5 Sieve Extension: Copying Without Side Effects 6 8 Status of this memo 10 This document is an Internet-Draft and is subject to all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Abstract 32 The sieve scripting language allows users to control 33 handling and disposal of their incoming e-mail. By default, 34 an e-mail message that is processed by a sieve script is saved 35 in the owner's "inbox". Actions such as "fileinto" and 36 "redirect" cancel this default behavior. 38 This document defines a new keyword parameter, ":copy", to be 39 used with the sieve "fileinto" and "redirect" actions. Adding 40 ":copy" to an action suppresses cancellation of the default 41 "inbox" save. It allows users to add commands to an existing 42 script without changing the meaning of the rest of the script. 44 1. Introduction 46 The sieve scripting language [SIEVE] allows users to control 47 handling and disposal of their incoming e-mail. Two frequently 48 used sieve commands are "fileinto" (saving into a local message 49 store, such as an IMAP server) and "redirect" (forwarding 50 to another e-mail address). Both of these cancel the sieve 51 default behavior of saving into the user's "inbox". 53 But some users have the notion of forwarding an extra copy of a 54 message for safekeeping to another e-mail address, or of saving 55 a copy in a folder -- in addition to the regular message 56 delivery, which shouldn't be affected by the copy. 58 If saving an extra copy is all the user wanted to do, 60 fileinto "unfiltered"; 61 keep; 63 would do the job. The "keep" command does explicitly what the 64 canceled default behavior did. But the explicit "keep" is a 65 poor substitute for the implicit keep when more processing follows: 67 fileinto "unfiltered"; 68 keep; 70 if header "Subject" "MAKE MONEY FAST!!!" 71 { 72 discard; 73 } 75 In this example, the "discard" is ineffective against the 76 explicit "keep"; the discarded message still ends up in 77 the user's inbox. 79 It is possible to generate sieve code that perfectly 80 expresses a user's wishes, but such code quickly grows 81 unwieldy because it needs to keep track of the state 82 the implicit keep would have had without the fileinto 83 or redirect command. 85 This extension tries to make life easier for user interface 86 designers and script writers by allowing them to express 87 the "copy" semantics directly. 89 2. Conventions used. 91 Conventions for notations are as in [SIEVE] section 1.1, including 92 use of [KEYWORDS] and "Syntax:" label for the definition of action 93 and tagged arguments syntax. 95 The capability string associated with extension defined in this 96 document is "copy". 98 3. ":copy" extension to the "fileinto" and "redirect" command. 100 Syntax: 101 "fileinto" [":copy"] 102 "redirect" [":copy"] 104 If the optional :copy keyword is specified with "fileinto" 105 or "redirect", the tagged command does not cancel the 106 implicit keep. Instead, it merely files or redirects a 107 copy in addition to whatever else is happening to the 108 message. 110 Example: 112 require ["copy", "fileinto"]; 113 fileinto :copy "incoming"; 115 # ... more processing follows ... 117 4. Security Considerations 119 The "copy" extension makes it easier to eavesdrop on a user's 120 message stream without the user noticing. This was technically 121 possible before if an attacker gained read/write access to a 122 user's sieve scripts, but now an attacker no longer needs to 123 parse a script in order to modify it. Write access to sieve scripts 124 must be protected as strongly as read/write access to e-mail, 125 for example by using secure directory protocols such as correctly 126 parametrized LDAP over TLS [LDAP]. 128 Organizations that wish to monitor their users' e-mail traffic 129 must familiarize themselves with local data protection laws 130 before creating stores of old e-mail traffic without control or 131 perhaps even knowledge of the sender or intended recipients. 133 Organizations that legally use redirect :copy to eavesdrop 134 on correspondence (for example, by keeping a log to later answer 135 questions about insider trading) can avoid later problems by 136 setting privacy expectations of their users correctly. 138 5. IANA Considerations 140 The following template specifies the IANA registration of the 141 "copy" Sieve extension specified in this document. 143 To: iana@iana.org 144 Subject: Registration of new Sieve extension 146 Capability name: copy 147 Capability keyword: copy 148 Capability arguments: N/A 149 Standards Track/IESG-approved experimental RFC number: this RFC 150 Person and email address to contact for further information: 152 Jutta Degener 153 Sendmail, Inc. 154 6425 Christie Ave, 4th Floor 155 Emeryville, CA 94608 157 Email: jutta@sendmail.com 159 This information should be added to the list of sieve extensions 160 given on http://www.iana.org/assignments/sieve-extensions. 162 6. Acknowledgments 164 Thanks to Eric Allman, Ned Freed, Will Lee, Nigel Swinson, 165 and Rand Wacker for corrections and comments. 167 7. Author's Address 169 Jutta Degener 170 Sendmail, Inc. 171 6425 Christie Ave, 4th Floor 172 Emeryville, CA 94608 174 Email: jutta@sendmail.com 176 Appendices 178 Appendix A. Normative References 180 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", RFC 2119, March 1997. 183 [LDAP] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, 184 "Authentication Methods for LDAP", RFC 2829, May 2000. 186 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, 187 January 2001. 189 Appendix B. Intellectual Property Rights Statement 191 The IETF takes no position regarding the validity or scope of any 192 intellectual property or other rights that might be claimed to 193 pertain to the implementation or use of the technology described in 194 this document or the extent to which any license under such rights 195 might or might not be available; neither does it represent that it 196 has made any effort to identify any such rights. Information on the 197 IETF's procedures with respect to rights in standards-track and 198 standards-related documentation can be found in BCP-11. Copies of 199 claims of rights made available for publication and any assurances 200 of licenses to be made available, or the result of an attempt made 201 to obtain a general license or permission for the use of such 202 proprietary rights by implementors or users of this specification 203 can be obtained from the IETF Secretariat. 205 Appendix C. Full Copyright Statement 207 Copyright (C) The Internet Society 2004. All Rights Reserved. 209 This document and translations of it may be copied and furnished to 210 others, and derivative works that comment on or otherwise explain it 211 or assist in its implementation may be prepared, copied, published 212 and distributed, in whole or in part, without restriction of any 213 kind, provided that the above copyright notice and this paragraph 214 are included on all such copies and derivative works. However, this 215 document itself may not be modified in any way, such as by removing 216 the copyright notice or references to the Internet Society or other 217 Internet organizations, except as needed for the purpose of 218 developing Internet standards in which case the procedures for 219 copyrights defined in the Internet Standards process must be 220 followed, or as required to translate it into languages other than 221 English. 223 The limited permissions granted above are perpetual and will not be 224 revoked by the Internet Society or its successors or assigns. 226 This document and the information contained herein is provided on an 227 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 228 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 229 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 230 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 231 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.