idnits 2.17.1 draft-ietf-sieve-3028bis-02.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 on line 1626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1650. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1614), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3028, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2005) is 6861 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: 'COMPARATOR' is mentioned on line 1281, but not defined == Missing Reference: 'ADDRESS-PART' is mentioned on line 1281, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 1281, but not defined == Missing Reference: 'QUANTIFIER' is mentioned on line 1417, but not defined == Unused Reference: 'IMAP' is defined on line 1609, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) == Outdated reference: A later version (-14) exists of draft-newman-i18n-comparator-03 ** Obsolete normative reference: RFC 2822 (ref. 'IMAIL') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3798 (ref. 'MDN') (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 1894 (ref. 'DSN') (Obsoleted by RFC 3464) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Guenther 3 Internet-Draft Sendmail, Inc. 4 Expires: December 2005 T. Showalter 5 Obsoletes: 3028 (if approved) Editors 6 June 2005 8 Sieve: An Email Filtering Language 9 draft-ietf-sieve-3028bis-02.txt 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 A revised version of this draft document will be submitted to the RFC 35 editor as a Standard Track RFC for the Internet Community. 36 Discussion and suggestions for improvement are requested, and should 37 be sent to ietf-mta-filters@imc.org. Distribution of this memo is 38 unlimited. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Abstract 46 This document describes a language for filtering email messages at 47 time of final delivery. It is designed to be implementable on either 48 a mail client or mail server. It is meant to be extensible, simple, 49 and independent of access protocol, mail architecture, and operating 50 system. It is suitable for running on a mail server where users may 51 not be allowed to execute arbitrary programs, such as on black box 52 Internet Message Access Protocol (IMAP) servers, as it has no 53 variables, loops, or ability to shell out to external programs. 55 Table of Contents 57 1. Introduction ........................................... 3 58 1.1. Conventions Used in This Document ..................... 4 59 1.2. Example mail messages ................................. 5 60 2. Design ................................................. 5 61 2.1. Form of the Language .................................. 6 62 2.2. Whitespace ............................................ 6 63 2.3. Comments .............................................. 6 64 2.4. Literal Data .......................................... 6 65 2.4.1. Numbers ............................................... 6 66 2.4.2. Strings ............................................... 7 67 2.4.2.1. String Lists .......................................... 8 68 2.4.2.2. Headers ............................................... 8 69 2.4.2.3. Addresses ............................................. 8 70 2.4.2.4. MIME Parts ............................................ 9 71 2.5. Tests ................................................. 9 72 2.5.1. Test Lists ............................................ 9 73 2.6. Arguments ............................................. 9 74 2.6.1. Positional Arguments .................................. 9 75 2.6.2. Tagged Arguments ...................................... 10 76 2.6.3. Optional Arguments .................................... 10 77 2.6.4. Types of Arguments .................................... 10 78 2.7. String Comparison ..................................... 11 79 2.7.1. Match Type ............................................ 11 80 2.7.2. Comparisons Across Character Sets ..................... 12 81 2.7.3. Comparators ........................................... 12 82 2.7.4. Comparisons Against Addresses ......................... 14 83 2.8. Blocks ................................................ 14 84 2.9. Commands .............................................. 14 85 2.10. Evaluation ............................................ 15 86 2.10.1. Action Interaction .................................... 15 87 2.10.2. Implicit Keep ......................................... 15 88 2.10.3. Message Uniqueness in a Mailbox ....................... 16 89 2.10.4. Limits on Numbers of Actions .......................... 16 90 2.10.5. Extensions and Optional Features ...................... 16 91 2.10.6. Errors ................................................ 17 92 2.10.7. Limits on Execution ................................... 17 93 3. Control Commands ....................................... 17 94 3.1. Control Structure If .................................. 18 95 3.2. Control Structure Require ............................. 19 96 3.3. Control Structure Stop ................................ 19 97 4. Action Commands ........................................ 19 98 4.1. Action fileinto ....................................... 20 99 4.2. Action redirect ....................................... 20 100 4.3. Action keep ........................................... 20 101 4.4. Action discard ........................................ 21 102 5. Test Commands .......................................... 21 103 5.1. Test address .......................................... 22 104 5.2. Test allof ............................................ 22 105 5.3. Test anyof ............................................ 23 106 5.4. Test envelope ......................................... 23 107 5.5. Test exists ........................................... 24 108 5.6. Test false ............................................ 24 109 5.7. Test header ........................................... 24 110 5.8. Test not .............................................. 25 111 5.9. Test size ............................................. 25 112 5.10. Test true ............................................. 25 113 6. Extensibility .......................................... 25 114 6.1. Capability String ..................................... 26 115 6.2. IANA Considerations ................................... 26 116 6.2.1. Template for Capability Registrations ................. 27 117 6.2.2. Initial Capability Registrations ...................... 27 118 6.3. Capability Transport .................................. 28 119 7. Transmission ........................................... 28 120 8. Parsing ................................................ 29 121 8.1. Lexical Tokens ........................................ 29 122 8.2. Grammar ............................................... 31 123 9. Extended Example ....................................... 31 124 10. Security Considerations ................................ 32 125 11. Acknowledgments ........................................ 33 126 12. Editor's Address ....................................... 33 127 13. Normative References ................................... 33 128 14. Informative References ................................. 34 129 14. Full Copyright Statement ............................... 34 131 1. Introduction 133 This memo documents a language that can be used to create filters for 134 electronic mail. It is not tied to any particular operating system 135 or mail architecture. It requires the use of [IMAIL]-compliant 136 messages, but should otherwise generalize to many systems. 138 The language is powerful enough to be useful but limited in order to 139 allow for a safe server-side filtering system. The intention is to 140 make it impossible for users to do anything more complex (and 141 dangerous) than write simple mail filters, along with facilitating 142 the use of GUIs for filter creation and manipulation. The language 143 is not Turing-complete: it provides no way to write a loop or a 144 function and variables are not provided. 146 Scripts written in Sieve are executed during final delivery, when the 147 message is moved to the user-accessible mailbox. In systems where 148 the MTA does final delivery, such as traditional Unix mail, it is 149 reasonable to sort when the MTA deposits mail into the user's 150 mailbox. 152 There are a number of reasons to use a filtering system. Mail 153 traffic for most users has been increasing due to increased usage of 154 email, the emergence of unsolicited email as a form of advertising, 155 and increased usage of mailing lists. 157 Experience at Carnegie Mellon has shown that if a filtering system is 158 made available to users, many will make use of it in order to file 159 messages from specific users or mailing lists. However, many others 160 did not make use of the Andrew system's FLAMES filtering language 161 [FLAMES] due to difficulty in setting it up. 163 Because of the expectation that users will make use of filtering if 164 it is offered and easy to use, this language has been made simple 165 enough to allow many users to make use of it, but rich enough that it 166 can be used productively. However, it is expected that GUI-based 167 editors will be the preferred way of editing filters for a large 168 number of users. 170 1.1. Conventions Used in This Document 172 In the sections of this document that discuss the requirements of 173 various keywords and operators, the following conventions have been 174 adopted. 176 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 177 in this document are to be interpreted as defined in [KEYWORDS]. 179 Each section on a command (test, action, or control structure) has a 180 line labeled "Syntax:". This line describes the syntax of the 181 command, including its name and its arguments. Required arguments 182 are listed inside angle brackets ("<" and ">"). Optional arguments 183 are listed inside square brackets ("[" and "]"). Each argument is 184 followed by its type, so "" represents an argument 185 called "key" that is a string. Literal strings are represented with 186 double-quoted strings. Alternatives are separated with slashes, and 187 parenthesis are used for grouping, similar to [ABNF]. 189 In the "Syntax" line, there are three special pieces of syntax that 190 are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART. 191 These are discussed in sections 2.7.1, 2.7.3, and 2.7.4, 192 respectively. 194 The formal grammar for these commands in section 10 and is the 195 authoritative reference on how to construct commands, but the formal 196 grammar does not specify the order, semantics, number or types of 197 arguments to commands, nor the legal command names. The intent is to 198 allow for extension without changing the grammar. 200 1.2. Example mail messages 202 The following mail messages will be used throughout this document in 203 examples. 205 Message A 206 ----------------------------------------------------------- 207 Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST) 208 From: coyote@desert.example.org 209 To: roadrunner@acme.example.com 210 Subject: I have a present for you 212 Look, I'm sorry about the whole anvil thing, and I really 213 didn't mean to try and drop it on you from the top of the 214 cliff. I want to try to make it up to you. I've got some 215 great birdseed over here at my place--top of the line 216 stuff--and if you come by, I'll have it all wrapped up 217 for you. I'm really sorry for all the problems I've caused 218 for you over the years, but I know we can work this out. 219 -- 220 Wile E. Coyote "Super Genius" coyote@desert.example.org 221 ----------------------------------------------------------- 223 Message B 224 ----------------------------------------------------------- 225 From: youcouldberich!@reply-by-postal-mail.invalid 226 Sender: b1ff@de.res.example.com 227 To: rube@landru.example.edu 228 Date: Mon, 31 Mar 1997 18:26:10 -0800 229 Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$ 231 YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT 232 IT! SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS! IT WILL 233 GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY! 234 MONEY! MONEY! COLD HARD CASH! YOU WILL RECEIVE OVER 235 $20,000 IN LESS THAN TWO MONTHS! AND IT'S LEGAL!!!!!!!!! 236 !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1 JUST 237 SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW! 238 ----------------------------------------------------------- 240 2. Design 241 2.1. Form of the Language 243 The language consists of a set of commands. Each command consists of 244 a set of tokens delimited by whitespace. The command identifier is 245 the first token and it is followed by zero or more argument tokens. 246 Arguments may be literal data, tags, blocks of commands, or test 247 commands. 249 The language is represented in UTF-8, as specified in [UTF-8]. 251 Tokens in the ASCII range are considered case-insensitive. 253 2.2. Whitespace 255 Whitespace is used to separate tokens. Whitespace is made up of 256 tabs, newlines (CRLF, never just CR or LF), and the space character. 257 The amount of whitespace used is not significant. 259 2.3. Comments 261 Two types of comments are offered. Comments are semantically 262 equivalent to whitespace and can be used anyplace that whitespace is 263 (with one exception in multi-line strings, as described in the 264 grammar). 266 Hash comments begin with a "#" character that is not contained within 267 a string and continue until the next CRLF. 269 Example: if size :over 100K { # this is a comment 270 discard; 271 } 273 Bracketed comments begin with the token "/*" and end with "*/" 274 outside of a string. Bracketed comments may span multiple lines. 275 Bracketed comments do not nest. 277 Example: if size :over 100K { /* this is a comment 278 this is still a comment */ discard /* this is a comment 279 */ ; 280 } 282 2.4. Literal Data 284 Literal data means data that is not executed, merely evaluated "as 285 is", to be used as arguments to commands. Literal data is limited to 286 numbers and strings. 288 2.4.1. Numbers 289 Numbers are given as ordinary decimal numbers. However, those 290 numbers that have a tendency to be fairly large, such as message 291 sizes, MAY have a "K", "M", or "G" appended to indicate a multiple of 292 a power of two. To be comparable with the power-of-two-based 293 versions of SI units that computers frequently use, K specifies 294 kibi-, or 1,024 (2^10) times the value of the number; M specifies 295 mebi-, or 1,048,576 (2^20) times the value of the number; and G 296 specifies gibi-, or 1,073,741,824 (2^30) times the value of the 297 number [BINARY-SI]. 299 Implementations MUST provide 31 bits of magnitude in numbers, but MAY 300 provide more. 302 Only positive integers are permitted by this specification. 304 2.4.2. Strings 306 Scripts involve large numbers of strings as they are used for pattern 307 matching, addresses, textual bodies, etc. Typically, short quoted 308 strings suffice for most uses, but a more convenient form is provided 309 for longer strings such as bodies of messages. 311 A quoted string starts and ends with a single double quote (the <"> 312 character, ASCII 34). A backslash ("\", ASCII 92) inside of a quoted 313 string is followed by either another backslash or a double quote. 314 This two-character sequence represents a single backslash or double- 315 quote within the string, respectively. 317 Scripts SHOULD NOT escape other characters with a backslash. 319 An undefined escape sequence (such as "\a" in a context where "a" has 320 no special meaning) is interpreted as if there were no backslash (in 321 this case, "\a" is just "a"). 323 Non-printing characters such as tabs, CR and LF, and control 324 characters are permitted in quoted strings. Quoted strings MAY span 325 multiple lines. NUL (ASCII 0) is not allowed in strings. 327 For entering larger amounts of text, such as an email message, a 328 multi-line form is allowed. It starts with the keyword "text:", 329 followed by a CRLF, and ends with the sequence of a CRLF, a single 330 period, and another CRLF. In order to allow the message to contain 331 lines with a single-dot, lines are dot-stuffed. That is, when 332 composing a message body, an extra `.' is added before each line 333 which begins with a `.'. When the server interprets the script, 334 these extra dots are removed. Note that a line that begins with a 335 dot followed by a non-dot character is not interpreted dot-stuffed; 336 that is, ".foo" is interpreted as ".foo". However, because this is 337 potentially ambiguous, scripts SHOULD be properly dot-stuffed so such 338 lines do not appear. 340 Note that a hashed comment or whitespace may occur in between the 341 "text:" and the CRLF, but not within the string itself. Bracketed 342 comments are not allowed here. 344 2.4.2.1. String Lists 346 When matching patterns, it is frequently convenient to match against 347 groups of strings instead of single strings. For this reason, a list 348 of strings is allowed in many tests, implying that if the test is 349 true using any one of the strings, then the test is true. 350 Implementations are encouraged to use short-circuit evaluation in 351 these cases. 353 For instance, the test `header :contains ["To", "Cc"] 354 ["me@example.com", "me00@landru.example.edu"]' is true if either the 355 To header or Cc header of the input message contains either of the 356 email addresses "me@example.com" or "me00@landru.example.edu". 358 Conversely, in any case where a list of strings is appropriate, a 359 single string is allowed without being a member of a list: it is 360 equivalent to a list with a single member. This means that the test 361 `exists "To"' is equivalent to the test `exists ["To"]'. 363 2.4.2.2. Headers 365 Headers are a subset of strings. In the Internet Message 366 Specification [IMAIL], each header line is allowed to have whitespace 367 nearly anywhere in the line, including after the field name and 368 before the subsequent colon. Extra spaces between the header name 369 and the ":" in a header field are ignored. 371 A header name never contains a colon. The "From" header refers to a 372 line beginning "From:" (or "From :", etc.). No header will match 373 the string "From:" due to the trailing colon. 375 Folding of long header lines (as described in [IMAIL] 2.2.3) is 376 removed prior to interpretation of the data. The folding syntax (the 377 CRLF that ends a line plus any leading whitespace at the beginning of 378 the next line that indicates folding) are interpreted as if they were 379 a single space. 381 2.4.2.3. Addresses 383 A number of commands call for email addresses, which are also a 384 subset of strings. When these addresses are used in outbound 385 contexts, addresses must be compliant with [IMAIL], but are further 386 constrained. Using the symbols defined in [IMAIL], section 3, the 387 syntax of an address is: 389 sieve-address = addr-spec ; simple address 390 / phrase "<" addr-spec ">" ; name & addr-spec 392 That is, routes and group syntax are not permitted. If multiple 393 addresses are required, use a string list. Named groups are not used 394 here. 396 Implementations MUST ensure that the addresses are syntactically 397 valid, but need not ensure that they actually identify an email 398 recipient. 400 2.4.2.4. MIME Parts 402 In a few places, [MIME] body parts are represented as strings. These 403 parts include MIME headers and the body. This provides a way of 404 embedding typed data within a Sieve script so that, among other 405 things, character sets other than UTF-8 can be used for output 406 messages. 408 2.5. Tests 410 Tests are given as arguments to commands in order to control their 411 actions. In this document, tests are given to if/elsif/else to 412 decide which block of code is run. 414 2.5.1. Test Lists 416 Some tests ("allof" and "anyof", which implement logical "and" and 417 logical "or", respectively) may require more than a single test as an 418 argument. The test-list syntax element provides a way of grouping 419 tests. 421 Example: if anyof (not exists ["From", "Date"], 422 header :contains "from" "fool@example.edu") { 423 discard; 424 } 426 2.6. Arguments 428 In order to specify what to do, most commands take arguments. There 429 are three types of arguments: positional, tagged, and optional. 431 2.6.1. Positional Arguments 432 Positional arguments are given to a command which discerns their 433 meaning based on their order. When a command takes positional 434 arguments, all positional arguments must be supplied and must be in 435 the order prescribed. 437 2.6.2. Tagged Arguments 439 This document provides for tagged arguments in the style of 440 CommonLISP. These are also similar to flags given to commands in 441 most command-line systems. 443 A tagged argument is an argument for a command that begins with ":" 444 followed by a tag naming the argument, such as ":contains". This 445 argument means that zero or more of the next tokens have some 446 particular meaning depending on the argument. These next tokens may 447 be numbers or strings but they are never blocks. 449 Tagged arguments are similar to positional arguments, except that 450 instead of the meaning being derived from the command, it is derived 451 from the tag. 453 Tagged arguments must appear before positional arguments, but they 454 may appear in any order with other tagged arguments. For simplicity 455 of the specification, this is not expressed in the syntax definitions 456 with commands, but they still may be reordered arbitrarily provided 457 they appear before positional arguments. Tagged arguments may be 458 mixed with optional arguments. 460 To simplify this specification, tagged arguments SHOULD NOT take 461 tagged arguments as arguments. 463 2.6.3. Optional Arguments 465 Optional arguments are exactly like tagged arguments except that they 466 may be left out, in which case a default value is implied. Because 467 optional arguments tend to result in shorter scripts, they have been 468 used far more than tagged arguments. 470 One particularly noteworthy case is the ":comparator" argument, which 471 allows the user to specify which comparator [COLLATION] will be used 472 to compare two strings, since different languages may impose 473 different orderings on UTF-8 [UTF-8] characters. 475 2.6.4. Types of Arguments 477 Abstractly, arguments may be literal data, tests, or blocks of 478 commands. In this way, an "if" control structure is merely a command 479 that happens to take a test and a block as arguments and may execute 480 the block of code. 482 However, this abstraction is ambiguous from a parsing standpoint. 483 The grammar in section 9.2 presents a parsable version of this: 484 Arguments are string-lists, numbers, and tags, which may be followed 485 by a test or a test-list, which may be followed by a block of 486 commands. No more than one test or test list, nor more than one 487 block of commands, may be used, and commands that end with blocks of 488 commands do not end with semicolons. 490 2.7. String Comparison 492 When matching one string against another, there are a number of ways 493 of performing the match operation. These are accomplished with three 494 types of matches: an exact match, a substring match, and a wildcard 495 glob-style match. These are described below. 497 In order to provide for matches between character sets and case 498 insensitivity, Sieve uses the comparators defined in the Internet 499 Application Protocol Collation Registry [COLLATION]. 501 However, when a string represents the name of a header, the 502 comparator is never user-specified. Header comparisons are always 503 done with the "en;ascii-casemap" operator, i.e., case-insensitive 504 comparisons, because this is the way things are defined in the 505 message specification [IMAIL]. 507 2.7.1. Match Type 509 There are three match types describing the matching used in this 510 specification: ":is", ":contains", and ":matches". Match type 511 arguments are supplied to those commands which allow them to specify 512 what kind of match is to be performed. 514 These are used as tagged arguments to tests that perform string 515 comparison. 517 The ":contains" match type describes a substring match. If the value 518 argument contains the key argument as a substring, the match is true. 519 For instance, the string "frobnitzm" contains "frob" and "nit", but 520 not "fbm". The empty key ("") is contained in all values. 522 The ":is" match type describes an absolute match; if the contents of 523 the first string are absolutely the same as the contents of the 524 second string, they match. Only the string "frobnitzm" is the string 525 "frobnitzm". The empty key ":is" and only ":is" the empty value. 527 The ":matches" match type specifies a wildcard match using the 528 characters "*" and "?"; the entire value must be matched. "*" 529 matches zero or more characters, and "?" matches a single character. 530 "?" and "*" may be escaped as "\\?" and "\\*" in strings to match 531 against themselves. The first backslash escapes the second 532 backslash; together, they escape the "*". This is awkward, but it is 533 commonplace in several programming languages that use globs and 534 regular expressions. 536 In order to specify what type of match is supposed to happen, 537 commands that support matching take optional tagged arguments 538 ":matches", ":is", and ":contains". Commands default to using ":is" 539 matching if no match type argument is supplied. Note that these 540 modifiers may interact with comparators; in particular, some 541 comparators are not suitable for matching with ":contains" or 542 ":matches". It is an error to use a comparator with ":contains" or 543 ":matches" that is not compatible with it. 545 It is an error to give more than one of these arguments to a given 546 command. 548 For convenience, the "MATCH-TYPE" syntax element is defined here as 549 follows: 551 Syntax: ":is" / ":contains" / ":matches" 553 2.7.2. Comparisons Across Character Sets 555 All Sieve scripts are represented in UTF-8, but messages may involve 556 a number of character sets. In order for comparisons to work across 557 character sets, implementations SHOULD implement the following 558 behavior: 560 Implementations decode header charsets to UTF-8. Two strings are 561 considered equal if their UTF-8 representations are identical. 562 Implementations should decode charsets represented in the forms 563 specified by [MIME] for both message headers and bodies. 564 Implementations must be capable of decoding US-ASCII, ISO-8859-1, 565 the ASCII subset of ISO-8859-* character sets, and UTF-8. 567 If implementations fail to support the above behavior, they MUST 568 conform to the following: 570 No two strings can be considered equal if one contains octets 571 greater than 127. 573 2.7.3. Comparators 575 In order to allow for language-independent, case-independent matches, 576 the match type may be coupled with a comparator name. The Internet 577 Application Protocol Collation Registry [COLLATION] provides the 578 framework for describing and naming comparators as used by this 579 specification. 581 While multiple comparator types are defined, only equality types are 582 used in this specification. 584 All implementations MUST support the "i;octet" comparator (simply 585 compares octets), the "en;ascii-casemap" comparator (which treats 586 uppercase and lowercase characters in the ASCII subset of UTF-8 as 587 the same), as well as the "i;ascii-casemap" comparator, which is a 588 deprecated synonym for "en;ascii-casemap". If left unspecified, the 589 default is "en;ascii-casemap". 591 Some comparators may not be usable with substring matches; that is, 592 they may only work with ":is". It is an error to try and use a 593 comparator with ":matches" or ":contains" that is not compatible with 594 it. 596 A comparator is specified by the ":comparator" option with commands 597 that support matching. This option is followed by a string providing 598 the name of the comparator to be used. For convenience, the syntax 599 of a comparator is abbreviated to "COMPARATOR", and (repeated in 600 several tests) is as follows: 602 Syntax: ":comparator" 604 So in this example, 606 Example: if header :contains :comparator "i;octet" "Subject" 607 "MAKE MONEY FAST" { 608 discard; 609 } 611 would discard any message with subjects like "You can MAKE MONEY 612 FAST", but not "You can Make Money Fast", since the comparator used 613 is case-sensitive. 615 Comparators other than "i;octet", "en;ascii-casemap", and "i;ascii- 616 casemap" must be declared with require, as they are extensions. If a 617 comparator declared with require is not known, it is an error, and 618 execution fails. If the comparator is not declared with require, it 619 is also an error, even if the comparator is supported. (See 2.10.5.) 621 Both ":matches" and ":contains" match types are compatible with the 622 "i;octet" and "en;ascii-casemap" comparators and may be used with 623 them. 625 It is an error to give more than one of these arguments to a given 626 command. 628 2.7.4. Comparisons Against Addresses 630 Addresses are one of the most frequent things represented as strings. 631 These are structured, and being able to compare against the local- 632 part or the domain of an address is useful, so some tests that act 633 exclusively on addresses take an additional optional argument that 634 specifies what the test acts on. 636 These optional arguments are ":localpart", ":domain", and ":all", 637 which act on the local-part (left-side), the domain part (right- 638 side), and the whole address. 640 The kind of comparison done, such as whether or not the test done is 641 case-insensitive, is specified as a comparator argument to the test. 643 If an optional address-part is omitted, the default is ":all". 645 It is an error to give more than one of these arguments to a given 646 command. 648 For convenience, the "ADDRESS-PART" syntax element is defined here as 649 follows: 651 Syntax: ":localpart" / ":domain" / ":all" 653 2.8. Blocks 655 Blocks are sets of commands enclosed within curly braces. Blocks are 656 supplied to commands so that the commands can implement control 657 commands. 659 A control structure is a command that happens to take a test and a 660 block as one of its arguments; depending on the result of the test 661 supplied as another argument, it runs the code in the block some 662 number of times. 664 With the commands supplied in this memo, there are no loops. The 665 control structures supplied--if, elsif, and else--run a block either 666 once or not at all. So there are two arguments, the test and the 667 block. 669 2.9. Commands 671 Sieve scripts are sequences of commands. Commands can take any of 672 the tokens above as arguments, and arguments may be either tagged or 673 positional arguments. Not all commands take all arguments. 675 There are three kinds of commands: test commands, action commands, 676 and control commands. 678 The simplest is an action command. An action command is an 679 identifier followed by zero or more arguments, terminated by a 680 semicolon. Action commands do not take tests or blocks as arguments. 682 A control command is similar, but it takes a test as an argument, and 683 ends with a block instead of a semicolon. 685 A test command is used as part of a control command. It is used to 686 specify whether or not the block of code given to the control command 687 is executed. 689 2.10. Evaluation 691 2.10.1. Action Interaction 693 Some actions cannot be used with other actions because the result 694 would be absurd. These restrictions are noted throughout this memo. 696 Extension actions MUST state how they interact with actions defined 697 in this specification. 699 2.10.2. Implicit Keep 701 Previous experience with filtering systems suggests that cases tend 702 to be missed in scripts. To prevent errors, Sieve has an "implicit 703 keep". 705 An implicit keep is a keep action (see 4.4) performed in absence of 706 any action that cancels the implicit keep. 708 An implicit keep is performed if a message is not written to a 709 mailbox, redirected to a new address, or explicitly thrown out. That 710 is, if a fileinto, a keep, a redirect, or a discard is performed, an 711 implicit keep is not. 713 Some actions may be defined to not cancel the implicit keep. These 714 actions may not directly affect the delivery of a message, and are 715 used for their side effects. None of the actions specified in this 716 document meet that criteria, but extension actions will. 718 For instance, with any of the short messages offered above, the 719 following script produces no actions. 721 Example: if size :over 500K { discard; } 723 As a result, the implicit keep is taken. 725 2.10.3. Message Uniqueness in a Mailbox 727 Implementations SHOULD NOT deliver a message to the same folder more 728 than once, even if a script explicitly asks for a message to be 729 written to a mailbox twice. 731 The test for equality of two messages is implementation-defined. 733 If a script asks for a message to be written to a mailbox twice, it 734 MUST NOT be treated as an error. 736 2.10.4. Limits on Numbers of Actions 738 Site policy MAY limit numbers of actions taken and MAY impose 739 restrictions on which actions can be used together. In the event 740 that a script hits a policy limit on the number of actions taken for 741 a particular message, an error occurs. 743 Implementations MUST allow at least one keep or one fileinto. If 744 fileinto is not implemented, implementations MUST allow at least one 745 keep. 747 2.10.5. Extensions and Optional Features 749 Because of the differing capabilities of many mail systems, several 750 features of this specification are optional. Before any of these 751 extensions can be executed, they must be declared with the "require" 752 action. 754 If an extension is not enabled with "require", implementations MUST 755 treat it as if they did not support it at all. 757 If a script does not understand an extension declared with require, 758 the script must not be used at all. Implementations MUST NOT execute 759 scripts which require unknown capability names. 761 Note: The reason for this restriction is that prior experiences with 762 languages such as LISP and Tcl suggest that this is a workable 763 way of noting that a given script uses an extension. 765 Experience with PostScript suggests that mechanisms that allow 766 a script to work around missing extensions are not used in 767 practice. 769 Extensions which define actions MUST state how they interact with 770 actions discussed in the base specification. 772 2.10.6. Errors 774 In any programming language, there are compile-time and run-time 775 errors. 777 Compile-time errors are ones in syntax that are detectable if a 778 syntax check is done. 780 Run-time errors are not detectable until the script is run. This 781 includes transient failures like disk full conditions, but also 782 includes issues like invalid combinations of actions. 784 When an error occurs in a Sieve script, all processing stops. 786 Implementations MAY choose to do a full parse, then evaluate the 787 script, then do all actions. Implementations might even go so far as 788 to ensure that execution is atomic (either all actions are executed 789 or none are executed). 791 Other implementations may choose to parse and run at the same time. 792 Such implementations are simpler, but have issues with partial 793 failure (some actions happen, others don't). 795 Implementations might even go so far as to ensure that scripts can 796 never execute an invalid set of actions before execution, although 797 this could involve solving the Halting Problem. 799 This specification allows any of these approaches. Solving the 800 Halting Problem is considered extra credit. 802 When an error happens, implementations MUST notify the user that an 803 error occurred, which actions (if any) were taken, and do an implicit 804 keep. 806 2.10.7. Limits on Execution 808 Implementations may limit certain constructs. However, this 809 specification places a lower bound on some of these limits. 811 Implementations MUST support fifteen levels of nested blocks. 813 Implementations MUST support fifteen levels of nested test lists. 815 3. Control Commands 816 Control structures are needed to allow for multiple and conditional 817 actions. 819 3.1. Control Structure If 821 There are three pieces to if: "if", "elsif", and "else". Each is 822 actually a separate command in terms of the grammar. However, an 823 elsif or else MUST only follow an if or elsif. An error occurs if 824 these conditions are not met. 826 Syntax: if 828 Syntax: elsif 830 Syntax: else 832 The semantics are similar to those of any of the many other 833 programming languages these control commands appear in. When the 834 interpreter sees an "if", it evaluates the test associated with it. 835 If the test is true, it executes the block associated with it. 837 If the test of the "if" is false, it evaluates the test of the first 838 "elsif" (if any). If the test of "elsif" is true, it runs the 839 elsif's block. An elsif may be followed by an elsif, in which case, 840 the interpreter repeats this process until it runs out of elsifs. 842 When the interpreter runs out of elsifs, there may be an "else" case. 843 If there is, and none of the if or elsif tests were true, the 844 interpreter runs the else case. 846 This provides a way of performing exactly one of the blocks in the 847 chain. 849 In the following example, both Message A and B are dropped. 851 Example: require "fileinto"; 852 if header :contains "from" "coyote" { 853 discard; 854 } elsif header :contains ["subject"] ["$$$"] { 855 discard; 856 } else { 857 fileinto "INBOX"; 858 } 860 When the script below is run over message A, it redirects the message 861 to acm@example.edu; message B, to postmaster@example.edu; any other 862 message is redirected to field@example.edu. 864 Example: if header :contains ["From"] ["coyote"] { 865 redirect "acm@example.edu"; 866 } elsif header :contains "Subject" "$$$" { 867 redirect "postmaster@example.edu"; 868 } else { 869 redirect "field@example.edu"; 870 } 872 Note that this definition prohibits the "... else if ..." sequence 873 used by C. This is intentional, because this construct produces a 874 shift-reduce conflict. 876 3.2. Control Structure Require 878 Syntax: require 880 The require action notes that a script makes use of a certain 881 extension. Such a declaration is required to use the extension, as 882 discussed in section 2.10.5. Multiple capabilities can be declared 883 with a single require. 885 The require command, if present, MUST be used before anything other 886 than a require can be used. An error occurs if a require appears 887 after a command other than require. 889 Example: require ["fileinto", "reject"]; 891 Example: require "fileinto"; 892 require "vacation"; 894 3.3. Control Structure Stop 896 Syntax: stop 898 The "stop" action ends all processing. If no actions have been 899 executed, then the keep action is taken. 901 4. Action Commands 903 This document supplies four actions that may be taken on a message: 904 keep, fileinto, redirect, and discard. 906 Implementations MUST support the "keep", "discard", and "redirect" 907 actions. 909 Implementations SHOULD support "fileinto". 911 Implementations MAY limit the number of certain actions taken (see 912 section 2.10.4). 914 4.1. Action fileinto 916 Syntax: fileinto 918 The "fileinto" action delivers the message into the specified folder. 919 Implementations SHOULD support fileinto, but in some environments 920 this may be impossible. 922 The capability string for use with the require command is "fileinto". 924 In the following script, message A is filed into folder 925 "INBOX.harassment". 927 Example: require "fileinto"; 928 if header :contains ["from"] "coyote" { 929 fileinto "INBOX.harassment"; 930 } 932 4.2. Action redirect 934 Syntax: redirect 936 The "redirect" action is used to send the message to another user at 937 a supplied address, as a mail forwarding feature does. The 938 "redirect" action makes no changes to the message body or existing 939 headers, but it may add new headers. The "redirect" modifies the 940 envelope recipient. 942 The redirect command performs an MTA-style "forward"--that is, what 943 you get from a .forward file using sendmail under UNIX. The address 944 on the [SMTP] envelope is replaced with the one on the redirect 945 command and the message is sent back out. (This is not an MUA-style 946 forward, which creates a new message with a different sender and 947 message ID, wrapping the old message in a new one.) 949 A simple script can be used for redirecting all mail: 951 Example: redirect "bart@example.edu"; 953 Implementations SHOULD take measures to implement loop control, 954 possibly including adding headers to the message or counting received 955 headers. If an implementation detects a loop, it causes an error. 957 4.3. Action keep 959 Syntax: keep 960 The "keep" action is whatever action is taken in lieu of all other 961 actions, if no filtering happens at all; generally, this simply means 962 to file the message into the user's main mailbox. This command 963 provides a way to execute this action without needing to know the 964 name of the user's main mailbox, providing a way to call it without 965 needing to understand the user's setup, or the underlying mail 966 system. 968 For instance, in an implementation where the Internet Message Access 969 Protocol (IMAP) server is running scripts on behalf of the user at 970 time of delivery, a keep command is equivalent to a fileinto "INBOX". 972 Example: if size :under 1M { keep; } else { discard; } 974 Note that the above script is identical to the one below. 976 Example: if not size :under 1M { discard; } 978 4.4. Action discard 980 Syntax: discard 982 Discard is used to silently throw away the message. It does so by 983 simply canceling the implicit keep. If discard is used with other 984 actions, the other actions still happen. Discard is compatible with 985 all other actions. (For instance fileinto+discard is equivalent to 986 fileinto.) 988 Discard MUST be silent; that is, it MUST NOT return a non-delivery 989 notification of any kind ([DSN], [MDN], or otherwise). 991 In the following script, any mail from "idiot@example.edu" is thrown 992 out. 994 Example: if header :contains ["from"] ["idiot@example.edu"] { 995 discard; 996 } 998 While an important part of this language, "discard" has the potential 999 to create serious problems for users: Students who leave themselves 1000 logged in to an unattended machine in a public computer lab may find 1001 their script changed to just "discard". In order to protect users in 1002 this situation (along with similar situations), implementations MAY 1003 keep messages destroyed by a script for an indefinite period, and MAY 1004 disallow scripts that throw out all mail. 1006 5. Test Commands 1007 Tests are used in conditionals to decide which part(s) of the 1008 conditional to execute. 1010 Implementations MUST support these tests: "address", "allof", 1011 "anyof", "exists", "false", "header", "not", "size", and "true". 1013 Implementations SHOULD support the "envelope" test. 1015 5.1. Test address 1017 Syntax: address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] 1018 1020 The address test matches Internet addresses in structured headers 1021 that contain addresses. It returns true if any header contains any 1022 key in the specified part of the address, as modified by the 1023 comparator and the match keyword. Whether there are other addresses 1024 present in the header doesn't affect this test; this test does not 1025 provide any way to determine whether an address is the only address 1026 in a header. 1028 Like envelope and header, this test returns true if any combination 1029 of the header-list and key-list arguments match. 1031 Internet email addresses [IMAIL] have the somewhat awkward 1032 characteristic that the local-part to the left of the at-sign is 1033 considered case sensitive, and the domain-part to the right of the 1034 at-sign is case insensitive. The "address" command does not deal 1035 with this itself, but provides the ADDRESS-PART argument for allowing 1036 users to deal with it. 1038 The address primitive never acts on the phrase part of an email 1039 address, nor on comments within that address. It also never acts on 1040 group names, although it does act on the addresses within the group 1041 construct. 1043 Implementations MUST restrict the address test to headers that 1044 contain addresses, but MUST include at least From, To, Cc, Bcc, 1045 Sender, Resent-From, Resent-To, and SHOULD include any other header 1046 that utilizes an "address-list" structured header body. 1048 Example: if address :is :all "from" "tim@example.com" { 1049 discard; 1051 5.2. Test allof 1053 Syntax: allof 1054 The allof test performs a logical AND on the tests supplied to it. 1056 Example: allof (false, false) => false 1057 allof (false, true) => false 1058 allof (true, true) => true 1060 The allof test takes as its argument a test-list. 1062 5.3. Test anyof 1064 Syntax: anyof 1066 The anyof test performs a logical OR on the tests supplied to it. 1068 Example: anyof (false, false) => false 1069 anyof (false, true) => true 1070 anyof (true, true) => true 1072 5.4. Test envelope 1074 Syntax: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] 1075 1077 The "envelope" test is true if the specified part of the SMTP (or 1078 equivalent) envelope matches the specified key. 1080 If one of the envelope-part strings is (case insensitive) "from", 1081 then matching occurs against the FROM address used in the SMTP MAIL 1082 command. 1084 If one of the envelope-part strings is (case insensitive) "to", then 1085 matching occurs against the TO address used in the SMTP RCPT command 1086 that resulted in this message getting delivered to this user. Note 1087 that only the most recent TO is available, and only the one relevant 1088 to this user. 1090 The envelope-part is a string list and may contain more than one 1091 parameter, in which case all of the strings specified in the key-list 1092 are matched against all parts given in the envelope-part list. 1094 Like address and header, this test returns true if any combination of 1095 the envelope-part and key-list arguments is true. 1097 All tests against envelopes MUST drop source routes. 1099 If the SMTP transaction involved several RCPT commands, only the data 1100 from the RCPT command that caused delivery to this user is available 1101 in the "to" part of the envelope. 1103 If a protocol other than SMTP is used for message transport, 1104 implementations are expected to adapt this command appropriately. 1106 The envelope command is optional. Implementations SHOULD support it, 1107 but the necessary information may not be available in all cases. 1109 Example: require "envelope"; 1110 if envelope :all :is "from" "tim@example.com" { 1111 discard; 1112 } 1114 5.5. Test exists 1116 Syntax: exists 1118 The "exists" test is true if the headers listed in the header-names 1119 argument exist within the message. All of the headers must exist or 1120 the test is false. 1122 The following example throws out mail that doesn't have a From header 1123 and a Date header. 1125 Example: if not exists ["From","Date"] { 1126 discard; 1127 } 1129 5.6. Test false 1131 Syntax: false 1133 The "false" test always evaluates to false. 1135 5.7. Test header 1137 Syntax: header [COMPARATOR] [MATCH-TYPE] 1138 1140 The "header" test evaluates to true if any header name matches any 1141 key. The type of match is specified by the optional match argument, 1142 which defaults to ":is" if not specified, as specified in section 1143 2.6. 1145 Like address and envelope, this test returns true if any combination 1146 of the string-list and key-list arguments match. 1148 If a header listed in the header-names argument exists, it contains 1149 the empty key (""). However, if the named header is not present, it 1150 does not contain the empty key. So if a message contained the header 1151 X-Caffeine: C8H10N4O2 1153 these tests on that header evaluate as follows: 1155 header :is ["X-Caffeine"] [""] => false 1156 header :contains ["X-Caffeine"] [""] => true 1158 5.8. Test not 1160 Syntax: not 1162 The "not" test takes some other test as an argument, and yields the 1163 opposite result. "not false" evaluates to "true" and "not true" 1164 evaluates to "false". 1166 5.9. Test size 1168 Syntax: size <":over" / ":under"> 1170 The "size" test deals with the size of a message. It takes either a 1171 tagged argument of ":over" or ":under", followed by a number 1172 representing the size of the message. 1174 If the argument is ":over", and the size of the message is greater 1175 than the number provided, the test is true; otherwise, it is false. 1177 If the argument is ":under", and the size of the message is less than 1178 the number provided, the test is true; otherwise, it is false. 1180 Exactly one of ":over" or ":under" must be specified, and anything 1181 else is an error. 1183 The size of a message is defined to be the number of octets from the 1184 initial header until the last character in the message body. 1186 Note that for a message that is exactly 4,000 octets, the message is 1187 neither ":over" 4000 octets or ":under" 4000 octets. 1189 5.10. Test true 1191 Syntax: true 1193 The "true" test always evaluates to true. 1195 6. Extensibility 1197 New control structures, actions, and tests can be added to the 1198 language. Sites must make these features known to their users; this 1199 document does not define a way to discover the list of extensions 1200 supported by the server. 1202 Any extensions to this language MUST define a capability string that 1203 uniquely identifies that extension. If a new version of an extension 1204 changes the functionality of a previously defined extension, it MUST 1205 use a different name. 1207 In a situation where there is a submission protocol and an extension 1208 advertisement mechanism aware of the details of this language, 1209 scripts submitted can be checked against the mail server to prevent 1210 use of an extension that the server does not support. 1212 Extensions MUST state how they interact with constraints defined in 1213 section 2.10, e.g., whether they cancel the implicit keep, and which 1214 actions they are compatible and incompatible with. 1216 6.1. Capability String 1218 Capability strings are typically short strings describing what 1219 capabilities are supported by the server. 1221 Capability strings beginning with "vnd." represent vendor-defined 1222 extensions. Such extensions are not defined by Internet standards or 1223 RFCs, but are still registered with IANA in order to prevent 1224 conflicts. Extensions starting with "vnd." SHOULD be followed by the 1225 name of the vendor and product, such as "vnd.acme.rocket-sled". 1227 The following capability strings are defined by this document: 1229 envelope The string "envelope" indicates that the implementation 1230 supports the "envelope" command. 1232 fileinto The string "fileinto" indicates that the implementation 1233 supports the "fileinto" command. 1235 comparator- The string "comparator-elbonia" is provided if the 1236 implementation supports the "elbonia" comparator. 1237 Therefore, all implementations have at least the 1238 "comparator-i;octet", "comparator-en;ascii-casemap", 1239 and "comparator-i;ascii-casemap" capabilities. However, 1240 these comparators may be used without being declared 1241 with require. 1243 6.2. IANA Considerations 1245 In order to provide a standard set of extensions, a registry is 1246 provided by IANA. Capability names may be registered on a first- 1247 come, first-served basis. Extensions designed for interoperable use 1248 SHOULD be defined as standards track or IESG approved experimental 1249 RFCs. 1251 6.2.1. Template for Capability Registrations 1253 The following template is to be used for registering new Sieve 1254 extensions with IANA. 1256 To: iana@iana.org 1257 Subject: Registration of new Sieve extension 1259 Capability name: 1260 Capability keyword: 1261 Capability arguments: 1262 Standards Track/IESG-approved experimental RFC number: 1263 Person and email address to contact for further information: 1265 6.2.2. Initial Capability Registrations 1267 This RFC updates the the following entries in the IANA registry for 1268 Sieve extensions. 1270 Capability name: fileinto 1271 Capability keyword: fileinto 1272 Capability arguments: fileinto 1273 Standards Track/IESG-approved experimental RFC number: 1274 This RFC (Sieve base spec) 1275 Person and email address to contact for further information: 1276 The Sieve discussion list 1278 Capability name: envelope 1279 Capability keyword: envelope 1280 Capability arguments: 1281 envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] 1282 1283 Standards Track/IESG-approved experimental RFC number: 1284 This RFC (Sieve base spec) 1285 Person and email address to contact for further information: 1286 The Sieve discussion list 1288 Capability name: comparator-* 1289 Capability keyword: 1290 comparator-* (anything starting with "comparator-") 1291 Capability arguments: (none) 1292 Standards Track/IESG-approved experimental RFC number: 1293 This RFC, Sieve, by reference to [COLLATION] 1294 Person and email address to contact for further information: 1296 The Sieve discussion list 1298 6.3. Capability Transport 1300 As the range of mail systems that this document is intended to apply 1301 to is quite varied, a method of advertising which capabilities an 1302 implementation supports is difficult due to the wide range of 1303 possible implementations. Such a mechanism, however, should have the 1304 property that the implementation can advertise the complete set of 1305 extensions that it supports. 1307 7. Transmission 1309 The MIME type for a Sieve script is "application/sieve". 1311 The registration of this type for RFC 2048 requirements is updated as 1312 follows: 1314 Subject: Registration of MIME media type application/sieve 1316 MIME media type name: application 1317 MIME subtype name: sieve 1318 Required parameters: none 1319 Optional parameters: none 1320 Encoding considerations: Most sieve scripts will be textual, 1321 written in UTF-8. When non-7bit characters are used, 1322 quoted-printable is appropriate for transport systems 1323 that require 7bit encoding. 1325 Security considerations: Discussed in section 10 of this RFC. 1326 Interoperability considerations: Discussed in section 2.10.5 1327 of this RFC. 1328 Published specification: this RFC. 1329 Applications which use this media type: sieve-enabled mail servers 1330 Additional information: 1331 Magic number(s): 1332 File extension(s): .siv 1333 Macintosh File Type Code(s): 1334 Person & email address to contact for further information: 1335 See the discussion list at ietf-mta-filters@imc.org. 1336 Intended usage: 1337 COMMON 1338 Author/Change controller: 1339 See Editor information in this RFC. 1341 8. Parsing 1343 The Sieve grammar is separated into tokens and a separate grammar as 1344 most programming languages are. 1346 8.1. Lexical Tokens 1348 Sieve scripts are encoded in UTF-8. The following assumes a valid 1349 UTF-8 encoding; special characters in Sieve scripts are all ASCII. 1351 The following are tokens in Sieve: 1353 - identifiers 1354 - tags 1355 - numbers 1356 - quoted strings 1357 - multi-line strings 1358 - other separators 1360 Blanks, horizontal tabs, CRLFs, and comments ("white space") are 1361 ignored except as they separate tokens. Some white space is required 1362 to separate otherwise adjacent tokens and in specific places in the 1363 multi-line strings. CR and LF can only appear in CRLF pairs. 1365 The other separators are single individual characters, and are 1366 mentioned explicitly in the grammar. 1368 The lexical structure of sieve is defined in the following grammar 1369 (as described in [ABNF]): 1371 bracket-comment = "/*" *not-star 1*STAR 1372 *(not-star-slash *not-star 1*STAR) "/" 1373 ; No */ allowed inside a comment. 1374 ; (No * is allowed unless it is the last 1375 ; character, or unless it is followed by a 1376 ; character that isn't a slash.) 1378 STAR = "*" 1380 not-star = CRLF / %x01-09 / %x0b-0c / %x0e-29 / %x2b-7f / 1381 UTF8-2 / UTF8-3 / UTF8-4 1382 ; either a CRLF pair, OR a single UTF-8 1383 ; character other than NUL, CR, LF, or star 1385 not-star-or-slash = CRLF / %x01-09 / %x0b-0c / %x0e-29 / %x2b-2e / 1386 %x30-7f / UTF8-2 / UTF8-3 / UTF8-4 1387 ; either a CRLF pair, OR a single UTF-8 1388 ; character other than NUL, CR, LF, star, 1389 ; or slash 1391 UTF8-NOT-CRLF = %x01-09 / %x0b-0c / %x0e-7f / 1392 UTF8-2 / UTF8-3 / UTF8-4 1393 ; a single UTF-8 character other than NUL, 1394 ; CR, or LF 1396 UTF8-NOT-PERIOD = %x01-09 / %x0b-0c / %x0e-2d / %x2f-7f / 1397 UTF8-2 / UTF8-3 / UTF8-4 1398 ; a single UTF-8 character other than NUL, 1399 ; CR, LF, or period 1401 UTF8-NOT-NUL = %x01-7f / UTF8-2 / UTF8-3 / UTF8-4 1402 ; a single UTF-8 character other than NUL 1404 UTF8-NOT-QSPECIAL = %x01-09 / %x0b-0c / %x0e-21 / %x23-5b / 1405 %x5d-7f / UTF8-2 / UTF8-3 / UTF8-4 1406 ; a single UTF-8 character other than NUL, 1407 ; CR, LF, double-quote, or backslash 1409 comment = bracket-comment / hash-comment 1411 hash-comment = "#" *UTF8-NOT-CRLF CRLF 1413 identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_") 1415 tag = ":" identifier 1417 number = 1*DIGIT [QUANTIFIER] 1419 QUANTIFIER = "K" / "M" / "G" 1421 quoted-safe = CRLF / UTF8-NOT-QSPECIAL 1422 ; either a CRLF pair, OR a single UTF-8 1423 ; character other than NUL, CR, LF, 1424 ; double-quote, or backslash 1426 quoted-special = "\" ( DQUOTE / "\" ) 1427 ; represents just a double-quote or backslash 1429 quoted-other = "\" UTF8-NOT-QSPECIAL 1430 ; represents just the UTF8-NOT-QSPECIAL 1431 ; character. SHOULD NOT be used 1433 quoted-text = *(quoted-safe / quoted-special / quoted-other) 1435 quoted-string = DQUOTE quoted-text DQUOTE 1437 multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF) 1438 *(multiline-literal / multiline-dotstuff) 1439 "." CRLF 1441 multiline-literal = [UTF8-NOT-PERIOD *UTF8-NOT-CRLF] CRLF 1443 multiline-dotstuff = "." 1*UTF8-NOT-CRLF CRLF 1444 ; A line containing only "." ends the 1445 ; multi-line. Remove a leading '.' if 1446 ; followed by another '.'. 1448 white-space = 1*(SP / CRLF / HTAB) / comment 1450 8.2. Grammar 1452 The following is the grammar of Sieve after it has been lexically 1453 interpreted. No white space or comments appear below. The start 1454 symbol is "start". 1456 argument = string-list / number / tag 1458 arguments = *argument [test / test-list] 1460 block = "{" commands "}" 1462 command = identifier arguments ( ";" / block ) 1464 commands = *command 1466 start = commands 1468 string = quoted-string / multi-line 1470 string-list = "[" string *("," string) "]" / string 1471 ; if there is only a single string, the brackets 1472 ; are optional 1474 test = identifier arguments 1476 test-list = "(" test *("," test) ")" 1478 9. Extended Example 1480 The following is an extended example of a Sieve script. Note that it 1481 does not make use of the implicit keep. 1483 # 1484 # Example Sieve Filter 1485 # Declare any optional features or extension used by the script 1486 # 1487 require ["fileinto"]; 1488 # 1489 # Handle messages from known mailing lists 1490 # Move messages from IETF filter discussion list to filter folder 1491 # 1492 if header :is "Sender" "owner-ietf-mta-filters@imc.org" 1493 { 1494 fileinto "filter"; # move to "filter" folder 1495 } 1496 # 1497 # Keep all messages to or from people in my company 1498 # 1499 elsif address :domain :is ["From", "To"] "example.com" 1500 { 1501 keep; # keep in "In" folder 1502 } 1504 # 1505 # Try and catch unsolicited email. If a message is not to me, 1506 # or it contains a subject known to be spam, file it away. 1507 # 1508 elsif anyof (not address :all :contains 1509 ["To", "Cc", "Bcc"] "me@example.com", 1510 header :matches "subject" 1511 ["*make*money*fast*", "*university*dipl*mas*"]) 1512 { 1513 # If message header does not contain my address, 1514 # it's from a list. 1515 fileinto "spam"; # move to "spam" folder 1516 } 1517 else 1518 { 1519 # Move all other (non-company) mail to "personal" 1520 # folder. 1521 fileinto "personal"; 1522 } 1524 10. Security Considerations 1526 Users must get their mail. It is imperative that whatever method 1527 implementations use to store the user-defined filtering scripts be 1528 secure. 1530 It is equally important that implementations sanity-check the user's 1531 scripts, and not allow users to create on-demand mailbombs. For 1532 instance, an implementation that allows a user to redirect a message 1533 multiple times might also allow a user to create a mailbomb triggered 1534 by mail from a specific user. Site- or implementation-defined limits 1535 on actions are useful for this. 1537 Several commands, such as "discard", "redirect", and "fileinto" allow 1538 for actions to be taken that are potentially very dangerous. 1540 Implementations SHOULD take measures to prevent languages from 1541 looping. 1543 11. Acknowledgments 1545 This document has been revised in part based on comments and 1546 discussions that took place on and off the SIEVE mailing list. 1547 Thanks to Cyrus Daboo, Ned Freed, Michael Haardt, Kjetil Torgrim 1548 Homme, Barry Leiba, Mark E. Mallett, Alexey Melnikov, Rob Siemborski, 1549 and Nigel Swinson for reviews and suggestions. 1551 12. Editors' Addresses 1553 Philip Guenther 1554 Sendmail, Inc. 1555 6425 Christie St. Ste 400 1556 Emeryville, CA 94608 1557 Email: guenther@sendmail.com 1559 Tim Showalter 1560 Email: tjs@psaux.com 1562 13. Normative References 1564 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1565 Specifications: ABNF", RFC 2234, November 1997. 1567 [COLLATION] Newman, C. and M. Duerst, "Internet Application Protocol 1568 Collation Registry" draft-newman-i18n-comparator-03.txt 1569 (work in progress), October 2004. 1571 [IMAIL] P. Resnick, Ed., "Internet Message Format", RFC 2822, 1572 April 2001. 1574 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1575 Requirement Levels", BCP 14, RFC 2119, March 1997. 1577 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1578 Extensions (MIME) Part One: Format of Internet Message 1579 Bodies", RFC 2045, November 1996. 1581 [MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition 1582 Notification", RFC 3798, May 2004. 1584 [SMTP] J. Klensin, Ed., "Simple Mail Transfer Protocol", RFC 1585 2821, April 2001. 1587 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 1588 10646", RFC 3629, November 2003. 1590 14. Informative References 1592 [BINARY-SI] "Standard IEC 60027-2: Letter symbols to be used in 1593 electrical technology - Part 2: Telecommunications and 1594 electronics", January 1999. 1596 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1597 for Delivery Status Notifications", RFC 1894, January 1598 1996. 1600 [FLAMES] Borenstein, N, and C. Thyberg, "Power, Ease of Use, and 1601 Cooperative Work in a Practical Multimedia Message 1602 System", Int. J. of Man-Machine Studies, April, 1991. 1603 Reprinted in Computer-Supported Cooperative Work and 1604 Groupware, Saul Greenberg, editor, Harcourt Brace 1605 Jovanovich, 1991. Reprinted in Readings in Groupware and 1606 Computer-Supported Cooperative Work, Ronald Baecker, 1607 editor, Morgan Kaufmann, 1993. 1609 [IMAP] Crispin, M., "Internet Message Access Protocol - version 1610 4rev1", RFC 3501, March 2003. 1612 14. Full Copyright Statement 1614 Copyright (C) The Internet Society (2005). 1616 This document is subject to the rights, licenses and restrictions 1617 contained in BCP 78, and except as set forth therein, the authors 1618 retain all their rights. 1620 This document and the information contained herein are provided on an 1621 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1622 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1623 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1624 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1625 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1628 Intellectual Property 1630 The IETF takes no position regarding the validity or scope of any 1631 Intellectual Property Rights or other rights that might be claimed to 1632 pertain to the implementation or use of the technology described in 1633 this document or the extent to which any license under such rights 1634 might or might not be available; nor does it represent that it has 1635 made any independent effort to identify any such rights. Information 1636 on the procedures with respect to rights in RFC documents can be 1637 found in BCP 78 and BCP 79. 1639 Copies of IPR disclosures made to the IETF Secretariat and any 1640 assurances of licenses to be made available, or the result of an 1641 attempt made to obtain a general license or permission for the use of 1642 such proprietary rights by implementers or users of this 1643 specification can be obtained from the IETF on-line IPR repository at 1644 http://www.ietf.org/ipr. 1646 The IETF invites any interested party to bring to its attention any 1647 copyrights, patents or patent applications, or other proprietary 1648 rights that may cover technology that may be required to implement 1649 this standard. Please address the information to the IETF at ietf- 1650 ipr@ietf.org. 1652 Acknowledgement 1654 Funding for the RFC Editor function is currently provided by the 1655 Internet Society. 1657 Append A. Change History 1659 This section will be removed when this document leaves the Internet- 1660 Draft stage. 1662 Open Issues: 1663 - should 'redirect' provide an argument for specifying the envelope 1664 sender 1665 - should it be an error to give 'envelope' an envelope-part name 1666 other than "from" or "to"? 1667 - should the requirements in 2.7.2 be tightened up? 1669 Changes from draft-ietf-sieve-3028bis-01.txt 1670 1. Remove ban on side effects 1671 2. Remove definition of the 'reject' action, as it is being moved 1672 to the doc that also defines the 'refuse' action 1673 3. Update capability registrations to reference the mailing list 1674 4. Add Tim back as an editor 1675 5. Refer to the zero-length string ("") as "empty" instead of 1676 "null" 1678 Changes from draft-ietf-sieve-3028bis-00.txt 1679 1. More grammar corrections: 1681 - permit /***/, 1682 - remove ambiguity in finding end of bracket comment, 1683 - require valid UTF-8, 1684 - express quoting in the grammar 1685 - ban bare CR and LF in all locations 1686 2. Correct a bunch of whitespace and linewrapping nits 1687 3. Update IMAIL and SMTP references RFC 2822 and RFC 2821 1688 4. Require support for en;ascii-casemap comparator as well as the 1689 old i;ascii-casemap. As with the old one, you do not need to 1690 use 'require' to use the new comparator. 1691 5. Update IANA considerations to update the existing registrations 1692 to point at this doc instead of 3028. 1693 6. Scripts SHOULD NOT contain superfluous backslashes 1694 7. Update Acknowledgments 1696 Changes from RFC 3028 1697 1. Split references into normative and informative 1698 2. Update references to current versions of DSN, IMAP, MDN, and 1699 UTF-8 RFCs 1700 3. Replace "e-mail" with "email" 1701 4. Incorporate RFC 3028 errata 1702 5. The "reject" action cancels the implicit keep 1703 6. Replace references to ACAP with references to the i18n-comparator 1704 draft. Further work is needed to completely sync with that 1705 draft. 1706 7. Start to update grammar to only permit legal UTF-8 (incomplete) 1707 and correct various other errors and typos 1708 8. Update IPR broilerplate to RFC 3978/3979