idnits 2.17.1 draft-ietf-sieve-imapflags-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 572. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 626 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 48 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([IMAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 31 has weird spacing: '...ting or using...' == Line 32 has weird spacing: '...rotocol are S...' == Line 60 has weird spacing: '...) being discu...' == Line 61 has weird spacing: '...ription reque...' == Line 62 has weird spacing: '... can be se...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Addflag is used to add flags to a list of [IMAP] flags. It doesn't replace any previously set flags. This means that multiple occurrences of addflag are treated additively. The order of the flags MAY NOT be preserved and duplicates are allowed. -- 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 (May 2005) is 6921 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MATCH-TYPE' is mentioned on line 318, but not defined == Unused Reference: 'ABNF' is defined on line 538, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3028 (ref. 'SIEVE') (Obsoleted by RFC 5228, RFC 5429) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- No information found for draft-ietf-sieve-variables-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Variables' Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft: Sieve -- IMAP flag Extension A. Melnikov 3 Document: draft-ietf-sieve-imapflags-01.txt Isode Limited 4 Expires: November 2005 May 2005 6 Sieve Mail Filtering Language: IMAP flag Extension 8 Status of this memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 The protocol discussed in this document is experimental and subject 31 to change. Persons planning on either implementing or using this 32 protocol are STRONGLY URGED to get in touch with the author before 33 embarking on such a project. 35 Copyright 37 Copyright (C) The Internet Society 2000-2005. All Rights Reserved. 39 Abstract 41 Recent discussions have shown that it is desirable to set different 42 [IMAP] flags on message delivery. This can be done, for example, 43 by a Sieve interpreter that works as a part of a Mail Delivery 44 Agent. 46 This document describes an extension to the Sieve mail filtering 47 language for setting [IMAP] flags. The extension allows to set both 48 [IMAP] system flags and [IMAP] keywords. 50 0. Meta-information on this draft 52 This information is intended to facilitate discussion. It will be 53 removed when this document leaves the Internet-Draft stage. 55 Editorial comments are marked with << and >>. 57 0.1. Discussion 59 This draft defines an extension to the Sieve mail filtering 60 language (RFC 3028) being discussed on the MTA Filters 61 mailing list at . Subscription requests 62 can be sent to (send an email 63 message with the word "subscribe" in the body). More information on 64 the mailing list along with a WWW archive of back messages is 65 available at . 67 0.2. Changes from the version submitted to the Sieve mailing list 69 1. Added addflag and removeflag actions 71 2. Changed the semantics of setflag (setflag is not additive any 72 more) 74 3. Corrected section "Interaction with Other Sieve Actions". 75 Removed incorrect reference to the forward action as to an 76 action that prohibits setflag. 78 4. Added paragraph about the mutual order of "fileinto"/"keep" and 79 "setflag"/"addflag"/"removeflag" actions. 81 0.3. Changes from the revision 00 83 1. Corrected Capability Identifier section (Section 2) 85 2. Corrected "Interaction with Other Sieve Actions" section 86 (Section 4) 88 3. Examples were updated to be compatible with Sieve-07 draft 90 4. Added "mark" and "unmark" actions 92 0.4. Changes from the revision 01 94 1. Some language fixes based on Tony Hansen comments 96 2. Clarified that the extension allows to set both IMAP System 97 Flags and Keywords 99 0.5. Changes from the revision 02 101 1. BugFix: all backslashes must be escaped 103 2. Added extended example and more detailed description of 104 "addflag"/"removeflag" additivity. 106 3. Minor example bugfixes 108 0.6. Changes from the revision 03 110 1. Added second way to specify flags to be set (via optional tagged 111 arguments). [Tim Showalter] 113 2. Rules for using Reject with imapflags relaxed. [Randall Gellens] 115 3. Removed ABNF section completely, added syntax description to 116 action definition. [Tim Showalter] 118 4. Cleaned up the example. [Ken Murchison] 120 5. Added FM (Flag Manupulation) acronym. 122 6. Clarified "mark"/"unmark" bahavior. [Randall Gellens] 124 0.7. Changes from the revision 04 126 1. "Interaction with Other Sieve Actions" was simplified based on 127 comments from Tim Showalter. Added sentence saying that 128 imapflags doesn't change an implicit keep. 130 2. Several editorial comments from Tim Showalter. 132 0.8. Changes from the revision 05 134 1. Updated copyright, author address, section numbers and references. 136 2. Added dependency on Sieve "variables" extension. 138 3. Several editorial comments from Matthew Elvey. 140 4. Removed "mark" and "unmark" actions. 142 5. Added "hasflag" test. 144 6. Dropped ":globalflags" 146 7. An invalid flag name doesn't cause a script execution failure anymore, 147 as imapflags now depends on variables and a variable can have an arbitrary 148 value. 150 0.9. Changes from the revision 06 (now draft-ietf-sieve-imapflags-00.txt) 152 1. Updated boilerplate and references. 154 2. Fixed capability string in the extended example. 156 3. Improved implementation using macros (section 6). 158 0.10. Changes from draft-ietf-sieve-imapflags-00.txt 160 1. Added back the internal variable, made the variable parameter to all 161 actions optional. 163 2. Some editorial suggestions from Mark E. Mallett. 165 3. Updated boilerplate once again. 167 1. Introduction 169 This is an extension to the Sieve language defined by [SIEVE] for 170 setting [IMAP] flags. It adds a new tagged argument to "keep" and 171 "fileinto" that describes the list of flags that have to be set 172 when the message is delivered to the specified mailbox. It also 173 adds several actions to help manipulate list of flags and a test 174 to check if a flag belongs to a list. 176 Sieve interpreters that don't support integration with IMAP SHOULD 177 ignore this extension. 179 The capability string associated with extension defined in this 180 document is "imap4flags". 182 <> 185 The "imap4flags" extension can be used with or without the "variables" 186 extension [Variables]. When the "variables" extension is also present 187 a script can use explicit variable names in setflag/addflag/removeflag 188 actions. See also section 3 for more details. 189 When the "variables" extension is not present the explicit variable name 190 parameter to setflag/addflag/removeflag MUST NOT be used. 192 2. Conventions used. 194 Conventions for notations are as in [SIEVE] section 1.1, including 195 use of [KEYWORDS] and "Syntax:" label for the definition of action 196 and tagged arguments syntax. 198 2.1. General requirements for flag handling 200 The following notes apply to processing of Addflag and Removeflag actions, 201 hasflag test and :flags tagged argument. 203 A Sieve interpreter MUST ignore empty strings (i.e. "") in a list-of-flags 204 parameter. 206 The Sieve interpreter SHOULD check the list of flags for validity as 207 described by [IMAP] ABNF. In particular non-ASCII characters are not 208 allowed in flag names. However spaces MUST be always allowed and multiple 209 spaces between flag names MUST be treated as a single space character. 210 A string containing a space-separated list of flags is equivalent to a 211 string list consisting of the flags. The last requirement is to simplify 212 amalgamation of multiple flag lists. 214 If a flag validity check fails the flag should be silently 215 ignored, but a warning message SHOULD be logged by the Sieve interpreter. 217 3. Actions 219 All actions described in this specification (setflag, addflag, removeflag) 220 operate on string variables that contain a set of [IMAP] flags. 221 On variable substitution a set of flags is represented as a string 222 containing space-separated list of flag names. 223 <> 225 Note that the parameter specifying a variable name to setflag/addflag/ 226 removeflag actions is optional. If the parameter is not specified 227 the actions operate on the internal variable, which has the empty 228 value when the script starts execution. If the SIEVE interpreter doesn't 229 support the "variables" extension [Variables], the present variable 230 name parameter MUST cause runtime error. 232 The "addflag" action adds flags to an existing set. The "removeflag" 233 action removes flags from an existing set. The "setflag" action 234 replaces an existing set of flags with a new set. The "set" action 235 defined in [Variables] can be used to replace an existing set of flags 236 with a new set as well. 238 The :flags tagged argument to "keep" and "fileinto" 239 actions is used to associate a set of flags referenced by a variable 240 with the current message. If the :flags tagged argument is not specified 241 with those 2 actions, the current value of the internal variable is used 242 instead. The value also applies to the implicit keep. 244 <> 247 3.1. Setflag Action 249 Syntax: setflag [] 251 Setflag is used for setting [IMAP] system flags or keywords. 252 Setflag replaces any previously set flags. 254 Example: if size :over 500K { 255 setflag "flags" "\\Deleted"; 256 } 258 A more substantial example is: 260 Example: 261 if header :contains "from" "boss@frobnitzm.example.edu" { 262 setflag "flagvar" "\\Flagged"; 263 fileinto :flags "${flagvar}" "INBOX.From Boss"; 264 } 266 3.2. Addflag action 268 Syntax: addflag [] 270 Addflag is used to add flags to a list of [IMAP] flags. It doesn't 271 replace any previously set flags. This means that multiple occurrences 272 of addflag are treated additively. The order of the flags MAY NOT 273 be preserved and duplicates are allowed. 275 The following examples demonstrate requirements described in 2.1. 276 The following two actions 278 addflag "flagvar" "\\Deleted"; 279 addflag "flagvar" "\\Answered"; 281 produce the same result as the single action 283 addflag "flagvar" ["\\Deleted", "\\Answered"]; 285 or 287 addflag "flagvar" "\\Deleted \\Answered"; 289 or 291 addflag "flagvar" "\\Answered \\Deleted"; 293 3.3. Removeflag Action 295 Syntax: removeflag [] 297 Removeflag is used to remove flags from a list of [IMAP] flags. 298 Removeflag clears flags previously set by "set"/"addflag". Calling 299 removeflag with a flag that wasn't set before is not an error and 300 is ignored. Note, that if an implementation doesn't perform automatic 301 duplicate elimination, it MUST remove all occurences of the flags 302 specified in the second parameter to removeflag. Empty strings in the 303 list-of-flags MUST be ignored. Also note, that flag names are 304 case-insensitive, as described in [IMAP]. 305 Multiple removeflag actions are treated additively. 307 Example: 308 if header :contains "Disposition-Notification-To" "mel@example.com" { 309 addflag "flagvar" "$MDNRequired"; 310 } 311 if header :contains "from" "imap@cac.washington.example.edu" { 312 removeflag "flagvar" "$MDNRequired"; 313 fileinto :flags "${flagvar}" "INBOX.imap-list"; 314 } 316 4. Test hasflag 318 Syntax: hasflag [MATCH-TYPE] 319 321 The "hasflag" test evaluates to true if any of the variables matches any 322 flag name. The type of match defaults to ":is". 324 Flagname comparisons is always done with the "i;ascii-casemap" operator, 325 i.e., case-insensitive comparisons, as defined in [IMAP]. 327 Note, that if an implementation automatically performs flags reordering 328 and/or duplicate elimination, it MUST perform it on both variable-list 329 values and flag-list values. This is required so that, when the variable 330 "MyFlags" has the value "A B", the following test 332 hasflag :is "MyFlags" "b A" 334 evaluates to true as expected. The above test can be also written as 336 hasflag "MyFlags" ["b","A"] 338 5. Tagged argument :flags 340 This specification adds a new optional tagged argument ":flags" that 341 alter the behavior of actions "keep" and "fileinto". 343 The :flags tagged argument specifies that the flags provided in the 344 subsequent argument should be set when fileinto/keep deliver the message 345 to the target mailbox/user's main mailbox. If the :flags tagged argument 346 is not specified, "keep" or "fileinto" will not set any flag when they 347 deliver the message to the mailbox. 349 Syntax: ":flags" 351 The copy of the message filed into mailbox will have only flags 352 listed after ":flags". 354 The Sieve interpreter MUST ignore all flags that it can't store 355 permanently. This means that the interpreter must not treat failure 356 to store any flag as a runtime failure to execute the Sieve 357 script. For example, if the mailbox "INBOX.From Boss" can't store any 358 flags, then 360 fileinto :flags "\\Deleted" "INBOX.From Boss"; 362 and 364 fileinto "INBOX.From Boss"; 366 are equivalent. 368 This document doesn't dictate how the Sieve interpreter will set 369 the [IMAP] flags. In particular, the Sieve interpreter may work as 370 an IMAP client, or may have direct access to the mailstore. 372 6. Implementation Notes 374 "Addflag " can be implemented as several actions 375 "set "${variable} ", where is a flag in flaglist. 377 A script interpreter MAY reorder flags and remove duplicates from the list. 378 Thus a SIEVE script writer MUST NOT assume that the order or duplicates 379 will be preserved. 381 A "hasflag " test can be implemented as follows: 383 string :matches :comparator "i;ascii-casemap" 384 " ${} " "* *" 386 "setflag [,,...]" can be implemented as 387 follows: 389 set " ... " 391 "addflag " can be implemented as: 393 if not string :matches :comparator "i;ascii-casemap" 394 " ${} " "* *" { 395 set "${} " 396 } 398 "removeflag " can be implemented as: 400 if string :matches :comparator "i;ascii-casemap" " ${} " 401 "* *" { 402 set "${1} ${2}"; 403 } 404 /* Remove any leading space */ 405 if string :matches :comparator "i;ascii-casemap" "${}" 406 " *" { 407 set "${1}"; 408 } 409 /* Remove any trailing space */ 410 if string :matches :comparator "i;ascii-casemap" "${}" 411 "* " { 412 set "${1}"; 413 } 415 7. Interaction with Other Sieve Actions 417 This extension work only on the message that is currently being 418 processed by Sieve, it doesn't affect another message generated 419 as a side affect of any action. 421 The extension decribed in this document doesn't change the implicit 422 keep (see section 2.10.2 of [SIEVE]). 424 8. Other Considerations 426 This extension intentionally doesn't allow setting [IMAP] flags on 427 an arbitrary message in the [IMAP] message store. 429 9. Security Considerations 431 Security considerations are discussed in the [IMAP], [SIEVE] and 432 [Variables]. 433 It is belived that this extension doesn't introduce any additional 434 security concerns. 436 10. Extended example 438 # 439 # Example Sieve Filter 440 # Declare any optional features or extension used by the script 441 # 442 require ["fileinto", "imap4flags", "variables"]; 444 # 445 # Move large messages to special mailbox 446 # 447 if size :over 1M 448 { 449 addflag "MyFlags" "Big"; 450 if header :is "From" "boss@company.example.com" 451 { 452 # The message will be marked as "\Flagged Big" when filed into 453 # mailbox "Big messages" 454 addflag "MyFlags" "\\Flagged"; 455 } 456 fileinto :flags "${MyFlags}" "Big messages"; 457 } 459 if header :is "From" "grandma@example.net" 460 { 461 addflag "MyFlags" ["\\Answered", "$MDNSent"]; 462 # If the message is bigger than 1Mb it will be marked as 463 # "Big \Answered $MDNSent" when filed into mailbox "grandma". 464 # If the message is shorter than 1Mb it will be marked as 465 # "\Answered $MDNSent" 466 fileinto :flags "${MyFlags}" "GrandMa"; # move to "GrandMa" folder 467 } 469 # 470 # Handle messages from known mailing lists 471 # Move messages from IETF filter discussion list to filter folder 472 # 473 if header :is "Sender" "owner-ietf-mta-filters@example.org" 474 { 475 set "MyFlags" "\\Flagged $Work"; 476 # Message will have both "\Flagged" and $Work flags 477 keep :flags "${MyFlags}"; 478 } 480 # 481 # Keep all messages to or from people in my company 482 # 483 elsif anyof address :domain :is ["From", "To"] "company.example.com" 484 { 485 keep :flags "${MyFlags}"; # keep in "Inbox" folder 486 } 487 # 488 # Try and catch unsolicited email. If a message is not to me, 489 # or it contains a subject known to be spam, file it away. 490 # 491 elsif anyof (not address :all :contains 492 ["To", "Cc"] "me@company.example.com", 493 header :matches "subject" 494 ["*make*money*fast*", "*university*dipl*mas*"]) 495 { 496 remove "MyFlags" "\\Flagged"; 497 # If message header does not contain my address, 498 # it's from a list. 499 fileinto :flags "${MyFlags}" "spam"; # move to "spam" folder 500 } 501 else 502 { 503 # Move all other external mail to "personal" 504 # folder. 505 fileinto :flags "${MyFlags}" "personal"; 506 } 508 11. Acknowledgments 510 This document has been revised in part based on comments and 511 discussions which took place on and off the Sieve mailing list. 513 The help of those who took the time to review the draft and make 514 suggestions is appreciated, especially that of Tim Showalter, 515 Barry Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo, 516 Matthew Elvey, Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson, 517 Kjetil Torgrim Homme and Mark E. Mallett. 519 Special thanks to Tony Hansen and David Lamb for helping me 520 better explain the concept. 522 12. Author's Address 524 Alexey Melnikov 525 Isode Limited 527 5 Castle Business Village 528 Hampton, Middlesex 529 United Kingdom, TW12 2BX 531 Email: alexey.melnikov@isode.com 533 13. Normative References 535 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Mirapoint, 536 RFC 3028, January 2001. 538 [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 539 Internet Mail Consortium, RFC 2234, November, 1997. 541 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", Harvard University, RFC 2119, March 1997. 544 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 545 University of Washington, RFC 3501, March 2003. 547 [Variables] Homme, K. T., "Sieve -- Variables Extension", University of 548 Oslo, work in progress, draft-ietf-sieve-variables-XX.txt 550 14. Intellectual Property Statement 552 The IETF takes no position regarding the validity or scope of any 553 Intellectual Property Rights or other rights that might be claimed 554 to pertain to the implementation or use of the technology 555 described in this document or the extent to which any license 556 under such rights might or might not be available; nor does it 557 represent that it has made any independent effort to identify any 558 such rights. Information on the procedures with respect to rights 559 in RFC documents can be found in BCP 78 and BCP 79. 561 Copies of IPR disclosures made to the IETF Secretariat and any 562 assurances of licenses to be made available, or the result of an 563 attempt made to obtain a general license or permission for the use 564 of such proprietary rights by implementers or users of this 565 specification can be obtained from the IETF on-line IPR repository 566 at http://www.ietf.org/ipr. 568 The IETF invites any interested party to bring to its attention 569 any copyrights, patents or patent applications, or other 570 proprietary rights that may cover technology that may be required 571 to implement this standard. Please address the information to the 572 IETF at ietf-ipr@ietf.org. 574 15. Full Copyright Statement 576 Copyright (C) The Internet Society (2005). 578 This document is subject to the rights, licenses and restrictions 579 contained in BCP 78, and except as set forth therein, the authors 580 retain all their rights. 582 This document and the information contained herein are provided on an 583 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 584 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 585 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 586 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 587 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 588 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 590 Acknowledgement 592 Funding for the RFC Editor function is currently provided by the 593 Internet Society.