idnits 2.17.1 draft-ietf-sieve-3431bis-00.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 34. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 282. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** 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: ---------------------------------------------------------------------------- ** 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. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack an Authors' Addresses Section. -- The draft header indicates that this document obsoletes RFC3431, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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: Internet DRAFT Sieve Extension: Relational Tests February 2005 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. 8. Normative References -- 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 (August 2005) is 6828 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 72, but not defined == Unused Reference: 'Keywords' is defined on line 224, 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: 16 errors (**), 0 flaws (~~), 4 warnings (==), 8 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-00.txt February 2005 5 Expires August 2005 7 Sieve Extension: Relational Tests 9 Status of this Document 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 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. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on August 14, 2005. 29 Copyright Notice 30 Copyright (C) The Internet Society (2005). 31 Abstract 32 This document describes the RELATIONAL extension to the Sieve mail 33 filtering language defined in RFC 3028. This extension extends 34 existing conditional tests in Sieve to allow relational operators. 36 Internet DRAFT Sieve Extension: Relational Tests February 2005 37 In addition to testing their content, it also allows for testing of 38 the number of entities in header and envelope fields. 39 Meta-information on this document 40 This information is intended to facilitate discussion. It will be 41 removed when this document leaves the Internet-Draft stage. 42 This document is intended to be an update to the existing 43 "relational" extension to the Sieve mail filtering language, 44 available from the RFC repository as 45 . 46 This document and the Sieve language itself are being discussed on 47 the MTA Filters mailing list at . 48 Subscription requests can be sent to 49 (send an 50 email message with the word "subscribe" in the body). More 51 information on the mailing list along with a WWW archive of back 52 messages is available at . 53 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in BCP 14, RFC 2119. 57 Conventions for notations are as in [SIEVE] section 1.1, including 58 the use of [KEYWORDS] and "Syntax:" label for the definition of 59 action and tagged arguments syntax, and the use of [ABNF]. 60 The capability string associated with extension defined in this 61 document is "relational". 62 1. Introduction 63 Sieve [SIEVE] is a language for filtering e-mail messages at the time 64 of final delivery. It is designed to be implementable on either a 65 mail client or mail server. It is meant to be extensible, simple, 66 and independent of access protocol, mail architecture, and operating 67 system. It is suitable for running on a mail server where users may 68 not be allowed to execute arbitrary programs, such as on black box 69 Internet Messages Access Protocol (IMAP) servers, as it has no 70 variables, loops, nor the ability to shell out to external programs. 71 The RELATIONAL extension provides relational operators on the 73 Internet DRAFT Sieve Extension: Relational Tests February 2005 74 address, envelope, and header tests. This extension also provides a 75 way of counting the entities in a message header or address field. 76 With this extension, the sieve script may now determine if a field is 77 greater than or less than a value instead of just equivalent. One 78 use is for the x-priority field: move messages with a priority 79 greater than 3 to the "work on later" folder. Mail could also be 80 sorted by the from address. Those userids that start with 'a'-'m' go 81 to one folder, and the rest go to another folder. 82 The sieve script can also determine the number of fields in the 83 header, or the number of addresses in a recipient field. For 84 example: are there more than 5 addresses in the to and cc fields. 85 2. Comparators 86 This document does not define any comparators or exempt any 87 comparators from the require clause. Any comparator used, other than 88 "i;octet" and "i;ascii-casemap", MUST be declared a require clause as 89 defined in [SIEVE]. 90 The "i;ascii-numeric" comparator, as defined in [ACAP], MUST be 91 supported for any implementation of this extension. The comparator 92 "i;ascii-numeric" MUST support at least 32 bit unsigned integers. 93 Larger integers MAY be supported. Note: the "i;ascii-numeric" 94 comparator does not support negative numbers. 95 3. Match Type 96 This document defines two new match types. They are the VALUE match 97 type and the COUNT match type. 98 The syntax is: 99 MATCH-TYPE =/ COUNT / VALUE 100 COUNT = ":count" relational-match 101 VALUE = ":value" relational-match 102 relational-match = DQUOTE ( "gt" / "ge" / "lt" 103 / "le" / "eq" / "ne" ) DQUOTE 104 ; "gt" means "greater than", the C operator ">". 105 ; "ge" means "greater than or equal", the C operator ">=". 106 ; "lt" means "less than", the C operator "<". 107 ; "le" means "less than or equal", the C operator "<=". 109 Internet DRAFT Sieve Extension: Relational Tests February 2005 110 ; "eq" means "greater than", the C operator "==". 111 ; "ne" means "greater than", the C operator "!=". 112 3.1. Match Type Value 113 The VALUE match type does a relational comparison between strings. 114 The VALUE match type may be used with any comparator which returns 115 sort information. 116 Leading and trailing white space MUST be removed from the value of 117 the message for the comparison. White space is defined as 118 SP / HTAB / CRLF 119 A value from the message is considered the left side of the relation. 120 A value from the test expression, the key-list for address, envelope, 121 and header tests, is the right side of the relation. 122 If there are multiple values on either side or both sides, the test 123 is considered true, if any pair is true. 124 3.2. Match Type Count 125 The COUNT match type first determines the number of the specified 126 entities in the message and does a relational comparison of the 127 number of entities to the values specified in the test expression. 128 The COUNT match type SHOULD only be used with numeric comparators. 129 The Address Test counts the number of recipients in the specified 130 fields. Group names are ignored. 131 The Envelope Test counts the number of recipients in the specified 132 envelope parts. The envelope "to" will always have only one entry, 133 which is the address of the user for whom the sieve script is 134 running. There is no way a sieve script can determine if the message 135 was actually sent to someone else using this test. The envelope 136 "from" will be 0 if the MAIL FROM is blank, or 1 if MAIL FROM is not 137 blank. 138 The Header Test counts the total number of instances of the specified 139 fields. This does not count individual addresses in the "to", "cc", 140 and other recipient fields. 141 In all cases, if more than one field name is specified, the counts 142 for all specified fields are added together to obtain the number for 144 Internet DRAFT Sieve Extension: Relational Tests February 2005 145 comparison. Thus, specifying ["to", "cc"] in an address COUNT test, 146 comparing the total number of "to" and "cc" addresses; if separate 147 counts are desired, they must be done in two comparisons, perhaps 148 joined by "allof" or "anyof". 149 4. Example 150 Using the message: 151 received: ... 152 received: ... 153 subject: example 154 to: foo@example.com.invalid, baz@example.com.invalid 155 cc: qux@example.com.invalid 156 The test: 157 address :count "ge" :comparator "i;ascii-numeric" 158 ["to", "cc"] ["3"] 159 would be true and the test 160 anyof ( address :count "ge" :comparator "i;ascii-numeric" 161 ["to"] ["3"], 162 address :count "ge" :comparator "i;ascii-numeric" 163 ["cc"] ["3"] ) 164 would be false. 165 To check the number of received fields in the header, the following 166 test may be used: 167 header :count "ge" :comparator "i;ascii-numeric" 168 ["received"] ["3"] 169 This would return false. But 170 header :count "ge" :comparator "i;ascii-numeric" 171 ["received", "subject"] ["3"] 172 would return true. 173 The test: 174 header :count "ge" :comparator "i;ascii-numeric" 175 ["to", "cc"] ["3"] 176 will always return false on an RFC 2822 compliant message [RFC2822], 178 Internet DRAFT Sieve Extension: Relational Tests February 2005 179 since a message can have at most one "to" field and at most one "cc" 180 field. This test counts the number of fields, not the number of 181 addresses. 182 5. Extended Example 183 require ["relational", "comparator-i;ascii-numeric"]; 184 if header :value "lt" :comparator "i;ascii-numeric" 185 ["x-priority"] ["3"] 186 { 187 fileinto "Priority"; 188 } 189 elseif address :count "gt" :comparator "i;ascii-numeric" 190 ["to"] ["5"] 191 { 192 # everything with more than 5 recipients in the "to" field 193 # is considered SPAM 194 fileinto "SPAM"; 195 } 196 elseif address :value "gt" :all :comparator "i;ascii-casemap" 197 ["from"] ["M"] 198 { 199 fileinto "From N-Z"; 200 } else { 201 fileinto "From A-M"; 202 } 203 if allof ( address :count "eq" :comparator "i;ascii-numeric" 204 ["to", "cc"] ["1"] , 205 address :all :comparator "i;ascii-casemap" 206 ["to", "cc"] ["me@foo.example.com.invalid"] 207 { 208 fileinto "Only me"; 209 } 210 6. IANA Considerations 211 This document requests that the IANA update the entry for the 212 "relational" Sieve extension to point to this document. 213 7. Security Considerations 214 Security considerations are discussed in [SIEVE]. 216 Internet DRAFT Sieve Extension: Relational Tests February 2005 217 An implementation MUST ensure that the test for envelope "to" only 218 reflects the delivery to the current user. It MUST not be possible 219 for a user to determine if this message was delivered to someone else 220 using this test. 221 8. Normative References 222 [SIEVE]; Showalter, T.; "Sieve: A Mail Filtering Language"; RFC 3028; 223 January 2001. 224 [Keywords]; Bradner, S.; "Key words for use in RFCs to 225 IndicateRequirement Levels"; BCP 14; RFC 2119; March 1997. 226 [ABNF]; Crocker, D.; "Augmented BNF for Syntax Specifications: ABNF"; 227 RFC 2234; November 1997. 228 [RFC2822]; Resnick, P.; "Internet Message Format"; RFC 2822; April 229 2001. 230 9. Non-Normative References 231 [ACAP]; Newman, C. and J. G. Myers; "ACAP -- Application 232 Configuration Access Protocol"; RFC 2244; November 1997. 233 10. Authors' Addresses 234 Wolfgang Segmuller 235 IBM T.J. Watson Research Center 236 19 Skyline Drive 237 Hawthorne, NY 10532 238 Phone: 1-914-784-7408 239 Email: whs@watson.ibm.com 240 Barry Leiba 241 IBM T.J. Watson Research Center 242 19 Skyline Drive 243 Hawthorne, NY 10532 244 Phone: 1-914-784-7941 245 Email: leiba@watson.ibm.com 247 Internet DRAFT Sieve Extension: Relational Tests February 2005 248 Intellectual Property Statement 249 The IETF takes no position regarding the validity or scope of any 250 Intellectual Property Rights or other rights that might be claimed to 251 pertain to the implementation or use of the technology described in 252 this document or the extent to which any license under such rights 253 might or might not be available; nor does it represent that it has 254 made any independent effort to identify any such rights. Information 255 on the procedures with respect to rights in RFC documents can be 256 found in BCP 78 and BCP 79. 257 Copies of IPR disclosures made to the IETF Secretariat and any 258 assurances of licenses to be made available, or the result of an 259 attempt made to obtain a general license or permission for the use of 260 such proprietary rights by implementers or users of this 261 specification can be obtained from the IETF on-line IPR repository at 262 http://www.ietf.org/ipr. 263 The IETF invites any interested party to bring to its attention any 264 copyrights, patents or patent applications, or other proprietary 265 rights that may cover technology that may be required to implement 266 this standard. Please address the information to the IETF at 267 ietf-ipr@ietf.org. 268 Disclaimer of Validity 269 This document and the information contained herein are provided on an 270 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 271 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 272 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 273 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 274 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 275 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 276 Copyright Statement 277 Copyright (C) The Internet Society (2005). This document is subject 278 to the rights, licenses and restrictions contained in BCP 78, and 279 except as set forth therein, the authors retain all their rights. 280 Acknowledgment 281 Funding for the RFC Editor function is currently provided by the 282 Internet Society.