idnits 2.17.1 draft-ietf-sieve-3431bis-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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 346. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3431, but the abstract doesn't seem to directly say this. It does mention RFC3431 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An implementation MUST ensure that the test for envelope "to" only reflects the delivery to the current user. It MUST not be possible for a user to determine if this message was delivered to someone else using this test. -- 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 (September 2005) is 6788 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: 'KEYWORDS' is mentioned on line 74, but not defined == Unused Reference: 'Keywords' is defined on line 292, 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 2822 (Obsoleted by RFC 5322) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Sieve Working Group W. Segmuller 2 Internet Draft B. Leiba 3 Obsoletes: 3431 (if approved) IBM T.J. Watson Research Center 4 Document: draft-ietf-sieve-3431bis-01.txt March 2005 5 Expires September 2005 7 Sieve Extension: Relational Tests 9 Status of this Document 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 September 16, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes the RELATIONAL extension to the Sieve mail 43 filtering language defined in RFC 3028. This extension extends 44 existing conditional tests in Sieve to allow relational operators. 46 In addition to testing their content, it also allows for testing of 47 the number of entities in header and envelope fields. 49 Meta-information on this document 51 This information is intended to facilitate discussion. It will be 52 removed when this document leaves the Internet-Draft stage. 54 This document is intended to be an update to the existing 55 "relational" extension to the Sieve mail filtering language, 56 available from the RFC repository as 57 . 59 This document and the Sieve language itself are being discussed on 60 the MTA Filters mailing list at . 61 Subscription requests can be sent to 62 (send an 63 email message with the word "subscribe" in the body). More 64 information on the mailing list along with a WWW archive of back 65 messages is available at . 67 Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in BCP 14, RFC 2119. 73 Conventions for notations are as in [SIEVE] section 1.1, including 74 the use of [KEYWORDS] and "Syntax:" label for the definition of 75 action and tagged arguments syntax, and the use of [ABNF]. 77 The capability string associated with extension defined in this 78 document is "relational". 80 1. Introduction 82 Sieve [SIEVE] is a language for filtering e-mail messages at the time 83 of final delivery. It is designed to be implementable on either a 84 mail client or mail server. It is meant to be extensible, simple, 85 and independent of access protocol, mail architecture, and operating 86 system. It is suitable for running on a mail server where users may 87 not be allowed to execute arbitrary programs, such as on black box 88 Internet Messages Access Protocol (IMAP) servers, as it has no 89 variables, loops, nor the ability to shell out to external programs. 91 The RELATIONAL extension provides relational operators on the 92 address, envelope, and header tests. This extension also provides a 93 way of counting the entities in a message header or address field. 95 With this extension, the sieve script may now determine if a field is 96 greater than or less than a value instead of just equivalent. One 97 use is for the x-priority field: move messages with a priority 98 greater than 3 to the "work on later" folder. Mail could also be 99 sorted by the from address. Those userids that start with 'a'-'m' go 100 to one folder, and the rest go to another folder. 102 The sieve script can also determine the number of fields in the 103 header, or the number of addresses in a recipient field. For 104 example: are there more than 5 addresses in the to and cc fields. 106 2. Comparators 108 This document does not define any comparators or exempt any 109 comparators from the require clause. Any comparator used, other than 110 "i;octet" and "i;ascii-casemap", MUST be declared a require clause as 111 defined in [SIEVE]. 113 The "i;ascii-numeric" comparator, as defined in [ACAP], MUST be 114 supported for any implementation of this extension. The comparator 115 "i;ascii-numeric" MUST support at least 32 bit unsigned integers. 117 Larger integers MAY be supported. Note: the "i;ascii-numeric" 118 comparator does not support negative numbers. 120 3. Match Type 122 This document defines two new match types. They are the VALUE match 123 type and the COUNT match type. 125 The syntax is: 127 MATCH-TYPE =/ COUNT / VALUE 129 COUNT = ":count" relational-match 131 VALUE = ":value" relational-match 133 relational-match = DQUOTE ( "gt" / "ge" / "lt" 134 / "le" / "eq" / "ne" ) DQUOTE 135 ; "gt" means "greater than", the C operator ">". 136 ; "ge" means "greater than or equal", the C operator ">=". 137 ; "lt" means "less than", the C operator "<". 138 ; "le" means "less than or equal", the C operator "<=". 140 ; "eq" means "equal to", the C operator "==". 141 ; "ne" means "not equal to", the C operator "!=". 143 3.1. Match Type Value 145 The VALUE match type does a relational comparison between strings. 147 The VALUE match type may be used with any comparator which returns 148 sort information. 150 Leading and trailing white space MUST be removed from the value of 151 the message for the comparison. White space is defined as 153 SP / HTAB / CRLF 155 A value from the message is considered the left side of the relation. 156 A value from the test expression, the key-list for address, envelope, 157 and header tests, is the right side of the relation. 159 If there are multiple values on either side or both sides, the test 160 is considered true, if any pair is true. 162 3.2. Match Type Count 164 The COUNT match type first determines the number of the specified 165 entities in the message and does a relational comparison of the 166 number of entities to the values specified in the test expression. 168 The COUNT match type SHOULD only be used with numeric comparators. 170 The Address Test counts the number of recipients in the specified 171 fields. Group names are ignored. 173 The Envelope Test counts the number of recipients in the specified 174 envelope parts. The envelope "to" will always have only one entry, 175 which is the address of the user for whom the sieve script is 176 running. There is no way a sieve script can determine if the message 177 was actually sent to someone else using this test. The envelope 178 "from" will be 0 if the MAIL FROM is blank, or 1 if MAIL FROM is not 179 blank. 181 The Header Test counts the total number of instances of the specified 182 fields. This does not count individual addresses in the "to", "cc", 183 and other recipient fields. 185 In all cases, if more than one field name is specified, the counts 186 for all specified fields are added together to obtain the number for 187 comparison. Thus, specifying ["to", "cc"] in an address COUNT test, 188 comparing the total number of "to" and "cc" addresses; if separate 189 counts are desired, they must be done in two comparisons, perhaps 190 joined by "allof" or "anyof". 192 4. Example 194 Using the message: 196 received: ... 197 received: ... 198 subject: example 199 to: foo@example.com.invalid, baz@example.com.invalid 200 cc: qux@example.com.invalid 202 The test: 204 address :count "ge" :comparator "i;ascii-numeric" 205 ["to", "cc"] ["3"] 207 would be true and the test 209 anyof ( address :count "ge" :comparator "i;ascii-numeric" 210 ["to"] ["3"], 211 address :count "ge" :comparator "i;ascii-numeric" 212 ["cc"] ["3"] ) 214 would be false. 216 To check the number of received fields in the header, the following 217 test may be used: 219 header :count "ge" :comparator "i;ascii-numeric" 220 ["received"] ["3"] 222 This would return false. But 224 header :count "ge" :comparator "i;ascii-numeric" 225 ["received", "subject"] ["3"] 227 would return true. 229 The test: 231 header :count "ge" :comparator "i;ascii-numeric" 232 ["to", "cc"] ["3"] 234 will always return false on an RFC 2822 compliant message [RFC2822], 235 since a message can have at most one "to" field and at most one "cc" 236 field. This test counts the number of fields, not the number of 237 addresses. 239 5. Extended Example 241 require ["relational", "comparator-i;ascii-numeric"]; 243 if header :value "lt" :comparator "i;ascii-numeric" 244 ["x-priority"] ["3"] 245 { 246 fileinto "Priority"; 247 } 249 elseif address :count "gt" :comparator "i;ascii-numeric" 250 ["to"] ["5"] 251 { 252 # everything with more than 5 recipients in the "to" field 253 # is considered SPAM 254 fileinto "SPAM"; 255 } 257 elseif address :value "gt" :all :comparator "i;ascii-casemap" 258 ["from"] ["M"] 259 { 260 fileinto "From N-Z"; 261 } else { 262 fileinto "From A-M"; 263 } 265 if allof ( address :count "eq" :comparator "i;ascii-numeric" 266 ["to", "cc"] ["1"] , 267 address :all :comparator "i;ascii-casemap" 268 ["to", "cc"] ["me@foo.example.com.invalid"] 269 { 270 fileinto "Only me"; 271 } 273 6. IANA Considerations 275 This document requests that the IANA update the entry for the 276 "relational" Sieve extension to point to this document. 278 7. Security Considerations 280 Security considerations are discussed in [SIEVE]. 282 An implementation MUST ensure that the test for envelope "to" only 283 reflects the delivery to the current user. It MUST not be possible 284 for a user to determine if this message was delivered to someone else 285 using this test. 287 8. Normative References 289 [SIEVE]; Showalter, T.; "Sieve: A Mail Filtering Language"; RFC 3028; 290 January 2001. 292 [Keywords]; Bradner, S.; "Key words for use in RFCs to 293 IndicateRequirement Levels"; BCP 14; RFC 2119; March 1997. 295 [ABNF]; Crocker, D.; "Augmented BNF for Syntax Specifications: ABNF"; 296 RFC 2234; November 1997. 298 [RFC2822]; Resnick, P.; "Internet Message Format"; RFC 2822; April 299 2001. 301 9. Non-Normative References 303 [ACAP]; Newman, C. and J. G. Myers; "ACAP -- Application 304 Configuration Access Protocol"; RFC 2244; November 1997. 306 10. Authors' Addresses 308 Wolfgang Segmuller 309 IBM T.J. Watson Research Center 310 19 Skyline Drive 311 Hawthorne, NY 10532 313 Phone: 1-914-784-7408 314 Email: whs@watson.ibm.com 316 Barry Leiba 317 IBM T.J. Watson Research Center 318 19 Skyline Drive 319 Hawthorne, NY 10532 321 Phone: 1-914-784-7941 322 Email: leiba@watson.ibm.com 324 Intellectual Property Statement 326 The IETF takes no position regarding the validity or scope of any 327 Intellectual Property Rights or other rights that might be claimed to 328 pertain to the implementation or use of the technology described in 329 this document or the extent to which any license under such rights 330 might or might not be available; nor does it represent that it has 331 made any independent effort to identify any such rights. Information 332 on the procedures with respect to rights in RFC documents can be 333 found in BCP 78 and BCP 79. 335 Copies of IPR disclosures made to the IETF Secretariat and any 336 assurances of licenses to be made available, or the result of an 337 attempt made to obtain a general license or permission for the use of 338 such proprietary rights by implementers or users of this 339 specification can be obtained from the IETF on-line IPR repository at 340 http://www.ietf.org/ipr. 342 The IETF invites any interested party to bring to its attention any 343 copyrights, patents or patent applications, or other proprietary 344 rights that may cover technology that may be required to implement 345 this standard. Please address the information to the IETF at 346 ietf-ipr@ietf.org. 348 Disclaimer of Validity 350 This document and the information contained herein are provided on an 351 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 352 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 353 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 354 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 355 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 356 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 358 Copyright Statement 360 Copyright (C) The Internet Society (2005). This document is subject 361 to the rights, licenses and restrictions contained in BCP 78, and 362 except as set forth therein, the authors retain all their rights. 364 Acknowledgment 366 Funding for the RFC Editor function is currently provided by the 367 Internet Society.