idnits 2.17.00 (12 Aug 2021) /tmp/idnits22564/draft-melnikov-sieve-imapext-metadata-08.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 396. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 402. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (December 16, 2008) is 4897 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 191, but not defined == Missing Reference: 'COMPARATOR' is mentioned on line 191, but not defined ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) == Outdated reference: draft-daboo-imap-annotatemore has been published as RFC 5464 == Outdated reference: draft-ietf-sieve-notify has been published as RFC 5435 == Outdated reference: draft-ietf-sieve-refuse-reject has been published as RFC 5429 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Intended status: Standards Track December 16, 2008 5 Expires: June 19, 2009 7 The Sieve mail filtering language - extensions for checking mailbox 8 status and accessing mailbox metadata 9 draft-melnikov-sieve-imapext-metadata-08 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 19, 2009. 36 Abstract 38 This memo defines an extension to the Sieve mail filtering language 39 (RFC 5228) for accessing mailbox and server annotations. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Conventions used in this document . . . . . . . . . . . . . 3 47 3. mailbox and mboxmetadata extensions . . . . . . . . . . . . 3 48 3.1. Test mailboxexists . . . . . . . . . . . . . . . . . . . . . 3 49 3.2. ':create' argument to 'fileinto' command . . . . . . . . . . 4 50 3.3. Test metadata . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.4. Test metadataexists . . . . . . . . . . . . . . . . . . . . 5 53 4. servermetadata extension . . . . . . . . . . . . . . . . . . 5 54 4.1. Test servermetadata . . . . . . . . . . . . . . . . . . . . 5 55 4.2. Test servermetadataexists . . . . . . . . . . . . . . . . . 6 57 5. Security Considerations . . . . . . . . . . . . . . . . . . 6 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . . 8 65 8.2. Informative References . . . . . . . . . . . . . . . . . . . 8 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 68 Intellectual Property and Copyright Statements . . . . . . . 10 70 1. Introduction 72 This memo defines an extension to the Sieve mail filtering language 73 [SIEVE] for accessing mailbox and server annotations. This allows 74 for customization of the Sieve engine behaviour based on variables 75 set using [METADATA]. 77 2. Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [KEYWORDS]. 83 Conventions for notations are as in [SIEVE] section 1.1, including 84 the use of [ABNF]. 86 This document is written with an assumption that readers are familiar 87 with data model and terms defined in Section 3 of [METADATA]. 89 3. mailbox and mboxmetadata extensions 91 3.1. Test mailboxexists 93 Usage: mailboxexists 95 The "mailboxexists" test is true if all mailboxes listed in the 96 mailbox-names argument exist in the mailstore and each allows the 97 user in whose context the Sieve script runs to "deliver" messages 98 into it. When the mailstore is an IMAP server, "delivery" of 99 messages is possible if a) the READ-WRITE response code is present 100 for the mailbox (see Section 7.1 of [IMAP]) if IMAP ACL [IMAPACL] is 101 not supported by the server, or b) the the user has 'p' or 'i' rights 102 for the mailbox (see Section 5.2 of [IMAPACL]). 104 Note that a successful "mailboxexists" test for a mailbox doesn't 105 necessarily mean that a "fileinto" action on this mailbox would 106 succeed. For example the "fileinto" action might put user over 107 quota. The "mailboxexists" only verifies existence of the mailbox 108 and whether the user in whose context the Sieve script runs has 109 permissions to execute fileinto on it. 111 The capability string for use with the require command is "mailbox". 113 Example: The following example assumes that the Sieve engine also 114 supports "reject" [REJECT] and "fileinto" [SIEVE]. However these 115 extensions are not required in order to implement the "mailbox" 116 extension. 118 require ["fileinto", "reject", "mailbox"]; 119 if mailboxexists "Partners" { 120 fileinto "Partners"; 121 } else { 122 reject "This message was not accepted by the Mailstore"; 123 } 125 3.2. ':create' argument to 'fileinto' command 127 Usage: fileinto [:create] 129 If the optional :create argument is specified with "fileinto" it 130 instructs the Sieve interpreter to create the specified mailbox, if 131 needed, before attempting to deliver the message into the specified 132 mailbox. If the mailbox already exists, this argument is ignored. 133 Failure to create the specified mailbox is considered to be an error. 135 The capability string for use with the :create parameter is 136 "mailbox". 138 3.3. Test metadata 140 Usage: metadata [MATCH-TYPE] [COMPARATOR] 141 142 144 This test retrieves the value of the mailbox annotation "annotation- 145 name" for the mailbox "mailbox" [METADATA]. The retrieved value is 146 compared to the "key-list". The test returns true if the annotation 147 exists and its value matches any of the keys. 149 The default match type is ":is" [SIEVE]. The default comparator is 150 "i;ascii-casemap" [SIEVE]. 152 The capability string for use with the require command is 153 "mboxmetadata". 155 Annotations MUST be accessed with the permissions of the user in 156 whose context the Sieve script runs, and annotations starting with 157 the "/private" prefix MUST be those of the user in whose context the 158 Sieve script runs. 160 Example: The following example assumes that the Sieve engine also 161 supports the "vacation" [VACATION] extension. However this extension 162 is not required in order to implement the "mboxmetadata" extension. 164 require ["mboxmetadata", "vacation"]; 166 if metadata :is "INBOX" 167 "/private/vendor/vendor.isode/auto-replies" "on" { 169 vacation text: 170 I'm away on holidays till March 2009. 171 Expect a delay. 172 . 173 } 175 3.4. Test metadataexists 177 Usage: metadataexists 180 The "metadataexists" test is true if all of the annotations listed in 181 the annotation-names argument exist (i.e., have non-NIL values) for 182 the specified mailbox. 184 The capability string for use with the require command is 185 "mboxmetadata". 187 4. servermetadata extension 189 4.1. Test servermetadata 191 Usage: servermetadata [MATCH-TYPE] [COMPARATOR] 192 194 This test retrieves the value of the server annotation "annotation- 195 name" [METADATA]. The retrieved value is compared to the "key-list". 196 The test returns true if the annotation exists and its value matches 197 any of the keys. 199 The default match type is ":is". The default comparator is "i;ascii- 200 casemap". 202 The capability string for use with the require command is 203 "servermetadata". 205 Annotations MUST be accessed with the permissions of the user in 206 whose context the Sieve script runs, and annotations starting with 207 the "/private" prefix MUST be those of the user in whose context the 208 Sieve script runs. 210 Example: The following example assumes that the Sieve engine also 211 supports "variables" [VARIABLES] and "enotify" [NOTIFY] and 212 "envelope" [SIEVE] extensions. However these extensions are not 213 required in order to implement the "servermetadata" extension. 215 require ["enotify", "servermetadata", "variables", "envelope"]; 217 if servermetadata :matches 218 "/private/vendor/vendor.isode/notification-uri" "*" { 219 set "notif_uri" "${0}"; 220 } 222 if not string :is "${notif_uri}" "none" { 223 # :matches is used to get the MAIL FROM address 224 if envelope :all :matches "from" "*" { 225 set "env_from" " [really: ${1}]"; 226 } 228 # :matches is used to get the value of the Subject header 229 if header :matches "Subject" "*" { 230 set "subject" "${1}"; 231 } 233 # :matches is used to get the address from the From header 234 if address :matches :all "from" "*" { 235 set "from_addr" "${1}"; 236 } 238 notify :message "${from_addr}${env_from}: ${subject}" 239 "${notif_uri}"; 240 } 242 4.2. Test servermetadataexists 244 Usage: servermetadataexists 245 247 The "servermetadataexists" test is true if all of the server 248 annotations listed in the annotation-names argument exist (i.e., have 249 non-NIL values). 251 The capability string for use with the require command is 252 "servermetadata". 254 5. Security Considerations 256 Extensions defined in this document deliberately don't provide a way 257 to modify annotations. 259 A failure to retrieve data due to the server storing the annotations 260 being down or otherwise inaccessible may alter the result of Sieve 261 processing. So implementations SHOULD treat a temporary failure to 262 retrieve annotations in the same manner as a temporary failure to 263 retrieve a Sieve script. 265 Protocols/APIs used to retrieve annotations MUST provide the same 266 level of confidentiality as protocols/APIs used to retrieve Sieve 267 scripts. 269 6. IANA Considerations 271 IANA is requested to add the following registrations to the list of 272 Sieve extensions: 274 To: iana@iana.org 275 Subject: Registration of new Sieve extension 276 Capability name: mailbox 277 Description: adds test for checking for mailbox existence and a new 278 optional argument to fileinto for creating a mailbox before 279 attempting mail delivery. 280 RFC number: this RFC 281 Contact address: 282 The Sieve discussion list 284 Capability name: mboxmetadata 285 Description: adds tests for checking for mailbox metadata item 286 existence and for retrieving of a mailbox metadata value. 287 RFC number: this RFC 288 Contact address: 289 The Sieve discussion list 291 Capability name: servermetadata 292 Description: adds tests for checking for server metadata item 293 existence and for retrieving of a server metadata value. 294 RFC number: this RFC 295 Contact address: 296 The Sieve discussion list 298 7. Acknowledgements 300 Thanks to Cyrus Daboo for initial motivation for this draft. 302 Thanks to Barry Leiba, Randall Gellens and Aaron Stone for helpful 303 comments on this document. 305 The author also thanks the Open Mobile Alliance's Mobile Email 306 working group for providing a set of requirements for mobile devices, 307 guiding some of the extensions in this document. 309 8. References 311 8.1. Normative References 313 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 314 Specifications: ABNF", RFC 5234, January 2008. 316 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 317 4rev1", RFC 3501, March 2003. 319 [IMAPACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 320 RFC 4314, December 2005. 322 [KEYWORDS] 323 Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", RFC 2119, March 1997. 326 [METADATA] 327 Daboo, C., "IMAP METADATA Extension", 328 draft-daboo-imap-annotatemore-17 (work in progress), 329 December 2008. 331 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 332 Language", RFC 5228, January 2008. 334 8.2. Informative References 336 [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 337 "Sieve Extension: Notifications", 338 draft-ietf-sieve-notify-12 (work in progress), 339 January 2008. 341 [REJECT] Stone, A., "The SIEVE mail filtering language - reject 342 extension", draft-ietf-sieve-refuse-reject-09 (work in 343 progress), November 2008. 345 [VACATION] 346 Showalter, T. and N. Freed, "Sieve Email Filtering: 347 Vacation Extension", RFC 5230, January 2008. 349 [VARIABLES] 350 Homme, K., "Sieve: An Email Filtering Language", RFC 5229, 351 January 2008. 353 Author's Address 355 Alexey Melnikov 356 Isode Limited 357 5 Castle Business Village 358 36 Station Road 359 Hampton, Middlesex TW12 2BX 360 UK 362 Email: Alexey.Melnikov@isode.com 364 Full Copyright Statement 366 Copyright (C) The IETF Trust (2008). 368 This document is subject to the rights, licenses and restrictions 369 contained in BCP 78, and except as set forth therein, the authors 370 retain all their rights. 372 This document and the information contained herein are provided on an 373 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 374 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 375 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 376 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 377 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 378 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 380 Intellectual Property 382 The IETF takes no position regarding the validity or scope of any 383 Intellectual Property Rights or other rights that might be claimed to 384 pertain to the implementation or use of the technology described in 385 this document or the extent to which any license under such rights 386 might or might not be available; nor does it represent that it has 387 made any independent effort to identify any such rights. Information 388 on the procedures with respect to rights in RFC documents can be 389 found in BCP 78 and BCP 79. 391 Copies of IPR disclosures made to the IETF Secretariat and any 392 assurances of licenses to be made available, or the result of an 393 attempt made to obtain a general license or permission for the use of 394 such proprietary rights by implementers or users of this 395 specification can be obtained from the IETF on-line IPR repository at 396 http://www.ietf.org/ipr. 398 The IETF invites any interested party to bring to its attention any 399 copyrights, patents or patent applications, or other proprietary 400 rights that may cover technology that may be required to implement 401 this standard. Please address the information to the IETF at 402 ietf-ipr@ietf.org.