idnits 2.17.1 draft-melnikov-sieve-imapflags-06.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 586 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 44 instances of too long lines in the document, the longest one being 11 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: ---------------------------------------------------------------------------- == Line 23 has weird spacing: '...listing conta...' == Line 24 has weird spacing: '...ctories on ...' == Line 29 has weird spacing: '...ting or using...' == Line 30 has weird spacing: '...rotocol are S...' == Line 58 has weird spacing: '...) being discu...' == (4 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 (January 2004) is 7405 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 291, but not defined == Unused Reference: 'ABNF' is defined on line 511, 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-homme-sieve-variables-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Variables' Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft: Sieve -- IMAP flag Extension A. Melnikov 4 Document: draft-melnikov-sieve-imapflags-06.txt Isode Limited 5 Expires: July 2004 January 2004 7 Sieve -- IMAP flag Extension 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as 20 reference material or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 The protocol discussed in this document is experimental and subject 29 to change. Persons planning on either implementing or using this 30 protocol are STRONGLY URGED to get in touch with the author before 31 embarking on such a project. 33 Copyright 35 Copyright (C) The Internet Society 2000-2004. All Rights Reserved. 37 Abstract 39 Recent discussions have shown that it is desirable to set different 40 [IMAP] flags on message delivery. This can be done, for example, 41 by a Sieve interpreter that works as a part of a Mail Delivery 42 Agent. 44 This document describes an extension to the Sieve mail filtering 45 language for setting [IMAP] flags. The extension allows to set both 46 [IMAP] system flags and [IMAP] keywords. 48 0. Meta-information on this draft 50 This information is intended to facilitate discussion. It will be 51 removed when this document leaves the Internet-Draft stage. 53 Editorial comments are marked with << and >>. 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. Open issues 67 1. There is no way to specify which flags to set on implicit keep. 68 Is this an issue? 70 2. Do we want to change the extension name, because of incompatible 71 changes with 04 and because 03 was widely deployed? 73 0.3. Changes from the version submitted to the Sieve mailing list 75 1. Added addflag and removeflag actions 77 2. Changed the semantics of setflag (setflag is not additive any 78 more) 80 3. Corrected section "Interaction with Other Sieve Actions". 81 Removed incorrect reference to the forward action as to an 82 action that prohibits setflag. 84 4. Added paragraph about the mutual order of "fileinto"/"keep" and 85 "setflag"/"addflag"/"removeflag" actions. 87 0.4. Changes from the revision 00 89 1. Corrected Capability Identifier section (Section 2) 91 2. Corrected "Interaction with Other Sieve Actions" section 92 (Section 4) 94 3. Examples were updated to be compatible with Sieve-07 draft 96 4. Added "mark" and "unmark" actions 98 0.5. Changes from the revision 01 100 1. Some language fixes based on Tony Hansen comments 102 2. Clarified that the extension allows to set both IMAP System 103 Flags and Keywords 105 0.6. Changes from the revision 02 107 1. BugFix: all backslashes must be escaped 109 2. Added extended example and more detailed description of 110 "addflag"/"removeflag" additivity. 112 3. Minor example bugfixes 114 0.7. Changes from the revision 03 116 1. Added second way to specify flags to be set (via optional tagged 117 arguments). [Tim Showalter] 119 2. Rules for using Reject with imapflags relaxed. [Randall Gellens] 121 3. Removed ABNF section completely, added syntax description to 122 action definition. [Tim Showalter] 124 4. Cleaned up the example. [Ken Murchison] 126 5. Added FM (Flag Manupulation) acronym. 128 6. Clarified "mark"/"unmark" bahavior. [Randall Gellens] 130 0.8. Changes from the revision 04 132 1. "Interaction with Other Sieve Actions" was simplified based on 133 comments from Tim Showalter. Added sentence saying that 134 imapflags doesn't change an implicit keep. 136 2. Several editorial comments from Tim Showalter. 138 0.9. Changes from the revision 05 140 1. Updated copyright, author address, section numbers and references. 142 2. Added dependency on Sieve "variables" extension. 144 3. Several editorial comments from Matthew Elvey. 146 4. Removed "mark" and "unmark" actions. 148 5. Removed "setflag" action. 150 6. Added "hasflag" test. 152 7. Dropped ":globalflags" 154 8. An invalid flag name doesn't cause a script execution failure anymore, 155 as imapflags now depends on variables and a variable can have an arbitrary 156 value. 158 1. Introduction 160 This is an extension to the Sieve language defined by [SIEVE] for 161 setting [IMAP] flags. It adds a new tagged argument to "keep" and 162 "fileinto" that describes the list of flags that have to be set 163 when the message is delivered to the specified mailbox. It also 164 adds several actions to help manipulate list of flags and a test 165 to check if a flag belongs to a list. 167 This extension depends on the presence of "variables" extension 168 [Variables]. 170 Sieve interpreters that don't support integration with IMAP SHOULD 171 ignore this extension. 173 The capability string associated with extension defined in this 174 document is "imap4flags". 176 <> 179 2. Conventions used. 181 Conventions for notations are as in [SIEVE] section 1.1, including 182 use of [KEYWORDS] and "Syntax:" label for the definition of action 183 and tagged arguments syntax. 185 2.1. General requirements for flag handling 187 The following notes apply to processing of Addflag and Removeflag actions, 188 hasflag test and :flags tagged argument. 190 A Sieve interpreter MUST ignore empty strings (i.e. "") in a list-of-flags 191 parameter. 193 The Sieve interpreter SHOULD check the list of flags for validity as described 194 by [IMAP] ABNF. In particular non-ASCII characters are not allowed in 195 flag names. However spaces MUST be always allowed and multiple spaces 196 between flag names MUST be treated as a single space character. A string 197 containing a space separated list of flags is equivalent to a string list 198 consisting of the flags. The last requirement is to simplify amalgamation 199 of multiple flag lists. 201 If a flag validity check fails the flag should be silently 202 dropped, but a warning message should be logged by the Sieve interpreter. 204 3. Actions 206 All actions described in this specification (setflag, addflag, removeflag) 207 operate on string variables that contain a set of [IMAP] flags. 208 On variable substitution a set of flags is represented as a string 209 containing space separated list of flag names. 211 <> 213 The "addflag" action adds flags to an existing set. The "removeflag" 214 action removes flags from an existing set. The "setflag" action 215 replaces an existing set of flags with a new set. The "set" action 216 defined in [Variables] can be used to replaces an existing set of flags 217 with a new set as well. The :flags tagged argument is used to associate 218 a set of flags referenced by a variable with the current message. 220 3.1. Setflag Action 222 Syntax: setflag 224 Setflag is used for setting [IMAP] system flags or 225 keywords. Setflag replaces any previously set flags. 227 Example: if size :over 500K { 228 setflag "flags" "\\Deleted"; 229 } 231 A more substantial example is: 233 Example: 234 if header :contains "from" "boss@frobnitzm.edu" { 235 setflag "flagvar" "\\Flagged"; 236 fileinto :flags "${flagvar}" "INBOX.From Boss"; 237 } 239 3.2. Addflag action 241 Syntax: addflag 243 Addflag is used to add flags to a list of [IMAP] flags. It doesn't 244 replace any previously set flags. This means that multiple occurrences 245 of addflag are treated additively. The order of the flags MAY NOT 246 be preserved and duplicates are allowed. 248 The following examples demonstrate requirements described in 2.1. 249 The following two actions 251 addflag "flagvar" "\\Deleted"; 252 addflag "flagvar" "\\Answered"; 254 produce the same result as the single action 256 addflag "flagvar" ["\\Deleted", "\\Answered"]; 258 or 260 addflag "flagvar" "\\Deleted \\Answered"; 262 or 264 addflag "flagvar" "\\Answered \\Deleted"; 266 3.3. Removeflag Action 268 Syntax: removeflag 270 Removeflag is used to remove flags from a list of [IMAP] flags. 271 Removeflag clears flags previously set by "set"/"addflag". Calling 272 removeflag with a flag that wasn't set before is not an error and 273 is ignored. Note, that if an implementation doesn't perform automatic 274 duplicate elimination, it MUST remove all occurences of the flags 275 specified in the second parameter to removeflag. Empty strings in the 276 list-of-flags MUST be ignored. Also note, that flag names are 277 case-insensitive, as described in [IMAP]. 278 Multiple removeflag actions are treated additively. 280 Example: 281 if header :contains "Disposition-Notification-To" "mel@example.com" { 282 addflag "flagvar" "$MDNRequired"; 283 } 284 if header :contains "from" "imap@cac.washington.edu" { 285 removeflag "flagvar" "$MDNRequired"; 286 fileinto :flags "${flagvar}" "INBOX.imap-list"; 287 } 289 4. Test hasflag 291 Syntax: hasflag [MATCH-TYPE] 292 294 The "hasflag" test evaluates to true if any of the variables matches any 295 flag name. The type of match defaults to ":is". 297 Flagname comparisons is always done with the "i;ascii-casemap" operator, 298 i.e., case-insensitive comparisons, as defined in [IMAP]. 300 Note, that if an implementation automatically performs flags reordering 301 and/or duplicate elimination, it MUST perform it on both variable-list 302 values and flag-list values. This is required so that, when the variable 303 "MyFlags" has the value "A B", the following test 305 hasflag :is "MyFlags" "b A" 307 evaluates to true as expected. The above test can be also written as 309 hasflag "MyFlags" ["b","A"] 311 5. Tagged argument :flags 313 This specification adds a new optional tagged argument ":flags" that 314 alter the behavior of actions "keep" and "fileinto". 316 The :flags tagged argument specifies that the flags provided in the 317 subsequent argument should be set when fileinto/keep deliver the message 318 to the target mailbox/user's main mailbox. If the :flags tagged argument 319 is not specified, "keep" or "fileinto" will not set any flag when they 320 deliver the message to the mailbox. 322 Syntax: ":flags" 324 The copy of the message filed into mailbox will have only flags 325 listed after ":flags". 327 The Sieve interpreter MUST ignore all flags that it can't store 328 permanently. This means that the interpreter must not treat failure 329 to store any flag as a runtime failure to execute the Sieve 330 script. For example, if the mailbox "INBOX.From Boss" can't store any 331 flags, then 333 fileinto :flags "\\Deleted" "INBOX.From Boss"; 335 and 337 fileinto "INBOX.From Boss"; 339 are equivalent. 341 This document doesn't dictate how the Sieve interpreter will set 342 the [IMAP] flags. In particular, the Sieve interpreter may work as 343 an IMAP client, or may have direct access to the mailstore. 345 6. Implementation Notes 347 "Addflag " can be implemented as several actions 348 "set "${variable} ", where is a flag in flaglist. 350 A script interpreter MAY reorder flags and remove duplicates from the list. 351 A SIEVE script write MUST NOT assume that the order or duplicates will be 352 preserved. 354 << 355 A "hasflag " test can be implemented as follows: 357 anyof (string :is :comparator "i;ascii-casemap" "" "", 358 /* a flag is in the middle */ 359 string :matches :comparator "i;ascii-casemap" "" "* *", 360 /* a flag is the first in the list */ 361 string :matches :comparator "i;ascii-casemap" "" " *", 362 /* a flag is the last in the list */ 363 string :matches :comparator "i;ascii-casemap" "" "* ") 365 "Setflag [,,...]" can be implemented as follows: 367 set "${} ${} ... ${}" 369 "Removeflag " can be implemented as (note that this version 370 doesn't remove duplicated flags): 372 if string :is :comparator "i;ascii-casemap" "" "" { 373 set ""; 374 } 375 /* a flag is in the middle */ 376 elsif string :matches :comparator "i;ascii-casemap" "" "* *" { 377 set "${1}${2}"; 378 } 379 /* a flag is the first in the list */ 380 elsif string :matches :comparator "i;ascii-casemap" "" " *" { 381 set "${1}"; 382 } 383 /* a flag is the last in the list */ 384 elsif string :matches :comparator "i;ascii-casemap" "" "* " { 385 set "${1}"; 386 } 387 >> 389 7. Interaction with Other Sieve Actions 391 This extension work only on the message that is currently being 392 processed by Sieve, it doesn't affect another message generated 393 as a side affect of any action. 395 The extension decribed in this document doesn't change an implicit 396 keep (see section 2.10.2 of [SIEVE]). 398 8. Other Considerations 400 This extension intentionally doesn't allow setting [IMAP] flags on 401 an arbitrary message in the [IMAP] message store. 403 9. Security Considerations 405 Security considerations are discussed in the [IMAP] and [SIEVE]. 406 It is belived that this extension doesn't introduce any additional 407 security concerns. 409 10. Extended example 411 # 412 # Example Sieve Filter 413 # Declare any optional features or extension used by the script 414 # 415 require ["fileinto", "imapflags", "variables"]; 417 # 418 # Move large messages to special mailbox 419 # 420 if size :over 1M 421 { 422 addflag "MyFlags" "Big"; 423 if header :is "From" "boss@company.com" 424 { 425 # The message will be marked as "\Flagged Big" when filed into 426 # mailbox "Big messages" 427 addflag "MyFlags" "\\Flagged"; 428 } 429 fileinto :flags "${MyFlags}" "Big messages"; 430 } 432 if header :is "From" "grandma@example.net" 433 { 434 addflag "MyFlags" ["\\Answered", "$MDNSent"]; 435 # If the message is bigger than 1Mb it will be marked as 436 # "Big \Answered $MDNSent" when filed into mailbox "grandma". 437 # If the message is shorter than 1Mb it will be marked as 438 # "\Answered $MDNSent" 439 fileinto :flags "${MyFlags}" "GrandMa"; # move to "GrandMa" folder 440 } 442 # 443 # Handle messages from known mailing lists 444 # Move messages from IETF filter discussion list to filter folder 445 # 446 if header :is "Sender" "owner-ietf-mta-filters@imc.org" 447 { 448 set "MyFlags" "\\Flagged $Work"; 449 # Message will have both "\Flagged" and $Work flags 450 keep :flags "${MyFlags}"; 451 } 453 # 454 # Keep all messages to or from people in my company 455 # 456 elsif anyof address :domain :is ["From", "To"] "company.com" 457 { 458 keep :flags "${MyFlags}"; # keep in "Inbox" folder 459 } 460 # 461 # Try and catch unsolicited email. If a message is not to me, 462 # or it contains a subject known to be spam, file it away. 463 # 464 elsif anyof (not address :all :contains 465 ["To", "Cc"] "me@company.com", 466 header :matches "subject" 467 ["*make*money*fast*", "*university*dipl*mas*"]) 468 { 469 remove "MyFlags" "\\Flagged"; 470 # If message header does not contain my address, 471 # it's from a list. 472 fileinto :flags "${MyFlags}" "spam"; # move to "spam" folder 473 } 474 else 475 { 476 # Move all other (non-company) mail to "personal" 477 # folder. 478 fileinto :flags "${MyFlags}" "personal"; 479 } 481 11. Acknowledgments 483 This document has been revised in part based on comments and 484 discussions which took place on and off the Sieve mailing list. 486 The help of those who took the time to review the draft and make 487 suggestions is appreciated, especially that of Tim Showalter, 488 Barry Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo, 489 Matthew Elvey, Jutta Degener, Ned Freed, Marc Mutz, Nigel Swinson 490 and Kjetil Torgrim Homme. 492 Special thanks to Tony Hansen and David Lamb for helping me 493 better explain the concept. 495 12. Author's Address 497 Alexey Melnikov 498 Isode Limited 500 5 Castle Business Village 501 Hampton, Middlesex 502 United Kingdom, TW12 2BX 504 Email: alexey.melnikov@isode.com 506 13. Normative References 508 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Mirapoint, 509 RFC 3028, January 2001. 511 [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 512 Internet Mail Consortium, RFC 2234, November, 1997. 514 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", Harvard University, RFC 2119, March 1997. 517 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 518 University of Washington, RFC 3501, March 2003. 520 [Variables] Homme, K. T., "Sieve -- Variables Extension", University of 521 Oslo, work in progress, draft-homme-sieve-variables-XX.txt 523 14. Full Copyright Statement 525 Copyright (C) The Internet Society 2000-2004. All Rights Reserved. 527 This document and translations of it may be copied and furnished to 528 others, and derivative works that comment on or otherwise explain it 529 or assist in its implementation may be prepared, copied, published 530 and distributed, in whole or in part, without restriction of any 531 kind, provided that the above copyright notice and this paragraph 532 are included on all such copies and derivative works. However, this 533 document itself may not be modified in any way, such as by removing 534 the copyright notice or references to the Internet Society or other 535 Internet organizations, except as needed for the purpose of 536 developing Internet standards in which case the procedures for 537 copyrights defined in the Internet Standards process must be 538 followed, or as required to translate it into languages other than 539 English. 541 The limited permissions granted above are perpetual and will not be 542 revoked by the Internet Society or its successors or assigns. 544 This document and the information contained herein is provided on an 545 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 546 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 547 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 548 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 549 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 551 Acknowledgement 553 Funding for the RFC Editor function is currently provided by the 554 Internet Society.