idnits 2.17.1 draft-ietf-appsawg-sieve-duplicate-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2014) is 3586 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) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 APPSAWG S. Bosch 3 Internet-Draft June 26, 2014 4 Intended status: Standards Track 5 Expires: December 28, 2014 7 Sieve Email Filtering: Detecting Duplicate Deliveries 8 draft-ietf-appsawg-sieve-duplicate-08 10 Abstract 12 This document defines a new test command "duplicate" for the "Sieve" 13 email filtering language. This test adds the ability to detect 14 duplications. The main application for this new test is handling 15 duplicate deliveries commonly caused by mailing list subscriptions or 16 redirected mail addresses. The detection is normally performed by 17 matching the message ID to an internal list of message IDs from 18 previously delivered messages. For more complex applications, the 19 "duplicate" test can also use the content of a specific header or 20 other parts of the message. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 28, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 3. Test "duplicate" . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Arguments ":header" and ":uniqueid" . . . . . . . . . . . 5 60 3.2. Argument ":handle" . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Arguments ":seconds" and ":last" . . . . . . . . . . . . . 7 62 3.4. Interaction with Other Sieve Extensions . . . . . . . . . 8 63 4. Sieve Capability Strings . . . . . . . . . . . . . . . . . . . 8 64 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 This document specifies an extension to the Sieve filtering language 80 defined by RFC 5228 [SIEVE]. It adds a test to track whether or not 81 a text string was seen before by the delivery agent in an earlier 82 execution of the Sieve script. This can be used to detect and handle 83 duplicate message deliveries. 85 Duplicate deliveries are a common side-effect of being subscribed to 86 a mailing list. For example, if a member of the list decides to 87 reply to both the user and the mailing list itself, the user will 88 often get one copy of the message directly and another through the 89 mailing list. Also, if someone cross-posts over several mailing 90 lists to which the user is subscribed, the user will likely receive a 91 copy from each of those lists. In another scenario, the user has 92 several redirected mail addresses all pointing to his main mail 93 account. If one of the user's contacts sends the message to more 94 than one of those addresses, the user will likely receive more than a 95 single copy. Using the "duplicate" extension, users have the means 96 to detect and handle such duplicates, e.g. by discarding them, 97 marking them as "seen", or putting them in a special folder. 99 Duplicate messages are normally detected using the Message-ID header 100 field, which is required to be unique for each message. However, the 101 "duplicate" test is flexible enough to use different criteria for 102 defining what makes a message a duplicate, for example using the 103 subject line or parts of the message body. Other applications of 104 this new test command are also possible, as long as the tracked 105 unique value is a string. 107 2. Conventions Used in This Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [KEYWORDS]. 113 Conventions for notations are as in [SIEVE] Section 1.1, including 114 use of the "Usage:" label for the definition of action and tagged 115 arguments syntax. 117 3. Test "duplicate" 119 Usage: "duplicate" [":handle" ] 120 [":header" / 121 ":uniqueid" ] 122 [":seconds" ] [":last"] 124 The "duplicate" test identifies the message by a "unique ID", and, 125 using that unique ID, keeps track of which messages were seen by a 126 "duplicate" test during an earlier Sieve execution. In its basic 127 form, the test gets the unique ID from the content of the message's 128 Message-ID header. The "duplicate" test evaluates to "true" when the 129 message was seen before and it evaluates to "false" when it was not. 131 As a side-effect, the "duplicate" test adds the unique ID to an 132 internal duplicate tracking list once the Sieve execution finishes 133 successfully. The first time a particular unique ID is seen, the 134 message is not a duplicate, and the unique ID is added to the 135 tracking list. If a future Sieve execution sees a message whose 136 unique ID appears in the tracking list, that test will evaluate to 137 "true", and that message will be considered a duplicate. 139 Note that this side-effect is performed only when the "duplicate" 140 test is actually evaluated. If the "duplicate" test is nested in a 141 control structure or it is not the first item of an "allof" or 142 "anyof" test list, its evaluation depends on the result of preceding 143 tests, which may produce unexpected results 145 Implementations MUST only update the internal duplicate tracking list 146 when the Sieve script execution finishes successfully. If failing 147 script executions add the unique ID to the duplicate tracking list, 148 all "duplicate" tests in the Sieve script would erroneously yield 149 "true" for the next delivery attempt of the same message, which can 150 -- depending on the action taken for a duplicate -- easily lead to 151 discarding the message without further notice. 153 However, deferring the definitive modification of the tracking list 154 to the end of a successful Sieve script execution is not without 155 problems. It can cause a race condition when a duplicate message is 156 delivered in parallel before the tracking list is updated. This way, 157 a duplicate message could be missed by the "duplicate" test. More 158 complex implementations could use a locking mechanism to prevent this 159 problem. But, irrespective of what implementation is chosen, 160 situations in which the "duplicate" test erroneously yields "true" 161 MUST be prevented. 163 The "duplicate" test MUST only check for duplicates amongst unique ID 164 values encountered in previous executions of the Sieve script; it 165 MUST NOT consider ID values encountered earlier in the current Sieve 166 script execution as potential duplicates. This means that all 167 "duplicate" tests in a Sieve script execution, including those 168 located in scripts included using the "include" [INCLUDE] extension, 169 MUST always yield the same result if the arguments are identical. 171 The Messsage-ID header field is assumed to be globally unique as 172 required in Section 3.6.4 of RFC 5322 [IMAIL]. In practice, this 173 assumption may not aways prove to be true. The "duplicate" test does 174 not deal with this situation, which means that false duplicates may 175 be detected in this case. However, the user can address such 176 situations by specifying an alternative means of message 177 identification using the ":header" or the ":uniqueid" argument, as 178 described in the next section. 180 3.1. Arguments ":header" and ":uniqueid" 182 Duplicate tracking involves determining the unique ID for a given 183 message, and checking whether that unique ID is in the duplicate 184 tracking list. The unique ID for a message is determined as follows: 186 o When neither the ":header" argument nor the ":uniqueid" argument 187 is used, the unique ID is the content of the message's Message-ID 188 header field. 190 o When the ":header" argument is used, the unique ID is the content 191 of the specified header field in the message. The header field 192 name is not part of the resulting unique ID; it consists only of 193 the field value. 195 o When the ":uniqueid" argument is used, the unique ID is the string 196 parameter that is specified with the argument. 198 The ":header" and ":uniqueid" arguments are mutually exclusive and 199 specifying both for a single "duplicate" test command MUST trigger an 200 error. 202 The syntax rules for the header name parameter of the ":header" 203 argument are specified in Section 2.4.2.2 of RFC 5228 [SIEVE]. Note 204 that implementations MUST NOT trigger an error for an invalid header 205 name. Instead, the "duplicate" test MUST yield "false" 206 unconditionally in this case. The parameter of the ":uniqueid" 207 argument can be any string. 209 If the tracked unique ID value is extracted directly from a message 210 header field, i.e., when the ":uniqueid" argument is not used, the 211 following operations MUST be performed before the actual duplicate 212 verification: 214 o Unfold the header line as described in RFC 5322 [IMAIL], Section 215 2.2.3. (see also Section 2.4.2.2 of RFC 5228 [SIEVE]). 217 o If possible, convert the header value to Unicode, encoded as UTF-8 218 (see Section 2.7.2 of RFC 5228 [SIEVE]). If conversion is not 219 possible, the value is left unchanged. 221 o Trim leading and trailing whitespace from the header value (see 222 Section 2.2 of RFC 5228 [SIEVE]). 224 Note that these rules also apply to the Message-ID header field used 225 by the basic "duplicate" test without a ":header" or ":uniqueid" 226 argument. When the ":uniqueid" argument is used, such normalization 227 concerns are the responsibility of the user. 229 If the header field specified using the ":header" argument exists 230 multiple times in the message, extraction of the unique ID MUST use 231 only the first occurrence. This is true whether or not multiple 232 occurrences are allowed by RFC 5322 [IMAIL], Section 3.6. If the 233 specified header field is not present in the message, the "duplicate" 234 test MUST yield "false" unconditionally. In that case the duplicate 235 tracking list is left unmodified by this test, since no unique ID 236 value is available. The same rules apply with respect to the 237 Message-ID header field for the basic "duplicate" test without a 238 ":header" or ":uniqueid" argument, since that header field could also 239 be missing or occur multiple times. 241 The string parameter of the ":uniqueid" argument can be composed from 242 arbitrary text extracted from the message using the "variables" 243 [VARIABLES] extension. To extract text from the message body, the 244 "foreverypart" and "extracttext" [SIEVE-MIME] extensions need to be 245 used as well. This provides the user with detailed control over how 246 the message's unique ID is created. 248 The unique ID MUST be matched case-sensitively with the contents of 249 the duplicate tracking list, irrespective of how the unique ID was 250 determined. To achieve case-insensitive behavior when the 251 ":uniqueid" argument is used, the "set" command added by the 252 "variables" [VARIABLES] extension can be used to normalize the unique 253 ID value to upper or lower case. 255 3.2. Argument ":handle" 257 The "duplicate" test MUST track a unique ID value independent of its 258 source. This means that all values in the duplicate list should be 259 used for duplicate testing, regardless of whether they were obtained 260 from the Message-ID header, from an arbitrary header specified using 261 the ":header" argument or explicitly from the ":uniqueid" argument. 262 The following three examples are equivalent and match the same entry 263 in the duplicate tracking list: 265 require "duplicate"; 266 if duplicate { 267 discard; 268 } 269 require "duplicate"; 270 if duplicate :header "message-id" { 271 discard; 272 } 274 require ["duplicate", "variables"]; 275 if header :matches "message-id" "*" { 276 if duplicate :uniqueid "${0}" { 277 discard; 278 } 279 } 281 The ":handle" argument can be used to override this default behavior. 282 The ":handle" argument separates a "duplicate" test from other 283 duplicate tests with a different or omitted ":handle" argument. 284 Using the ":handle" argument, unrelated "duplicate" tests can be 285 prevented from interfering with each other: a message is only 286 recognized as a duplicate when the tracked unique ID was seen before 287 in an earlier script execution by a "duplicate" test with the same 288 ":handle" argument. 290 NOTE: The necessary mechanism to track duplicate messages is very 291 similar to the mechanism that is needed for tracking duplicate 292 responses for the "vacation" [VACATION] action. One way to implement 293 the necessary mechanism for the "duplicate" test is therefore to 294 store a hash of the tracked unique ID and, if provided, the ":handle" 295 argument. 297 3.3. Arguments ":seconds" and ":last" 299 Implementations SHOULD let entries in the tracking list expire after 300 a short period of time. The user can explicitly control the length 301 of this expiration time by means of the ":seconds" argument, which 302 accepts an integer value specifying the timeout value in seconds. If 303 the ":seconds" argument is omitted, an appropriate default value MUST 304 be used. A default expiration time of around 7 days is usually 305 appropriate. Sites SHOULD impose a maximum limit on the expiration 306 time. If that limit is exceeded by the ":seconds" argument, the 307 maximum value MUST silently be substituted; exceeding the limit MUST 308 NOT produce an error. If the ":seconds" argument is zero, the 309 "duplicate" test MUST yield "false" unconditionally. 311 When the ":last" argument is omitted, the expiration time for entries 312 in the duplicate tracking list MUST be measured relative to the 313 moment at which the entry was first created; i.e., at the end of the 314 successful script execution during which "duplicate" test returned 315 "false" for a message with that particular unique ID value. This 316 means that subsequent duplicate messages have no influence on the 317 time at which the entry in the duplicate tracking list finally 318 expires. 320 In contrast, when the ":last" argument is specified, the expiration 321 time MUST be measured relative to the last script execution during 322 which the "duplicate" test was used to check the entry's unique ID 323 value. This effectively means that the entry in the duplicate 324 tracking list will not expire while duplicate messages with the 325 corresponding unique ID keep being delivered within intervals smaller 326 than the expiration time. 328 It is possible to write Sieve scripts where during a single execution 329 more than one "duplicate" test is evaluated with the same unique ID 330 value and ":handle" argument but different ":seconds" or ":last" 331 arguments. The resulting behavior is left undefined by this 332 specification, so such constructs should be avoided. Implementations 333 MAY choose to use the ":seconds" and ":last" arguments from the 334 "duplicate" test that was evaluated last. 336 3.4. Interaction with Other Sieve Extensions 338 The "duplicate" test does not support either the "index" 339 [DATE-INDEX], or "mime" [SIEVE-MIME] extensions directly, meaning 340 that none of the ":index", ":mime" or associated arguments are added 341 to the "duplicate" test when these extensions are active. The 342 ":uniqueid" argument can be used in combination with the "variables" 343 [VARIABLES] extension to achieve the same result indirectly. 345 Normally, Sieve scripts are executed at final delivery. However, 346 with the "imapsieve" [IMAPSIEVE] extension, Sieve scripts are invoked 347 when the IMAP [IMAP] server performs operations on the message store, 348 e.g. when messages are uploaded, flagged, or moved to another 349 location. The "duplicate" test is devised for use at final delivery 350 and the semantics in the "imapsieve" context are left undefined. 351 Therefore, implementations SHOULD NOT allow the "duplicate" test to 352 be used in the context of "imapsieve". 354 4. Sieve Capability Strings 356 A Sieve implementation that defines the "duplicate" test command will 357 advertise the capability string "duplicate". 359 5. Examples 360 5.1. Example 1 362 In this basic example, message duplicates are detected by tracking 363 the Message-ID header. Duplicate deliveries are stored in a special 364 folder contained in the user's Trash folder. If the folder does not 365 exist, it is created automatically using the "mailbox" [MAILBOX] 366 extension. This way, the user has a chance to recover messages when 367 necessary. Messages that are not recognized as duplicates are stored 368 in the user's inbox as normal. 370 require ["duplicate", "fileinto", "mailbox"]; 372 if duplicate { 373 fileinto :create "Trash/Duplicate"; 374 } 376 5.2. Example 2 378 This example shows a more complex use of the "duplicate" test. The 379 user gets network alerts from a set of remote automated monitoring 380 systems. Several notifications can be received about the same event 381 from different monitoring systems. The Message-ID of these messages 382 is different, because these are all distinct messages from different 383 senders. To avoid being notified more than a single time about the 384 same event the user writes the following script: 386 require ["duplicate", "variables", "imap4flags", 387 "fileinto"]; 389 if header :matches "subject" "ALERT: *" { 390 if duplicate :seconds 60 :uniqueid "${1}" { 391 setflag "\\seen"; 392 } 393 fileinto "Alerts"; 394 } 396 The subjects of the notification message are structured with a 397 predictable pattern which includes a description of the event. In 398 the script above, the "duplicate" test is used to detect duplicate 399 alert events. The message subject is matched against a pattern and 400 the event description is extracted using the "variables" [VARIABLES] 401 extension. If a message with that event in the subject was received 402 before, but more than a minute ago, it is not detected as a duplicate 403 due to the specified ":seconds" argument. In the the event of a 404 duplicate, the message is marked as "seen" using the "imap4flags" 405 [IMAP4FLAGS] extension. All alert messages are put into the "Alerts" 406 mailbox irrespective of whether those messages are duplicates or not. 408 5.3. Example 3 410 This example shows how the "duplicate" test can be used to limit the 411 frequency of notifications sent using the "enotify" [NOTIFY] 412 extension. Consider the following scenario: a mail user receives 413 XMPP notifications [NOTIFY-XMPP] about new mail through Sieve, but 414 sometimes a single contact sends many messages in a short period of 415 time. Now the user wants to prevent being notified of all of those 416 messages. The user wants to be notified about messages from each 417 person at most once per 30 minutes and writes the following script: 419 require ["variables", "envelope", "enotify", "duplicate"]; 421 if envelope :matches "from" "*" { set "sender" "${1}"; } 422 if header :matches "subject" "*" { set "subject" "${1}"; } 424 if not duplicate :seconds 1800 :uniqueid "${sender}" 425 { 426 notify :message "[SIEVE] ${sender}: ${subject}" 427 "xmpp:user@im.example.com"; 428 } 430 The example shown above uses the message envelope sender rather than 431 the Message-ID header as the unique ID for duplicate tracking. 433 The example can be extended to allow more messages from the same 434 sender in close succession as long as the discussed subject is 435 different. This can be achieved as follows: 437 require ["variables", "envelope", "enotify", "duplicate"]; 439 if envelope :matches "from" "*" { set "sender" "${1}"; } 440 if header :matches "subject" "*" { set "subject" "${1}"; } 442 # account for 'Re:' prefix 443 if string :comparator "i;ascii-casemap" 444 :matches "${subject}" "Re:*" 445 { 446 set "subject" "${1}"; 447 } 448 if not duplicate :seconds 1800 449 :uniqueid "${sender} ${subject}" 450 { 451 notify :message "[SIEVE] ${sender}: ${subject}" 452 "xmpp:user@im.example.com"; 453 } 455 This uses a combination of the message envelope sender and the 456 subject of the message as the unique ID for duplicate tracking. 458 5.4. Example 4 460 For this example, the mail user uses the "duplicate" test for two 461 separate applications: for discarding duplicate events from a 462 notification system and to mark certain follow-up messages in a 463 software support mailing as "seen" using the "imap4flags" 464 [IMAP4FLAGS] extension. 466 The two "duplicate" tests in the following example each use a 467 different header to identify messages. However, these "X-Event-ID" 468 and "X-Ticket-ID headers can have similar values in this case (e.g. 469 both based on a time stamp), meaning that one "duplicate" test can 470 erroneously detect duplicates based on ID values tracked by the 471 other. Therefore, the user wants to prevent the second "duplicate" 472 test from matching ID values tracked by the first "duplicate" test 473 and vice versa. This is achieved by specifying different ":handle" 474 arguments for these tests. 476 require ["duplicate", "imap4flags"]; 478 if duplicate :header "X-Event-ID" :handle "notifier" { 479 discard; 480 } 481 if allof ( 482 duplicate :header "X-Ticket-ID" :handle "support", 483 address "to" "support@example.com", 484 header :contains "subject" "fileserver") 485 { 486 setflag "\\seen"; 487 } 489 6. Security Considerations 491 A flood of unique messages could cause the duplicate tracking list to 492 grow indefinitely. Therefore, implementations SHOULD limit the 493 number of entries in the duplicate tracking list. When limiting the 494 number of entries, implementations SHOULD discard the oldest ones 495 first. 497 Scripts using the duplicate test evaluation should be aware that 498 Message-IDs are not necessarily unique, either through the fault of 499 benign generators or attackers injecting a message with the 500 properties used by the duplicate Sieve filter at some point prior to 501 the Sieve filter. Therefore, scripts are well advised to be 502 conservative with respect to actions taken when duplicate messages 503 are identified only by Message-ID. 505 The list of unique IDs used for duplicate tracking can include 506 privacy-sensitive information, such as Message-ID values, content of 507 subject lines, and content extracted from message bodies. 508 Implementations SHOULD protect that information, by obscuring it 509 through hashing (see the note at the end of Section 3.2) and/or by 510 storing it with a level of access control equivalent to that of the 511 messages themselves. 513 These measures will not prevent an entity that has access to the 514 duplicate tracking list from querying whether messages with certain 515 unique ID values were received. As this operation is the essence of 516 the "duplicate" test, this cannot be prevented, and may violate the 517 expectations of the user. For example, a user who deletes a message 518 from the server may expect that no record of it remains on the 519 server, but that will not be true if its Message-ID is persisted on 520 the server in the duplicate tracking list. 522 It's notable, however, that server logs will often store the 523 information present on the duplicate tracking list anyway, and 524 probably would expose plaintext Message-IDs for a much longer period 525 than this mechanism would. Users of email services that 526 intentionally delete such logs with the intent of limiting 527 traceability should be made aware that use of the duplicate tracking 528 mechanism re-exposes this information for the duration of the expiry 529 interval. Therefore, a shorter default expiry interval may be 530 appropriate in those situations. 532 7. IANA Considerations 534 The following template specifies the IANA registration of the Sieve 535 extension specified in this document: 537 To: iana@iana.org 538 Subject: Registration of new Sieve extension 540 Capability name: duplicate 541 Description: Adds test 'duplicate' that can be used to test 542 whether a particular message is a duplicate; 543 i.e., whether a copy of it was seen before by the 544 delivery agent that is executing the Sieve 545 script. 546 RFC number: this RFC 547 Contact address: Sieve mailing list 549 This information should be added to the list of sieve extensions 550 given on http://www.iana.org/assignments/sieve-extensions. 552 8. Acknowledgements 554 Thanks to Brian Carpenter, Cyrus Daboo, Arnt Gulbrandsen, Tony 555 Hansen, Kristin Hubner, Barry Leiba, Alexey Melnikov, Subramanian 556 Moonesamy, Tom Petch, Hector Santos, Robert Sparks, Aaron Stone, and 557 Stefan Winter for reviews and suggestions. With special thanks to 558 Ned Freed for his guidance and support. 560 9. References 562 9.1. Normative References 564 [DATE-INDEX] 565 Freed, N., "Sieve Email Filtering: Date and Index 566 Extensions", RFC 5260, July 2008. 568 [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 569 October 2008. 571 [IMAPSIEVE] 572 Leiba, B., "Support for Internet Message Access Protocol 573 (IMAP) Events in Sieve", RFC 6785, November 2012. 575 [INCLUDE] Daboo, C. and A. Stone, "Sieve Email Filtering: Include 576 Extension", RFC 6609, May 2012. 578 [KEYWORDS] 579 Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, March 1997. 582 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 583 Language", RFC 5228, January 2008. 585 [SIEVE-MIME] 586 Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 587 Tests, Iteration, Extraction, Replacement, and Enclosure", 588 RFC 5703, October 2009. 590 [VARIABLES] 591 Homme, K., "Sieve Email Filtering: Variables Extension", 592 RFC 5229, January 2008. 594 9.2. Informative References 596 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 597 4rev1", RFC 3501, March 2003. 599 [IMAP4FLAGS] 600 Melnikov, A., "Sieve Email Filtering: Imap4flags 601 Extension", RFC 5232, January 2008. 603 [MAILBOX] Melnikov, A., "The Sieve Mail-Filtering Language -- 604 Extensions for Checking Mailbox Status and Accessing 605 Mailbox Metadata", RFC 5490, March 2009. 607 [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 608 "Sieve Email Filtering: Extension for Notifications", 609 RFC 5435, January 2009. 611 [NOTIFY-XMPP] 612 Saint-Andre, P. and A. Melnikov, "Sieve Notification 613 Mechanism: Extensible Messaging and Presence Protocol 614 (XMPP)", RFC 5437, January 2009. 616 [VACATION] 617 Showalter, T. and N. Freed, "Sieve Email Filtering: 618 Vacation Extension", RFC 5230, January 2008. 620 Author's Address 622 Stephan Bosch 623 Enschede 624 NL 626 Email: stephan@rename-it.nl