idnits 2.17.1 draft-melnikov-sieve-imapflags-05.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 505 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 29 instances of too long lines in the document, the longest one being 6 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 22 has weird spacing: '...listing conta...' == Line 23 has weird spacing: '...ctories on ...' == Line 28 has weird spacing: '...ting or using...' == Line 29 has weird spacing: '...rotocol are S...' == Line 57 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 (June 2003) is 7621 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 243, but not defined == Unused Reference: 'ABNF' is defined on line 434, 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. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft: Sieve -- IMAP flag Extension A. Melnikov 3 Document: draft-melnikov-sieve-imapflags-05.txt Isode Limited 4 Expires: December 2003 June 2003 6 Sieve -- IMAP flag Extension 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 The protocol discussed in this document is experimental and subject 28 to change. Persons planning on either implementing or using this 29 protocol are STRONGLY URGED to get in touch with the author before 30 embarking on such a project. 32 Copyright 34 Copyright (C) The Internet Society 2000-2003. All Rights Reserved. 36 Abstract 38 Recent discussions have shown that it is desirable to set different 39 [IMAP] flags on message delivery. This can be done, for example, 40 by a Sieve interpreter that works as a part of a Mail Delivery 41 Agent. 43 This document describes an extension to the Sieve mail filtering 44 language for setting [IMAP] flags. The extension allows to set both 45 [IMAP] system flags and [IMAP] keywords. 47 0. Meta-information on this draft 49 This information is intended to facilitate discussion. It will be 50 removed when this document leaves the Internet-Draft stage. 52 Editorial comments are marked with << and >>. 54 0.1. Discussion 56 This draft defines an extension to the Sieve mail filtering 57 language (RFC 3028) being discussed on the MTA Filters 58 mailing list at . Subscription requests 59 can be sent to (send an email 60 message with the word "subscribe" in the body). More information on 61 the mailing list along with a WWW archive of back messages is 62 available at . 64 0.2. Open issues 66 1. There is no way to specify which flags to set on implicit keep. 67 Is this an issue? 69 0.3. Changes from the version submitted to the Sieve mailing list 71 1. Added addflag and removeflag actions 73 2. Changed the semantics of setflag (setflag is not additive any 74 more) 76 3. Corrected section "Interaction with Other Sieve Actions". 77 Removed incorrect reference to the forward action as to an 78 action that prohibits setflag. 80 4. Added paragraph about the mutual order of "fileinto"/"keep" and 81 "setflag"/"addflag"/"removeflag" actions. 83 0.4. Changes from the revision 00 85 1. Corrected Capability Identifier section (Section 2) 87 2. Corrected "Interaction with Other Sieve Actions" section 88 (Section 4) 90 3. Examples were updated to be compatible with Sieve-07 draft 92 4. Added "mark" and "unmark" actions 94 0.5. Changes from the revision 01 96 1. Some language fixes based on Tony Hansen comments 98 2. Clarified that the extension allows to set both IMAP System 99 Flags and Keywords 101 0.6. Changes from the revision 02 103 1. BugFix: all backslashes must be escaped 105 2. Added extended example and more detailed description of 106 "addflag"/"removeflag" additivity. 108 3. Minor example bugfixes 110 0.7. Changes from the revision 03 112 1. Added second way to specify flags to be set (via optional tagged 113 arguments). [Tim Showalter] 115 2. Rules for using Reject with imapflags relaxed. [Randall Gellens] 117 3. Removed ABNF section completely, added syntax description to 118 action definition. [Tim Showalter] 120 4. Cleaned up the example. [Ken Murchison] 122 5. Added FM (Flag Manupulation) acronym. 124 6. Clarified "mark"/"unmark" bahavior. [Randall Gellens] 126 0.8. Changes from the revision 04 128 1. "Interaction with Other Sieve Actions" was simplified based on 129 comments from Tim Showalter. Added sentence saying that 130 imapflags doesn't change an implicit keep. 132 2. Several editorial comments from Tim Showalter. 134 0.9. Changes from the revision 05 136 1. Updated copyright, author address, section numbers and references. 138 2. Several editorial comments from Matthew Elvey. 140 3. Removed "mark" and "unmark" actions. 142 4. Removed "setflag" action. 144 5. Added "hasflag" test. 146 1. Introduction 148 This is an extension to the Sieve language defined by [SIEVE] for 149 setting [IMAP] flags. It adds a new tagged argument to "keep" and 150 "fileinto" that describes the list of flags that have to be set 151 when the message is delivered to the specified mailbox. It also 152 adds several actions to help manipulate list of flags and a test 153 to check if a flag belongs to a list. 155 This extension depends on the presence of "variables" extension 156 [Variables]. 158 Sieve interpreters that don't support integration with IMAP SHOULD 159 ignore this extension. 161 The capability string associated with extension defined in this 162 document is "imapflags". 164 <> 166 2. Conventions used. 168 Conventions for notations are as in [SIEVE] section 1.1, including 169 use of [KEYWORDS] and "Syntax:" label for the definition of action 170 and tagged arguments syntax. 172 3. Actions 174 All actions described in this specification (addflag, removeflag) 175 operate on string variables that contain a set of [IMAP] flags. 176 On variable substitution a set of flags is represented as a string 177 containing space separated list of flag names. 178 The "addflag" action adds flags to an existing set. The "removeflag" 179 action removes flags from an existing set. The "set" action defined in 180 [Variables] can be used to replaces an existing set of flags with a 181 new set. The :flags tagged argument is used to associate a set of flags 182 referenced by a variable with the current message. 184 <> 186 3.1. Addflag action 188 Syntax: addflag 190 Addflag is used to add flags to a list of [IMAP] flags. It doesn't 191 replace any previously set flags. This means that multiple occurrences 192 of addflag are treated additively. The order of the flags MAY NOT 193 be preserved and duplicates are allowed. 195 Addflag SHOULD check the list of flags for validity as described by 196 [IMAP] ABNF. In particular non-ASCII characters are not allowed in 197 flag names. However spaces MUST be always allowed and multiple spaces 198 between flag names MUST be treated as a single space character. The 199 last requirement is to simplify amalgamation of multiple flag lists. 201 For example, the following two actions 203 addflag "flagvar" "\\Deleted"; 204 addflag "flagvar" "\\Answered"; 206 produce the same result as the single action 208 addflag "flagvar" ["\\Deleted", "\\Answered"]; 210 or 212 addflag "flagvar" "\\Deleted \\Answered"; 214 or 216 addflag "flagvar" "\\Answered \\Deleted"; 218 3.2. Removeflag Action 220 Syntax: removeflag 222 Removeflag is used to remove flags from a list of [IMAP] flags. 223 Removeflag clears flags previously set by "set"/"addflag". Calling 224 removeflag with a flag that wasn't set before is not an error and 225 is ignored. Multiple occurrences of removeflag are treated additively. 227 Removeflag SHOULD check the list of flags for validity as described by 228 [IMAP] ABNF. In particular non-ASCII characters are not allowed in 229 flag names. However spaces MUST be always allowed and multiple spaces 230 between flag names MUST be treated as a single space character. 232 Example: 233 if header :contains "Disposition-Notification-To" "mel@example.com" { 234 addflag "flagvar" "$MDNRequired"; 235 } 236 if header :contains "from" "imap@cac.washington.edu" { 237 removeflag "flagvar" "$MDNRequired"; 238 fileinto :globalflags "INBOX.imap-list"; 239 } 241 4. Test hasflag 243 Syntax: hasflag [MATCH-TYPE] 244 246 The "hasflag" test evaluates to true if any of the variables matches any 247 flag name. The type of match defaults to ":is". 249 Flagname comparisons is always done with the "i;ascii-casemap" operator, 250 i.e., case-insensitive comparisons, as defined in [IMAP]. 252 Note, that if an implementation automatically performs flags reordering 253 and/or duplicate elimination, it MUST perform it on both variable-list 254 values and flag-list values. This is required so that, when the variable 255 "flags" has the value "A B", the following test 257 hasflag :is "flags" "b A" 259 evaluates to true as expected. 261 5. Tagged argument - :flags 263 This specification adds a new optional tagged argument ":flags" that 264 alter the behavior of actions "keep" and "fileinto". 266 The :flags tagged argument specifies that the flags provided in the 267 subsequent argument should be set when fileinto/keep deliver the message 268 to the target mailbox/user's main mailbox. If the :flags tagged argument 269 is not specified, "keep" or "fileinto" will not set any flag when they 270 deliver the message to the mailbox. 272 Syntax: ":flags" 274 The copy of the message filed into mailbox will have only flags 275 listed after ":flags". 277 The Sieve interpreter MUST check that all flag names are valid [IMAP] flag 278 names and MUST signal a script execution error if they are not. The Sieve 279 interpreter MUST ignore all flags that it can't store 280 permanently. This means that the interpreter must not treat failure 281 to store any flag as a runtime failure to execute the Sieve 282 script. For example, if the mailbox "INBOX.From Boss" can't store any 283 flags, then 285 fileinto :flags "\\Deleted" "INBOX.From Boss"; 287 and 289 fileinto "INBOX.From Boss"; 291 are equivalent. 293 This document doesn't dictate how the Sieve interpreter will set 294 the [IMAP] flags. In particular, the Sieve interpreter may work as 295 an IMAP client, or may have direct access to the mailstore. 297 <> 302 6. Implementation Notes 304 "Addflag " can be implemented as several actions 305 "set "${variable} ", where is a flag in flaglist. 307 A script interpreter MAY reorder flags and remove duplicates from the list. 308 A SIEVE script write MUST NOT assume that the order or duplicates will be 309 preserved. 311 <> 313 7. Interaction with Other Sieve Actions 315 This extension work only on the message that is currently being 316 processed by Sieve, it doesn't affect another message generated 317 as a side affect of any action. 319 The extension decribed in this document doesn't change an implicit 320 keep (see section 2.10.2 of [SIEVE]). 322 8. Other Considerations 324 This extension intentionally doesn't allow setting [IMAP] flags on 325 an arbitrary message in the [IMAP] message store. 327 9. Security Considerations 329 Security considerations are discussed in the [IMAP] and [SIEVE]. 330 It is belived that this extension doesn't introduce any additional 331 security concerns. 333 10. Extended example 335 # 336 # Example Sieve Filter 337 # Declare any optional features or extension used by the script 338 # 339 require ["fileinto", "imapflags", "variables"]; 341 # 342 # Move large messages to special mailbox 343 # 344 if size :over 1M 345 { 346 add "flags" "Big"; 347 if header :is "From" "boss@company.com" 348 { 349 # The message will be marked as "\Flagged Big" when filed into 350 # mailbox "Big messages" 351 add "flags" "\\Flagged"; 352 } 353 fileinto :flags "${flags}" "Big messages"; 354 } 356 if header :is "From" "grandma@example.net" 357 { 358 add "flags" ["\\Answered", "$MDNSent"]; 359 # If the message is bigger than 1Mb it will be marked as 360 # "Big \Answered $MDNSent" when filed into mailbox "grandma". 361 # If the message is shorter than 1Mb it will be marked as 362 # "\Answered $MDNSent" 363 fileinto :flags "${flags}" "GrandMa"; # move to "GrandMa" folder 364 } 366 # 367 # Handle messages from known mailing lists 368 # Move messages from IETF filter discussion list to filter folder 369 # 370 if header :is "Sender" "owner-ietf-mta-filters@imc.org" 371 { 372 set "flags" "\\Flagged $Work"; 373 # Message will have both "\Flagged" and $Work flags 374 keep :flags "${flags}"; 375 } 377 # 378 # Keep all messages to or from people in my company 379 # 380 elsif anyof address :domain :is ["From", "To"] "company.com" 381 { 382 keep :flags "${flags}"; # keep in "Inbox" folder 383 } 384 # 385 # Try and catch unsolicited email. If a message is not to me, 386 # or it contains a subject known to be spam, file it away. 387 # 388 elsif anyof (not address :all :contains 389 ["To", "Cc"] "me@company.com", 390 header :matches "subject" 391 ["*make*money*fast*", "*university*dipl*mas*"]) 392 { 393 remove "flags" "\\Flagged"; 394 # If message header does not contain my address, 395 # it's from a list. 396 fileinto :flags "${flags}" "spam"; # move to "spam" folder 397 } 398 else 399 { 400 # Move all other (non-company) mail to "personal" 401 # folder. 402 fileinto :flags "${flags}" "personal"; 403 } 405 11. Acknowledgments 407 This document has been revised in part based on comments and 408 discussions which took place on and off the Sieve mailing list. 410 The help of those who took the time to review the draft and make 411 suggestions is appreciated, especially that of Tim Showalter, 412 Barry Leiba, Randall Gellens, Ken Murchison, Cyrus Daboo, 413 Matthew Elvey, Jutta Degener, Ned Freed, Marc Mutz and 414 Kjetil Torgrim Homme. 416 Special thanks to Tony Hansen, David Lamb and 417 Roman Migal for helping me explain better the concept. 419 12. Author's Address 421 Alexey Melnikov 422 Isode 423 28 Gloucester Road, 424 Teddington, Middlesex 425 United Kingdom, TW11 0NU 427 Email: mel@isode.com 429 13. Normative References 431 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Mirapoint, 432 RFC 3028, January 2001. 434 [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 435 Internet Mail Consortium, RFC 2234, November, 1997. 437 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", Harvard University, RFC 2119, March 1997. 440 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 441 University of Washington, RFC 3501, March 2003. 443 [Variables] Homme, K. T., "Sieve -- Variables Extension", University of 444 Oslo, work in progress, draft-homme-sieve-variables-XX.txt 446 14. Full Copyright Statement 448 Copyright (C) The Internet Society 2000-2003. All Rights Reserved. 450 This document and translations of it may be copied and furnished to 451 others, and derivative works that comment on or otherwise explain it 452 or assist in its implementation may be prepared, copied, published 453 and distributed, in whole or in part, without restriction of any 454 kind, provided that the above copyright notice and this paragraph 455 are included on all such copies and derivative works. However, this 456 document itself may not be modified in any way, such as by removing 457 the copyright notice or references to the Internet Society or other 458 Internet organizations, except as needed for the purpose of 459 developing Internet standards in which case the procedures for 460 copyrights defined in the Internet Standards process must be 461 followed, or as required to translate it into languages other than 462 English. 464 The limited permissions granted above are perpetual and will not be 465 revoked by the Internet Society or its successors or assigns. 467 This document and the information contained herein is provided on an 468 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 469 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 470 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 471 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 472 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 474 Acknowledgement 476 Funding for the RFC Editor function is currently provided by the 477 Internet Society.