idnits 2.17.1 draft-ietf-appsawg-sieve-duplicate-04.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (May 22, 2014) is 3627 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 (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 APPSAWG S. Bosch 3 Internet-Draft May 22, 2014 4 Intended status: Standards Track 5 Expires: November 23, 2014 7 Sieve Email Filtering: Detecting Duplicate Deliveries 8 draft-ietf-appsawg-sieve-duplicate-04 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 November 23, 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 In its basic form, the "duplicate" test keeps track of which messages 125 were seen before by this test during an earlier Sieve execution. 126 Messages are by default identified by their message ID as contained 127 in the Message-ID header. The "duplicate" test evaluates to "true" 128 when the message was seen before and it evaluates to "false" when it 129 was not. 131 As a side-effect, the "duplicate" test adds the message ID to an 132 internal duplicate tracking list once the Sieve execution finishes 133 successfully. This way, the same test will evaluate to "true" during 134 the next Sieve execution in which that message ID is encountered. 135 Note that this side-effect is performed only when the "duplicate" 136 test is actually evaluated. If the "duplicate" test is nested in a 137 control structure or it is not the first item of an "allof" or 138 "anyof" test list, its evaluation depends on the result of preceding 139 tests, which may produce unexpected results. 141 Implementations MUST only update the internal duplicate tracking list 142 when the Sieve script execution finishes successfully. If failing 143 script executions add the message ID to the duplicate tracking list, 144 all "duplicate" tests in the Sieve script would erroneously yield 145 "true" for the next delivery attempt of the same message, which can 146 -- depending on the action taken for a duplicate -- easily lead to 147 discarding the message without further notice. 149 However, deferring the definitive modification of the tracking list 150 to the end of a successful Sieve script execution is not without 151 problems. It can cause a race condition when a duplicate message is 152 delivered in parallel before the tracking list is updated. This way, 153 a duplicate message could be missed by the "duplicate" test. More 154 complex implementations could use a locking mechanism to prevent this 155 problem. But, irrespective of what implementation is chosen, 156 situations in which the "duplicate" test erroneously yields "true" 157 MUST be prevented. 159 The "duplicate" test MUST only check for duplicates amongst message 160 ID values encountered in previous executions of the Sieve script; it 161 MUST NOT consider ID values encountered earlier in the current Sieve 162 script execution as potential duplicates. This means that all 163 "duplicate" tests in a Sieve script execution, including those 164 located in scripts included using the "include" [INCLUDE] extension, 165 MUST always yield the same result if the arguments are identical. 167 The Messsage-ID header field is assumed to be globally unique as 168 required in Section 3.6.4 of RFC 5322 [IMAIL]. In practice, this 169 assumption may not aways prove to be true. The "duplicate" tests 170 does not deal with this situation implicitly, which means that false 171 duplicates may be detected in this case. However, the user can 172 address such situations by specifying an alternative means of message 173 identification using the ":header" or the ":uniqueid" argument, as 174 described in the next section. 176 3.1. Arguments ":header" and ":uniqueid" 178 By default, the content of the message's Message-ID header field is 179 used as the unique ID for duplicate tracking. For more complex 180 applications, the "duplicate" test can also be used to detect 181 duplicate deliveries based on other message text. Then, the tracked 182 unique ID can be an arbitrary string value extracted from the 183 message. By adding the ":header" argument with a message header 184 field name, the content of the specified header field can be used as 185 the tracked unique ID instead of the default Message-ID header. 186 Alternatively, the tracked unique ID can be specified explicitly 187 using the ":uniqueid" argument. The ":header" and ":uniqueid" 188 arguments are mutually exclusive and specifying both for a single 189 "duplicate" test command MUST trigger an error. 191 The syntax rules for the header name parameter of the ":header" 192 argument are specified in Section 2.4.2.2 of RFC 5228 [SIEVE]. Note 193 that implementations MUST NOT trigger an error for an invalid header 194 name. Instead, the "duplicate" test MUST yield "false" 195 unconditionally in this case. The parameter of the ":uniqueid" 196 argument can be any string. 198 If the tracked unique ID value is extracted directly from a message 199 header field, i.e., when the ":uniqueid" argument is not used, the 200 following operations MUST be performed before the actual duplicate 201 verification: 203 o Unfold the header line as described in [IMAIL] Section 2.2.3. (see 204 also Section 2.4.2.2 of RFC 5228 [SIEVE]). 206 o If possible, convert the header value to Unicode, encoded as UTF-8 207 (see Section 2.7.2 of RFC 5228 [SIEVE]). If conversion is not 208 possible, the value is left unchanged. 210 o Trim leading and trailing whitespace from the header value (see 211 Section 2.2 of RFC 5228 [SIEVE]). 213 Note that these rules also apply to the Message-ID header field used 214 by the basic "duplicate" test without a ":header" or ":uniqueid" 215 argument. When the ":uniqueid" argument is used, such normalization 216 concerns are the responsibility of the user. 218 If the header field specified using the ":header" argument exists 219 multiple times in the message, only the first occurrence MUST be used 220 for duplicate tracking. If the specified header field is not present 221 in the message, the "duplicate" test MUST yield "false" 222 unconditionally. In that case the duplicate tracking list is left 223 unmodified by this test, since no unique ID value is available. The 224 same rules apply with respect to the Message-ID header field for the 225 basic "duplicate" test without a ":header" or ":uniqueid" argument, 226 since that header field could also be missing or occur multiple 227 times. 229 The string parameter of the ":uniqueid" argument can be composed from 230 arbitrary text extracted from the message using the "variables" 231 [VARIABLES] extension. To extract text from the message body, the 232 "foreverypart" and "extracttext" [SIEVE-MIME] extensions need to be 233 used as well. This provides the user with detailed control over what 234 identifies a message as a duplicate. 236 The tracked unique ID value MUST be matched case-sensitively, 237 irrespective of whether it originates from a header or is specified 238 explicitly using the ":uniqueid" argument. To achieve case- 239 insensitive behavior, the "set" command added by the "variables" 240 [VARIABLES] extension can be used in combination with the ":uniqueid" 241 argument to normalize the tracked unique ID value to upper or lower 242 case. 244 3.2. Argument ":handle" 246 The "duplicate" test MUST track a unique ID value independent of its 247 source. This means that it does not matter whether values are 248 obtained from the message ID header, from an arbitrary header 249 specified using the ":header" argument or explicitly from the 250 ":uniqueid" argument. For example, the following three examples are 251 equivalent and match the same entry in the duplicate tracking list: 253 require "duplicate"; 254 if duplicate { 255 discard; 256 } 258 require "duplicate"; 259 if duplicate :header "message-id" { 260 discard; 261 } 262 require ["duplicate", "variables"]; 263 if header :matches "message-id" "*" { 264 if duplicate :uniqueid "${0}" { 265 discard; 266 } 267 } 269 The ":handle" argument can be used to override this default behavior. 270 The ":handle" argument separates a "duplicate" test from other 271 duplicate tests with a different or omitted ":handle" argument. 272 Using the ":handle" argument, unrelated "duplicate" tests can be 273 prevented from interfering with each other: a message is only 274 recognized as a duplicate when the tracked unique ID was seen before 275 in an earlier script execution by a "duplicate" test with the same 276 ":handle" argument. 278 NOTE: The necessary mechanism to track duplicate messages is very 279 similar to the mechanism that is needed for tracking duplicate 280 responses for the "vacation" [VACATION] action. One way to implement 281 the necessary mechanism for the "duplicate" test is therefore to 282 store a hash of the tracked unique ID and, if provided, the ":handle" 283 argument. 285 3.3. Arguments ":seconds" and ":last" 287 Implementations SHOULD let entries in the tracking list expire after 288 a short period of time. The user can explicitly control the length 289 of this expiration time by means of the ":seconds" argument, which 290 accepts an integer value specifying the timeout value in seconds. If 291 the ":seconds" argument is omitted, an appropriate default value MUST 292 be used. A default expiration time of around 7 days is usually 293 appropriate. Sites SHOULD impose a maximum limit on the expiration 294 time. If that limit is exceeded by the ":seconds" argument, the 295 maximum value MUST silently be substituted; exceeding the limit MUST 296 NOT produce an error. If the ":seconds" argument is zero, the 297 "duplicate" test MUST yield "false" unconditionally. 299 When the ":last" argument is omitted, the expiration time for entries 300 in the duplicate tracking list MUST be measured relative to the 301 moment at which the entry was first created; i.e., at the end of the 302 successful script execution during which "duplicate" test returned 303 "false" for a message with that particular message ID value. This 304 means that subsequent duplicate messages have no influence on the 305 time at which the entry in the duplicate tracking list finally 306 expires. 308 In contrast, when the ":last" argument is specified, the expiration 309 time MUST be measured relative to the last script execution during 310 which the "duplicate" test was used to check the entry's message ID 311 value. This effectively means that the entry in the duplicate 312 tracking list will not expire while duplicate messages with the 313 corresponding message ID keep being delivered within intervals 314 smaller than the expiration time. 316 Within a single Sieve script execution, several "duplicate" tests 317 could evaluate the same ID value with the same ":handle" argument, 318 but with different ":seconds" or ":last" arguments. However, that is 319 best avoided and the behavior in that situation is left undefined by 320 this specification. In this situation, implementations MAY simply 321 choose to use the ":seconds" and ":last" arguments from the 322 "duplicate" test that was evaluated last. 324 3.4. Interaction with Other Sieve Extensions 326 The "duplicate" test does not support either the "index" 327 [DATE-INDEX], or "mime" [SIEVE-MIME] extensions directly, meaning 328 that none of the ":index", ":mime" or associated arguments are added 329 to the "duplicate" test when these extensions are active. The 330 ":uniqueid" argument can be used in combination with the "variables" 331 [VARIABLES] extension to achieve the same result indirectly. 333 Normally, Sieve scripts are executed at final delivery. However, 334 with the "imapsieve" [IMAPSIEVE] extension, Sieve scripts are invoked 335 when the IMAP [IMAP] server performs operations on the message store, 336 e.g. when messages are uploaded, flagged, or moved to another 337 location. The "duplicate" test is devised for use at final delivery 338 and the semantics in the "imapsieve" context are left undefined. 339 Therefore it is NOT RECOMMENDED to allow the "duplicate" test to be 340 used in the context of "imapsieve". 342 4. Sieve Capability Strings 344 A Sieve implementation that defines the "duplicate" test command will 345 advertise the capability string "duplicate". 347 5. Examples 349 5.1. Example 1 351 In this basic example, message duplicates are detected by tracking 352 the Message-ID header. Duplicate deliveries are stored in a special 353 folder contained in the user's Trash folder. If the folder does not 354 exist, it is created automatically using the "mailbox" [MAILBOX] 355 extension. This way, the user has a chance to recover messages when 356 necessary. Messages that are not recognized as duplicates are stored 357 in the user's inbox as normal. 359 require ["duplicate", "fileinto", "mailbox"]; 361 if duplicate { 362 fileinto :create "Trash/Duplicate"; 363 } 365 5.2. Example 2 367 This example shows a more complex use of the "duplicate" test. The 368 user gets network alerts from a set of remote automated monitoring 369 systems. Several notifications can be received about the same event 370 from different monitoring systems. The Message-ID of these messages 371 is different, because these are all distinct messages from different 372 senders. To avoid being notified more than a single time about the 373 same event the user writes the following script: 375 require ["duplicate", "variables", "imap4flags", 376 "fileinto"]; 378 if header :matches "subject" "ALERT: *" { 379 if duplicate :seconds 60 :uniqueid "${1}" { 380 setflag "\\seen"; 381 } 382 fileinto "Alerts"; 383 } 385 The subjects of the notification message are structured with a 386 predictable pattern which includes a description of the event. In 387 the script above, the "duplicate" test is used to detect duplicate 388 alert events. The message subject is matched against a pattern and 389 the event description is extracted using the "variables" [VARIABLES] 390 extension. If a message with that event in the subject was received 391 before, but more than a minute ago, it is not detected as a duplicate 392 due to the specified ":seconds" argument. In the the event of a 393 duplicate, the message is marked as "seen" using the "imap4flags" 394 [IMAP4FLAGS] extension. All alert messages are put into the "Alerts" 395 mailbox irrespective of whether those messages are duplicates or not. 397 5.3. Example 3 399 This example shows how the "duplicate" test can be used to limit the 400 frequency of notifications sent using the "enotify" [NOTIFY] 401 extension. Consider the following scenario: a mail user receives 402 XMPP notifications [NOTIFY-XMPP] about new mail through Sieve, but 403 sometimes a single contact sends many messages in a short period of 404 time. Now the user wants to prevent being notified of all of those 405 messages. The user wants to be notified about messages from each 406 person at most once per 30 minutes and writes the following script: 408 require ["variables", "envelope", "enotify", "duplicate"]; 410 if envelope :matches "from" "*" { set "sender" "${1}"; } 411 if header :matches "subject" "*" { set "subject" "${1}"; } 413 if not duplicate :seconds 1800 :uniqueid "${sender}" 414 { 415 notify :message "[SIEVE] ${sender}: ${subject}" 416 "xmpp:user@im.example.com"; 417 } 419 The example shown above uses the message envelope sender rather than 420 the Message-ID header as the unique ID for duplicate tracking. 422 The example can be extended to allow more messages from the same 423 sender in close succession as long as the discussed subject is 424 different. This can be achieved as follows: 426 require ["variables", "envelope", "enotify", "duplicate"]; 428 if envelope :matches "from" "*" { set "sender" "${1}"; } 429 if header :matches "subject" "*" { set "subject" "${1}"; } 431 # account for 'Re:' prefix 432 if string :comparator "i;ascii-casemap" 433 :matches "${subject}" "Re:*" 434 { 435 set "subject" "${1}"; 436 } 437 if not duplicate :seconds 1800 438 :uniqueid "${sender} ${subject}" 439 { 440 notify :message "[SIEVE] ${sender}: ${subject}" 441 "xmpp:user@im.example.com"; 442 } 444 This uses a combination of the message envelope sender and the 445 subject of the message as the unique ID for duplicate tracking. 447 5.4. Example 4 449 For this example, the mail user uses the "duplicate" test for two 450 separate applications: for discarding duplicate events from a 451 notification system and to mark certain follow-up messages in a 452 software support mailing as "seen" using the "imap4flags" 453 [IMAP4FLAGS] extension. 455 The two "duplicate" tests in the following example each use a 456 different header to identify messages. However, these "X-Event-ID" 457 and "X-Ticket-ID headers can have similar values in this case (e.g. 458 both based on a time stamp), meaning that one "duplicate" test can 459 erroneously detect duplicates based on ID values tracked by the 460 other. Therefore, the user wants to prevent the second "duplicate" 461 test from matching ID values tracked by the first "duplicate" test 462 and vice versa. This is achieved by specifying different ":handle" 463 arguments for these tests. 465 require ["duplicate", "imap4flags"]; 467 if duplicate :header "X-Event-ID" :handle "notifier" { 468 discard; 469 } 470 if allof ( 471 duplicate :header "X-Ticket-ID" :handle "support", 472 address "to" "support@example.com", 473 header :contains "subject" "fileserver") 474 { 475 setflag "\\seen"; 476 } 478 6. Security Considerations 480 A flood of unique messages could cause the list of tracked message ID 481 values to grow indefinitely. Therefore, implementations SHOULD limit 482 the number of entries in the duplicate tracking list. When limiting 483 the number of entries, implementations SHOULD discard the oldest ones 484 first. 486 7. IANA Considerations 488 The following template specifies the IANA registration of the Sieve 489 extension specified in this document: 491 To: iana@iana.org 492 Subject: Registration of new Sieve extension 494 Capability name: duplicate 495 Description: Adds test 'duplicate' that can be used to test 496 whether a particular message is a duplicate; 497 i.e., whether a copy of it was seen before by the 498 delivery agent that is executing the Sieve 499 script. 500 RFC number: this RFC 501 Contact address: Sieve mailing list 503 This information should be added to the list of sieve extensions 504 given on http://www.iana.org/assignments/sieve-extensions. 506 8. Acknowledgements 508 Thanks to Cyrus Daboo, Arnt Gulbrandsen, Tony Hansen, Kristin Hubner, 509 Alexey Melnikov, Subramanian Moonesamy, Tom Petch, Hector Santos, 510 Robert Sparks, and Aaron Stone for reviews and suggestions. With 511 special thanks to Ned Freed for his guidance and support. 513 9. References 515 9.1. Normative References 517 [DATE-INDEX] 518 Freed, N., "Sieve Email Filtering: Date and Index 519 Extensions", RFC 5260, July 2008. 521 [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 522 October 2008. 524 [IMAPSIEVE] 525 Leiba, B., "Support for Internet Message Access Protocol 526 (IMAP) Events in Sieve", RFC 6785, November 2012. 528 [INCLUDE] Daboo, C. and A. Stone, "Sieve Email Filtering: Include 529 Extension", RFC 6609, May 2012. 531 [KEYWORDS] 532 Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 536 Language", RFC 5228, January 2008. 538 [SIEVE-MIME] 539 Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 540 Tests, Iteration, Extraction, Replacement, and Enclosure", 541 RFC 5703, October 2009. 543 [VARIABLES] 544 Homme, K., "Sieve Email Filtering: Variables Extension", 545 RFC 5229, January 2008. 547 9.2. Informative References 549 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 550 4rev1", RFC 3501, March 2003. 552 [IMAP4FLAGS] 553 Melnikov, A., "Sieve Email Filtering: Imap4flags 554 Extension", RFC 5232, January 2008. 556 [MAILBOX] Melnikov, A., "The Sieve Mail-Filtering Language -- 557 Extensions for Checking Mailbox Status and Accessing 558 Mailbox Metadata", RFC 5490, March 2009. 560 [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 561 "Sieve Email Filtering: Extension for Notifications", 562 RFC 5435, January 2009. 564 [NOTIFY-XMPP] 565 Saint-Andre, P. and A. Melnikov, "Sieve Notification 566 Mechanism: Extensible Messaging and Presence Protocol 567 (XMPP)", RFC 5437, January 2009. 569 [VACATION] 570 Showalter, T. and N. Freed, "Sieve Email Filtering: 571 Vacation Extension", RFC 5230, January 2008. 573 Author's Address 575 Stephan Bosch 576 Enschede 577 NL 579 Email: stephan@rename-it.nl