idnits 2.17.1 draft-ietf-extra-sieve-fcc-06.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC5230, updated by this document, for RFC5378 checks: 2005-03-16) -- 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 (October 1, 2018) is 2033 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) -- Looks like a reference, but probably isn't: '1' on line 520 == Missing Reference: 'FCC' is mentioned on line 199, but not defined -- Looks like a reference, but probably isn't: '2' on line 522 -- Looks like a reference, but probably isn't: '3' on line 524 -- Looks like a reference, but probably isn't: '4' on line 526 == Outdated reference: A later version (-05) exists of draft-ietf-extra-sieve-special-use-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EXTRA K. Murchison 3 Internet-Draft B. Gondwana 4 Updates: 5230, 5435 (if approved) FastMail 5 Intended status: Standards Track October 1, 2018 6 Expires: April 4, 2019 8 Sieve Extension: File Carbon Copy (Fcc) 9 draft-ietf-extra-sieve-fcc-06 11 Abstract 13 The Sieve Email Filtering Language provides a number of action 14 commands, some of which can generate additional messages on behalf of 15 the user. This document defines an extension to such commands to 16 allow a copy of any generated message to be filed into a target 17 mailbox. 19 This document updates RFC5230 and RFC5435 by adding a new tagged 20 argument to the "vacation" and "enotify" actions respectively. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 4, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 3. Tagged Argument ":fcc" . . . . . . . . . . . . . . . . . . . 3 59 3.1. Format of Filed Messages . . . . . . . . . . . . . . . . 3 60 3.2. Interaction with the Vacation Action . . . . . . . . . . 4 61 3.3. Interaction with the Notify Action . . . . . . . . . . . 5 62 3.3.1. Notification-Capability "fcc" . . . . . . . . . . . . 5 63 3.4. Compatibility with Other Actions . . . . . . . . . . . . 6 64 3.5. Interaction with Fileinto Extensions . . . . . . . . . . 6 65 3.5.1. Imap4flags Extension . . . . . . . . . . . . . . . . 7 66 3.5.2. Mailbox Extension . . . . . . . . . . . . . . . . . . 7 67 3.5.3. Special-Use Extension . . . . . . . . . . . . . . . . 7 68 3.5.4. Extended Example . . . . . . . . . . . . . . . . . . 8 69 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Registration of Sieve Extension . . . . . . . . . . . . . 9 73 6.2. Registration of Notification-Capability 74 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 8.2. Informative References . . . . . . . . . . . . . . . . . 11 79 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 Appendix A. Change History (To be removed by RFC Editor before 81 publication) . . . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 The Sieve Email Filtering Language [RFC5228] provides a number of 87 action commands, some of which can generate additional messages on 88 behalf of the user. It is sometimes desirable for a Sieve user to 89 maintain an archive of the messages generated by these commands. 91 This extension defines a new optional tagged argument ":fcc" to 92 action commands which generate additional messages to allow a copy of 93 the generated message to be filed into a target mailbox. 95 The capability string associated with this extension is "fcc". 97 Each action that generates additional messages will need to specify 98 how it interfacts with :fcc. This document also specifies the 99 interaction of :fcc with the Vacation [RFC5230] and Notify [RFC5435] 100 extensions. 102 2. Conventions Used in This Document 104 Conventions for notations are as in Section 1.1 of [RFC5228], 105 including use of the "Usage:" label for the definition of action and 106 tagged arguments syntax. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [1] [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Tagged Argument ":fcc" 116 For convenience, the "FCC" syntax element is defined here using ABNF 117 [RFC5234] so that it can be augmented by other extensions. 119 FCC = ":fcc" 121 If the optional ":fcc" argument is specified with an action that 122 generates an additional message, it instructs the Sieve interpreter 123 to file a copy of the generated message into the target mailbox. The 124 syntax and semantics of the mailbox argument MUST match those of the 125 mailbox argument to the "fileinto" action specified in Section 4.1 of 126 [RFC5228]. If the specified mailbox doesn't exist, the 127 implementation MAY treat it as an error, create the mailbox, or file 128 the message into an implementation-defined mailbox. 130 3.1. Format of Filed Messages 132 Copies of messages filed into a mailbox via this extension are 133 REQUIRED to be in Internet Message Format [RFC5322]. Some messages 134 generated by Sieve actions might already conform to this format and 135 MAY be filed without modification. Messages generated in other 136 formats MUST be encapsulated using constructs from [RFC5322] and MIME 137 ([RFC2045], [RFC2046], [RFC2047]). 139 The general requirements for encapsulating the copies of messages to 140 be filed are the following: 142 o Date: The Date header field is REQUIRED and SHOULD be set to the 143 date and time when the message was generated. 145 o From: The From header field is REQUIRED and SHOULD be set to the 146 email address of the owner of the Sieve script, unless explicitly 147 overridden by rules for encapsulating a particular message type. 149 o To: The To header field is OPTIONAL and MAY be set to the email 150 address of the recipient of the generated message, if available. 152 o Subject: The Subject header field is OPTIONAL and MAY be generated 153 as follows: The subject is set to the characters "Fcc: " followed 154 by the subject of the message being processed by the Sieve 155 interpreter. 157 o In-Reply-To: The In-Reply-To header field is OPTIONAL and MAY be 158 set to the Message-ID of the message being processed by the Sieve 159 interpreter. 161 o Message Body: The body of the filed message is REQUIRED and is 162 composed of one or more MIME-parts containing the generated 163 message and any related metadata. The Content-Type header 164 field(s) MUST be set to the appropriate MIME types. If any of the 165 MIME-parts include 8-bit or binary data, the Content-Transfer- 166 Encoding header field(s) MUST be set accordingly. 168 3.2. Interaction with the Vacation Action 170 This document extends the "vacation" [RFC5230] action (see also 171 "vacation-seconds" [RFC6131]) to optionally store a copy of the auto- 172 reply messages into a target mailbox. 174 Usage: vacation [FCC] 175 [":days" number | ":seconds" number] 176 [":subject" string] 177 [":from" string] 178 [":addresses" string-list] 179 [":mime"] 180 [":handle" string] 181 183 Example: 185 require ["vacation", "fcc"]; 187 vacation :days 7 188 :from "hemingway@example.com" "Gone Fishin'" 189 :fcc "INBOX.Sent"; 191 Vacation auto-reply messages are MIME-compliant and MAY be filed into 192 the target mailbox without modification. 194 3.3. Interaction with the Notify Action 196 This document extends the "notify" [RFC5435] action to optionally 197 store a copy of the notification messages into a target mailbox. 199 Usage: notify [FCC] 200 [":from" string] 201 [":importance" <"1" / "2" / "3">] 202 [":options" string-list] 203 [":message" string] 204 206 Example: 208 require ["enotify", "fcc"]; 210 notify :fcc "INBOX.Sent" 211 :message "You got mail!" 212 "mailto:ken@example.com"; 214 Messages generated using the "mailto" [RFC5436] notification method 215 are MIME-compliant and MAY be filed into the target mailbox without 216 modification. 218 Messages generated by other notification methods (e.g. "xmpp" 219 [RFC5437]) MUST be encapsulated per Section 3.1 before being filed. 220 The body of the filed message MUST include the :message parameter and 221 MAY include one or more of the :from, :importance, or :options 222 parameters. The MIME-type(s) of the body part(s) used to encapsulate 223 the parameters is an implementation decision. 225 An implementation MAY only support :fcc in conjunction with a subset 226 of the notification methods it supports. An error occurs if :fcc is 227 combined with a notification method that doesn't support it. 228 Notification methods that support :fcc can be discovered at run-time 229 using the mechanism described below (Section 3.3.1). 231 3.3.1. Notification-Capability "fcc" 233 This document defines a new notification-capability value "fcc" for 234 use with the notify_method_capability test (see Section 5 of 235 [RFC5435]. For the "fcc" notification-capability, the 236 notify_method_capability test can match one of the following key-list 237 values: 239 yes A copy of the notification message sent using the method 240 identified by the notification-uri can be filed into a target 241 mailbox. 243 no A copy of the notification message sent using the method 244 identified by the notification-uri can not be filed into a target 245 mailbox. 247 Note that the "fcc" notify_method_capability test does not require 248 the notification-uri argument to specify anything other than a 249 scheme. 251 Example: 253 require ["enotify", "fcc"]; 255 if notify_method_capability "xmpp:" "Fcc" "yes" { 256 notify :fcc "INBOX.Sent" 257 :message "You got mail" 258 "xmpp:ken@example.com?message;subject=SIEVE"; 259 } else { 260 notify :fcc "INBOX.Sent" 261 :message "You got mail!" 262 "mailto:ken@example.com"; 263 } 265 3.4. Compatibility with Other Actions 267 The "fcc" extension is not compatible with any Sieve action that does 268 not generate an additional message on behalf of the user. It is an 269 error for a script to use the ":fcc" tagged argument with any such 270 action. 272 Future extensions that define actions that generate additional 273 messages on behalf of the user should describe their compatibility 274 with ":fcc", and how to MIME-encapsulate the message, if required. 276 3.5. Interaction with Fileinto Extensions 278 The "fcc" extension can be used with some tagged arguments defined in 279 extensions to the "fileinto" action. The sections below describe its 280 interaction with currently defined extensions. Tagged arguments in 281 future extensions to the "fileinto" command should describe their 282 interaction with ":fcc", if any. 284 When any "fileinto" extension arguments are used with ":fcc", the 285 corresponding extension MUST be enabled, and the arguments MUST have 286 the same syntax and semantics as they do with "fileinto". 288 3.5.1. Imap4flags Extension 290 This document extends the definition of the ":flags" [RFC5232] tagged 291 argument so that it can optionally be used with the ":fcc" argument. 293 FCC =/ [":flags" ] 295 If the optional ":flags" argument is specified with ":fcc", it 296 instructs the Sieve interpreter to set the IMAP4 flags provided in 297 the subsequent argument when the generated message is filed into the 298 target mailbox. 300 3.5.2. Mailbox Extension 302 This document extends the definition of the ":create" [RFC5490] 303 tagged argument so that it can optionally be used with the ":fcc" 304 argument. 306 FCC =/ [":create"] 308 If the optional ":create" argument is specified with ":fcc", it 309 instructs the Sieve interpreter to create the target mailbox, if 310 needed, before attempting to file the generated message into the 311 target mailbox. 313 3.5.3. Special-Use Extension 315 This document extends the definition of the ":specialuse" 316 [I-D.ietf-extra-sieve-special-use] tagged argument so that it can 317 optionally be used with the ":fcc" argument. 319 FCC =/ [":specialuse" ] 321 If the optional ":specialuse" argument is specified with ":fcc", it 322 instructs the Sieve interpreter to check whether a mailbox exists 323 with the specific special-use flag assigned to it. If such a mailbox 324 exists, the generated message is filed into the special-use mailbox. 325 Otherwise, the generated message is filed into the target mailbox. 327 If both the optional ":specialuse" and ":create" arguments are 328 specified with ":fcc", the Sieve interpreter is instructed to create 329 the target mailbox per Section 4.1 of 330 [I-D.ietf-extra-sieve-special-use], if needed. 332 3.5.4. Extended Example 334 require ["vacation", "fcc", "mailbox", "special-use", "imap4flags"]; 336 vacation :days 7 337 :from "hemingway@example.com" "Gone Fishin'" 338 :fcc "INBOX.Sent" :specialuse "\\Sent" :create 339 :flags ["\\Seen"]; 341 4. Implementation Status 343 < RFC Editor: before publication please remove this section and the 344 reference to [RFC7942] > 346 This section records the status of known implementations of the 347 protocol defined by this specification at the time of posting of this 348 Internet-Draft, and is based on a proposal described in [RFC7942]. 349 The description of implementations in this section is intended to 350 assist the IETF in its decision processes in progressing drafts to 351 RFCs. Please note that the listing of any individual implementation 352 here does not imply endorsement by the IETF. Furthermore, no effort 353 has been spent to verify the information presented here that was 354 supplied by IETF contributors. This is not intended as, and must not 355 be construed to be, a catalog of available implementations or their 356 features. Readers are advised to note that other implementations may 357 exist. 359 According to [RFC7942], "this will allow reviewers and working groups 360 to assign due consideration to documents that have the benefit of 361 running code, which may serve as evidence of valuable experimentation 362 and feedback that have made the implemented protocols more mature. 363 It is up to the individual working groups to use this information as 364 they see fit". 366 4.1. Cyrus Server 368 The open source Cyrus Server [2] project is a highly scalable 369 enterprise mail system which supports Sieve email filtering at the 370 point of final delivery. This production level Sieve implementation 371 supports all of the requirements described in this document. This 372 implementation is freely distributable under a BSD style license from 373 Computing Services at Carnegie Mellon University [3]. 375 4.2. Oracle Communications Messaging Server 377 The Oracle Communications Messaging Server [4] is a highly scalable, 378 reliable, and available messaging platform. This production level 379 product supports the :fcc extension in conjunction with both the 380 notify and vacation extensions. The implementation meets all the 381 requirements given in this document. The product also supports the 382 imap4flags extension so the :flags may be used in conjunction :fcc. 384 5. Security Considerations 386 The "fcc" extension does not raise any other security considerations 387 that are not already present in [RFC5228], [RFC5230], [RFC5435], and 388 [RFC6131]. 390 6. IANA Considerations 392 6.1. Registration of Sieve Extension 394 To: iana@iana.org 396 Subject: Registration of new Sieve extension 398 Capability name: fcc 400 Description: Adds the ":fcc" parameter to Sieve action commands 401 that generate additional messages. 403 RFC number: RFC XXXX 405 Contact address: The Sieve discussion list 407 6.2. Registration of Notification-Capability Parameter 409 To: iana@iana.org 411 Subject: Registration of a new notification-capability parameter 413 Capability name: fcc 415 Description: Returns whether a copy of the notification message 416 sent using the method identified by the notification-uri parameter 417 to the notify_method_capability test can be filed into a target 418 mailbox. 420 Syntax: Can contain one of two values: "yes" or "no". Values MUST 421 be in lowercase. 423 Permanent and readily available reference(s): This RFC 425 Contact information: The Sieve discussion list 428 7. Acknowledgments 430 The authors would like to thank the following individuals for 431 contributing their ideas and support for writing this specification: 432 Ned Freed, Stan Kalisch, and Alexey Melnikov. 434 8. References 436 8.1. Normative References 438 [I-D.ietf-extra-sieve-special-use] 439 Bosch, S., "Sieve Email Filtering: Delivering to Special- 440 Use Mailboxes", draft-ietf-extra-sieve-special-use-03 441 (work in progress), September 2018. 443 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 444 Extensions (MIME) Part One: Format of Internet Message 445 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 446 . 448 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 449 Extensions (MIME) Part Two: Media Types", RFC 2046, 450 DOI 10.17487/RFC2046, November 1996, 451 . 453 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 454 Part Three: Message Header Extensions for Non-ASCII Text", 455 RFC 2047, DOI 10.17487/RFC2047, November 1996, 456 . 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, 460 DOI 10.17487/RFC2119, March 1997, 461 . 463 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 464 Filtering Language", RFC 5228, DOI 10.17487/RFC5228, 465 January 2008, . 467 [RFC5230] Showalter, T. and N. Freed, Ed., "Sieve Email Filtering: 468 Vacation Extension", RFC 5230, DOI 10.17487/RFC5230, 469 January 2008, . 471 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 472 Extension", RFC 5232, DOI 10.17487/RFC5232, January 2008, 473 . 475 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 476 Specifications: ABNF", STD 68, RFC 5234, 477 DOI 10.17487/RFC5234, January 2008, 478 . 480 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 481 DOI 10.17487/RFC5322, October 2008, 482 . 484 [RFC5435] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. 485 Martin, "Sieve Email Filtering: Extension for 486 Notifications", RFC 5435, DOI 10.17487/RFC5435, January 487 2009, . 489 [RFC5490] Melnikov, A., "The Sieve Mail-Filtering Language -- 490 Extensions for Checking Mailbox Status and Accessing 491 Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March 492 2009, . 494 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 495 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 496 May 2017, . 498 8.2. Informative References 500 [RFC5436] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: 501 mailto", RFC 5436, DOI 10.17487/RFC5436, January 2009, 502 . 504 [RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification 505 Mechanism: Extensible Messaging and Presence Protocol 506 (XMPP)", RFC 5437, DOI 10.17487/RFC5437, January 2009, 507 . 509 [RFC6131] George, R. and B. Leiba, "Sieve Vacation Extension: 510 "Seconds" Parameter", RFC 6131, DOI 10.17487/RFC6131, July 511 2011, . 513 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 514 Code: The Implementation Status Section", BCP 205, 515 RFC 7942, DOI 10.17487/RFC7942, July 2016, 516 . 518 8.3. URIs 520 [1] https://tools.ietf.org/html/bcp14 522 [2] http://www.cyrusimap.org/ 524 [3] http://www.cmu.edu/computing/ 526 [4] https://www.oracle.com/industries/communications/enterprise/ 527 products/messaging-server/index.html 529 Appendix A. Change History (To be removed by RFC Editor before 530 publication) 532 Changes since draft-ietf-extra-sieve-fcc-05: 534 o Editorial changes from Jiankang Yao. 536 Changes since draft-ietf-extra-sieve-fcc-04: 538 o Editorial changes from Ned Freed. 540 o Added information on Oracle implementation. 542 Changes since draft-ietf-extra-sieve-fcc-03: 544 o Fixed typo in ABNF. 546 Changes since draft-ietf-extra-sieve-fcc-02: 548 o Updated Keywords boilerplate. 550 o Noted that :fcc mailbox argument and any fileinto extension 551 arguments used wth :fcc have the same syntax and semantics as they 552 have with fileinto. 554 o Removed section on [e]Reject. 556 o Added "fcc" notification-capability. 558 o Added Implementation Status section. 560 o Editorial changes from Ned Freed. 562 Changes since draft-ietf-extra-sieve-fcc-01: 564 o Added text discussing how to handle generated messages that are 565 not in MIME format. 567 o Adjusted ABNF so that tagged arguments that supplement :fcc no 568 longer appear as positional. 570 Changes since draft-ietf-extra-sieve-fcc-00: 572 o Updated abstract with text from Ned. 574 o Added support for :fcc to notify extension. 576 o Prohibit use of :fcc with reject and ereject extensions. 578 o Added registration of the extension with IANA. 580 o Added Acknowledgments. 582 o Minor editorial changes. 584 Authors' Addresses 586 Kenneth Murchison 587 FastMail US LLC 588 1429 Walnut Street 589 Philadelphia, PA 19107 590 USA 592 Email: murch@fastmailteam.com 594 Bron Gondwana 595 FastMail Pty Ltd 596 Level 2, 114 William Street 597 Melbourne, VIC 3000 598 Australia 600 Email: brong@fastmailteam.com