idnits 2.17.1 draft-ietf-sieve-imapflags-02.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 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 555. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 559), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 605 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 45 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 58 has weird spacing: '...) being discu...' == Line 59 has weird spacing: '...ription reque...' == Line 60 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 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 2005) is 6768 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 346, but not defined ** Obsolete normative reference: RFC 3028 (ref. 'SIEVE') (Obsoleted by RFC 5228, RFC 5429) ** 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 (~~), 11 warnings (==), 10 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-02.txt Isode Limited 4 Expires: April 2006 October 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 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 0.1. Discussion 57 This draft defines an extension to the Sieve mail filtering 58 language (RFC 3028) being discussed on the MTA Filters 59 mailing list at . Subscription requests 60 can be sent to (send an email 61 message with the word "subscribe" in the body). More information on 62 the mailing list along with a WWW archive of back messages is 63 available at . 65 0.2. Changes from the version submitted to the Sieve mailing list 67 1. Added addflag and removeflag actions 69 2. Changed the semantics of setflag (setflag is not additive any 70 more) 72 3. Corrected section "Interaction with Other Sieve Actions". 73 Removed incorrect reference to the forward action as to an 74 action that prohibits setflag. 76 4. Added paragraph about the mutual order of "fileinto"/"keep" and 77 "setflag"/"addflag"/"removeflag" actions. 79 0.3. Changes from the revision 00 81 1. Corrected Capability Identifier section (Section 2) 83 2. Corrected "Interaction with Other Sieve Actions" section 84 (Section 4) 86 3. Examples were updated to be compatible with Sieve-07 draft 88 4. Added "mark" and "unmark" actions 90 0.4. Changes from the revision 01 92 1. Some language fixes based on Tony Hansen comments 94 2. Clarified that the extension allows to set both IMAP System 95 Flags and Keywords 97 0.5. Changes from the revision 02 99 1. BugFix: all backslashes must be escaped 101 2. Added extended example and more detailed description of 102 "addflag"/"removeflag" additivity. 104 3. Minor example bugfixes 106 0.6. Changes from the revision 03 108 1. Added second way to specify flags to be set (via optional tagged 109 arguments). [Tim Showalter] 111 2. Rules for using Reject with imapflags relaxed. [Randall Gellens] 113 3. Removed ABNF section completely, added syntax description to 114 action definition. [Tim Showalter] 116 4. Cleaned up the example. [Ken Murchison] 118 5. Added FM (Flag Manupulation) acronym. 120 6. Clarified "mark"/"unmark" bahavior. [Randall Gellens] 122 0.7. Changes from the revision 04 124 1. "Interaction with Other Sieve Actions" was simplified based on 125 comments from Tim Showalter. Added sentence saying that 126 imapflags doesn't change an implicit keep. 128 2. Several editorial comments from Tim Showalter. 130 0.8. Changes from the revision 05 132 1. Updated copyright, author address, section numbers and references. 134 2. Added dependency on Sieve "variables" extension. 136 3. Several editorial comments from Matthew Elvey. 138 4. Removed "mark" and "unmark" actions. 140 5. Added "hasflag" test. 142 6. Dropped ":globalflags" 144 7. An invalid flag name doesn't cause a script execution failure anymore, 145 as imapflags now depends on variables and a variable can have an arbitrary 146 value. 148 0.9. Changes from the revision 06 (now draft-ietf-sieve-imapflags-00.txt) 150 1. Updated boilerplate and references. 152 2. Fixed capability string in the extended example. 154 3. Improved implementation using macros (section 6). 156 0.10. Changes from draft-ietf-sieve-imapflags-00.txt 158 1. Added back the internal variable, made the variable parameter to all 159 actions optional. 161 2. Some editorial suggestions from Mark E. Mallett. 163 3. Updated boilerplate once again. 165 0.11. Changes from draft-ietf-sieve-imapflags-01.txt 167 1. Clarified that if "variables" is not available, then usage of 168 the explicit variable parameter causes a runtime error. 170 2. Clarified handling of spaces, in particular that leading/ 171 trailing spaces in a flag variable are to be ignored. 173 3. Clarified that the extension can't be used to set the \Recent flag. 175 4. Made the variable list parameter to hasflag test optional, for 176 consistency with all actions. 178 5. Dropped the "Implementation Notes" section. 180 6. Fixed an error in section 5: when the :flags tagged argument is not 181 specified, the correct behavior is to use flags from the internal 182 variable. 184 7. Other minor editorial changes. 186 1. Introduction 188 This is an extension to the Sieve language defined by [SIEVE] for 189 setting [IMAP] flags. It adds a new tagged argument to "keep" and 190 "fileinto" that describes the list of flags that have to be set 191 when the message is delivered to the specified mailbox. It also 192 adds several actions to help manipulate list of flags and a test 193 to check if a flag belongs to a list. 195 Sieve interpreters that don't support integration with IMAP SHOULD 196 ignore this extension. 198 The capability string associated with extension defined in this 199 document is "imap4flags". 201 The "imap4flags" extension can be used with or without the "variables" 202 extension [VARIABLES]. When the "variables" extension is enabled in 203 a script using , the script can use explicit 204 variable names in setflag/addflag/removeflag actions. See also section 205 3 for more details. When the "variables" extension is not enabled 206 the explicit variable name parameter to setflag/addflag/removeflag 207 MUST NOT be used and MUST cause an error according to [SIEVE]. 209 2. Conventions used. 211 Conventions for notations are as in [SIEVE] section 1.1, including 212 use of [KEYWORDS] and "Syntax:" label for the definition of action 213 and tagged arguments syntax. 215 2.1. General requirements for flag handling 217 The following notes apply to processing of Addflag and Removeflag actions, 218 hasflag test and :flags tagged argument. 220 A Sieve interpreter MUST ignore empty strings (i.e. "") in a list-of-flags 221 parameter. 223 The Sieve interpreter SHOULD check the list of flags for validity as 224 described by [IMAP] ABNF. In particular non-ASCII characters are not 225 allowed in flag names. However spaces MUST be always allowed. Multiple 226 spaces between flag names MUST be treated as a single space character, 227 leading and trailing spaces MUST be ignored. 228 A string containing a space-separated list of flags is equivalent to a 229 string list consisting of the flags. The last requirement is to simplify 230 amalgamation of multiple flag lists. 232 If a flag validity check fails the flag MUST be ignored. 234 Note that it is not possible to use this extension to set or clear the 235 \Recent flag or any other special system flag which is not settable 236 in [IMAP]. Any such flags MUST be ignored if included in a flag list. 238 3. Actions 240 All actions described in this specification (setflag, addflag, removeflag) 241 operate on string variables that contain a set of [IMAP] flags. 242 On variable substitution a set of flags is represented as a string 243 containing space-separated list of flag names. 245 Any of setflag/addflag/removeflag action MAY alter the flag list in any 246 way that leaves its semantics as a set of case-insensitive words unaltered. 247 For example, it may reorder the flags, alter the case of the letters in 248 them, or add or remove duplicates or extraneous spaces. Scripts 249 MUST NOT make assumptions about the ordering of flags in lists or 250 the preservation of their case. 252 Note that the parameter specifying a variable name to setflag/addflag/ 253 removeflag actions and the hasflag test is optional. If the parameter 254 is not specified the actions operate on the internal variable, which 255 has the empty value when the script starts execution. If the SIEVE 256 interpreter doesn't support the "variables" extension [VARIABLES], 257 the present variable name parameter MUST cause runtime error. 259 The "addflag" action adds flags to an existing set. The "removeflag" 260 action removes flags from an existing set. The "setflag" action 261 replaces an existing set of flags with a new set. The "set" action 262 defined in [VARIABLES] can be used to replace an existing set of flags 263 with a new set as well. However it should be noted that the "set" 264 action can't perform any flag reordering, duplicate elimination, etc. 266 The :flags tagged argument to "keep" and "fileinto" 267 actions is used to associate a set of flags referenced by a variable 268 with the current message. If the :flags tagged argument is not specified 269 with those 2 actions, the current value of the internal variable is used 270 instead. The value also applies to the implicit keep. 272 Note that when keep/fileinto is used multiple times in a script and 273 duplicate message elimination is performed, the last flag list value MUST 274 win. 276 3.1. Setflag Action 278 Syntax: setflag [] 280 Setflag is used for setting [IMAP] system flags or keywords. 281 Setflag replaces any previously set flags. 283 Example: if size :over 500K { 284 setflag "flags" "\\Deleted"; 285 } 287 A more substantial example is: 289 Example: 290 if header :contains "from" "boss@frobnitzm.example.edu" { 291 setflag "flagvar" "\\Flagged"; 292 fileinto :flags "${flagvar}" "INBOX.From Boss"; 293 } 295 3.2. Addflag action 297 Syntax: addflag [] 299 Addflag is used to add flags to a list of [IMAP] flags. It doesn't 300 replace any previously set flags. This means that multiple occurrences 301 of addflag are treated additively. 303 The following examples demonstrate requirements described in 2.1. 304 The following two actions 306 addflag "flagvar" "\\Deleted"; 307 addflag "flagvar" "\\Answered"; 309 produce the same result as the single action 311 addflag "flagvar" ["\\Deleted", "\\Answered"]; 313 or 315 addflag "flagvar" "\\Deleted \\Answered"; 317 or 319 addflag "flagvar" "\\Answered \\Deleted"; 321 3.3. Removeflag Action 323 Syntax: removeflag [] 325 Removeflag is used to remove flags from a list of [IMAP] flags. 326 Removeflag clears flags previously set by "set"/"addflag". Calling 327 removeflag with a flag that wasn't set before is not an error and 328 is ignored. Note, that if an implementation doesn't perform automatic 329 duplicate elimination, it MUST remove all occurences of the flags 330 specified in the second parameter to removeflag. Empty strings in the 331 list-of-flags MUST be ignored. Also note, that flag names are 332 case-insensitive, as described in [IMAP]. 333 Multiple removeflag actions are treated additively. 335 Example: 336 if header :contains "Disposition-Notification-To" "mel@example.com" { 337 addflag "flagvar" "$MDNRequired"; 338 } 339 if header :contains "from" "imap@cac.washington.example.edu" { 340 removeflag "flagvar" "$MDNRequired"; 341 fileinto :flags "${flagvar}" "INBOX.imap-list"; 342 } 344 4. Test hasflag 346 Syntax: hasflag [MATCH-TYPE] 347 [] 349 The "hasflag" test evaluates to true if any of the variables matches any 350 flag name. The type of match defaults to ":is". 351 If the list of variables is omitted, value of the internal variable is 352 used instead. 354 Flagname comparisons is always done with the "i;ascii-casemap" operator, 355 i.e., case-insensitive comparisons, as defined in [IMAP]. 357 Example: 358 If the variable "MyFlags" has the value "A B", the following test 360 hasflag :is "MyFlags" "b A" 362 evaluates to true. The above test can be also written as 364 hasflag "MyFlags" ["b","A"] 366 5. Tagged argument :flags 368 This specification adds a new optional tagged argument ":flags" that 369 alter the behavior of actions "keep" and "fileinto". 371 The :flags tagged argument specifies that the flags provided in the 372 subsequent argument should be set when fileinto/keep deliver the message 373 to the target mailbox/user's main mailbox. If the :flags tagged argument 374 is not specified, "keep" or "fileinto" will use the current value of the 375 internal variable when delivering message to the target mailbox. 377 Syntax: ":flags" 379 The copy of the message filed into mailbox will have only flags 380 listed after ":flags". 382 The Sieve interpreter MUST ignore all flags that it can't store 383 permanently. This means that the interpreter must not treat failure 384 to store any flag as a runtime failure to execute the Sieve 385 script. For example, if the mailbox "INBOX.From Boss" can't store any 386 flags, then 388 fileinto :flags "\\Deleted" "INBOX.From Boss"; 390 and 392 fileinto "INBOX.From Boss"; 394 are equivalent. 396 This document doesn't dictate how the Sieve interpreter will set 397 the [IMAP] flags. In particular, the Sieve interpreter may work as 398 an IMAP client, or may have direct access to the mailstore. 400 6. Interaction with Other Sieve Actions 402 This extension work only on the message that is currently being 403 processed by Sieve, it doesn't affect another message generated 404 as a side affect of any action. 406 The extension decribed in this document doesn't change the implicit 407 keep (see section 2.10.2 of [SIEVE]). 409 7. Other Considerations 411 This extension intentionally doesn't allow setting [IMAP] flags on 412 an arbitrary message in the [IMAP] message store. 414 8. Security Considerations 416 Security considerations are discussed in the [IMAP], [SIEVE] and 417 [VARIABLES]. 418 It is believed that this extension doesn't introduce any additional 419 security concerns. 421 9. Extended example 423 # 424 # Example Sieve Filter 425 # Declare any optional features or extension used by the script 426 # 427 require ["fileinto", "imap4flags", "variables"]; 429 # 430 # Move large messages to special mailbox 431 # 432 if size :over 1M 433 { 434 addflag "MyFlags" "Big"; 435 if header :is "From" "boss@company.example.com" 436 { 437 # The message will be marked as "\Flagged Big" when filed into 438 # mailbox "Big messages" 439 addflag "MyFlags" "\\Flagged"; 440 } 441 fileinto :flags "${MyFlags}" "Big messages"; 442 } 444 if header :is "From" "grandma@example.net" 445 { 446 addflag "MyFlags" ["\\Answered", "$MDNSent"]; 447 # If the message is bigger than 1Mb it will be marked as 448 # "Big \Answered $MDNSent" when filed into mailbox "grandma". 449 # If the message is shorter than 1Mb it will be marked as 450 # "\Answered $MDNSent" 451 fileinto :flags "${MyFlags}" "GrandMa"; # move to "GrandMa" folder 452 } 454 # 455 # Handle messages from known mailing lists 456 # Move messages from IETF filter discussion list to filter folder 457 # 458 if header :is "Sender" "owner-ietf-mta-filters@example.org" 459 { 460 set "MyFlags" "\\Flagged $Work"; 461 # Message will have both "\Flagged" and $Work flags 462 keep :flags "${MyFlags}"; 463 } 465 # 466 # Keep all messages to or from people in my company 467 # 468 elsif anyof address :domain :is ["From", "To"] "company.example.com" 469 { 470 keep :flags "${MyFlags}"; # keep in "Inbox" folder 471 } 472 # 473 # Try and catch unsolicited email. If a message is not to me, 474 # or it contains a subject known to be spam, file it away. 475 # 476 elsif anyof (not address :all :contains 477 ["To", "Cc"] "me@company.example.com", 478 header :matches "subject" 479 ["*make*money*fast*", "*university*dipl*mas*"]) 480 { 481 remove "MyFlags" "\\Flagged"; 482 # If message header does not contain my address, 483 # it's from a list. 484 fileinto :flags "${MyFlags}" "spam"; # move to "spam" folder 485 } 486 else 487 { 488 # Move all other external mail to "personal" 489 # folder. 490 fileinto :flags "${MyFlags}" "personal"; 491 } 493 10. Acknowledgments 495 This document has been revised in part based on comments and 496 discussions which took place on and off the Sieve mailing list. 498 The help of those who took the time to review the draft and make 499 suggestions is appreciated, especially that of Tim Showalter, 500 Barry Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo, 501 Matthew Elvey, Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson, 502 Kjetil Torgrim Homme, Mark E. Mallett, Dave Cridland, 503 Arnt Gulbrandsen and Philip Guenther. 505 Special thanks to Tony Hansen and David Lamb for helping me 506 better explain the concept. 508 11. Author's Address 510 Alexey Melnikov 511 Isode Limited 513 5 Castle Business Village 514 Hampton, Middlesex 515 United Kingdom, TW12 2BX 517 Email: alexey.melnikov@isode.com 519 12. Normative References 521 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Mirapoint, 522 RFC 3028, January 2001. 524 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", Harvard University, RFC 2119, March 1997. 527 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 528 University of Washington, RFC 3501, March 2003. 530 [VARIABLES] Homme, K. T., "Sieve -- Variables Extension", University of 531 Oslo, work in progress, draft-ietf-sieve-variables-XX.txt 533 13. Intellectual Property Statement 535 The IETF takes no position regarding the validity or scope of any 536 Intellectual Property Rights or other rights that might be claimed 537 to pertain to the implementation or use of the technology 538 described in this document or the extent to which any license 539 under such rights might or might not be available; nor does it 540 represent that it has made any independent effort to identify any 541 such rights. Information on the procedures with respect to rights 542 in RFC documents can be found in BCP 78 and BCP 79. 544 Copies of IPR disclosures made to the IETF Secretariat and any 545 assurances of licenses to be made available, or the result of an 546 attempt made to obtain a general license or permission for the use 547 of such proprietary rights by implementers or users of this 548 specification can be obtained from the IETF on-line IPR repository 549 at http://www.ietf.org/ipr. 551 The IETF invites any interested party to bring to its attention 552 any copyrights, patents or patent applications, or other 553 proprietary rights that may cover technology that may be required 554 to implement this standard. Please address the information to the 555 IETF at ietf-ipr@ietf.org. 557 14. Full Copyright Statement 559 Copyright (C) The Internet Society (2005). 561 This document is subject to the rights, licenses and restrictions 562 contained in BCP 78, and except as set forth therein, the authors 563 retain all their rights. 565 This document and the information contained herein are provided on an 566 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 567 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 568 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 569 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 570 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 571 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 573 Acknowledgement 575 Funding for the RFC Editor function is currently provided by the 576 Internet Society.