idnits 2.17.1 draft-ietf-appsawg-sieve-duplicate-07.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 16, 2014) is 3601 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 16, 2014 4 Intended status: Standards Track 5 Expires: December 18, 2014 7 Sieve Email Filtering: Detecting Duplicate Deliveries 8 draft-ietf-appsawg-sieve-duplicate-07 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 18, 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 . . . . . . . . . . . . . . . . . . . . . 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" test does 170 not deal with this situation, which means that false duplicates may 171 be detected in this case. However, the user can address such 172 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 Duplicate tracking involves determining the unique ID for a given 179 message, and checking whether that unique ID is in the duplicate 180 tracking list. The unique ID for a message is determined as follows: 182 o When neither the ":header" argument nor the ":uniqueid" argument 183 is used, the unique ID is the content of the message's Message-ID 184 header field. 186 o When the ":header" argument is used, the unique ID is the content 187 of the specified header field in the message. The header field 188 name is not part of the resulting unique ID; it consists only of 189 the field value. 191 o When the ":uniqueid" argument is used, the unique ID is the string 192 parameter that is specified with the argument. 194 The ":header" and ":uniqueid" arguments are mutually exclusive and 195 specifying both for a single "duplicate" test command MUST trigger an 196 error. 198 The syntax rules for the header name parameter of the ":header" 199 argument are specified in Section 2.4.2.2 of RFC 5228 [SIEVE]. Note 200 that implementations MUST NOT trigger an error for an invalid header 201 name. Instead, the "duplicate" test MUST yield "false" 202 unconditionally in this case. The parameter of the ":uniqueid" 203 argument can be any string. 205 If the tracked unique ID value is extracted directly from a message 206 header field, i.e., when the ":uniqueid" argument is not used, the 207 following operations MUST be performed before the actual duplicate 208 verification: 210 o Unfold the header line as described in RFC 5322 [IMAIL], Section 211 2.2.3. (see also Section 2.4.2.2 of RFC 5228 [SIEVE]). 213 o If possible, convert the header value to Unicode, encoded as UTF-8 214 (see Section 2.7.2 of RFC 5228 [SIEVE]). If conversion is not 215 possible, the value is left unchanged. 217 o Trim leading and trailing whitespace from the header value (see 218 Section 2.2 of RFC 5228 [SIEVE]). 220 Note that these rules also apply to the Message-ID header field used 221 by the basic "duplicate" test without a ":header" or ":uniqueid" 222 argument. When the ":uniqueid" argument is used, such normalization 223 concerns are the responsibility of the user. 225 If the header field specified using the ":header" argument exists 226 multiple times in the message, extraction of the unique ID MUST use 227 only the first occurrence. This is true whether or not multiple 228 occurrences are allowed by RFC 5322 [IMAIL], Section 3.6. If the 229 specified header field is not present in the message, the "duplicate" 230 test MUST yield "false" unconditionally. In that case the duplicate 231 tracking list is left unmodified by this test, since no unique ID 232 value is available. The same rules apply with respect to the 233 Message-ID header field for the basic "duplicate" test without a 234 ":header" or ":uniqueid" argument, since that header field could also 235 be missing or occur multiple times. 237 The string parameter of the ":uniqueid" argument can be composed from 238 arbitrary text extracted from the message using the "variables" 239 [VARIABLES] extension. To extract text from the message body, the 240 "foreverypart" and "extracttext" [SIEVE-MIME] extensions need to be 241 used as well. This provides the user with detailed control over how 242 the message's unique ID is created. 244 The unique ID MUST be matched case-sensitively with the contents of 245 the duplicate tracking list, irrespective of how the unique ID was 246 determined. To achieve case-insensitive behavior when the 247 ":uniqueid" argument is used, the "set" command added by the 248 "variables" [VARIABLES] extension can be used to normalize the unique 249 ID value to upper or lower case. 251 3.2. Argument ":handle" 253 The "duplicate" test MUST track a unique ID value independent of its 254 source. This means that it does not matter whether values are 255 obtained from the message ID header, from an arbitrary header 256 specified using the ":header" argument or explicitly from the 257 ":uniqueid" argument. The following three examples are equivalent 258 and match the same entry in the duplicate tracking list: 260 require "duplicate"; 261 if duplicate { 262 discard; 263 } 264 require "duplicate"; 265 if duplicate :header "message-id" { 266 discard; 267 } 269 require ["duplicate", "variables"]; 270 if header :matches "message-id" "*" { 271 if duplicate :uniqueid "${0}" { 272 discard; 273 } 274 } 276 The ":handle" argument can be used to override this default behavior. 277 The ":handle" argument separates a "duplicate" test from other 278 duplicate tests with a different or omitted ":handle" argument. 279 Using the ":handle" argument, unrelated "duplicate" tests can be 280 prevented from interfering with each other: a message is only 281 recognized as a duplicate when the tracked unique ID was seen before 282 in an earlier script execution by a "duplicate" test with the same 283 ":handle" argument. 285 NOTE: The necessary mechanism to track duplicate messages is very 286 similar to the mechanism that is needed for tracking duplicate 287 responses for the "vacation" [VACATION] action. One way to implement 288 the necessary mechanism for the "duplicate" test is therefore to 289 store a hash of the tracked unique ID and, if provided, the ":handle" 290 argument. 292 3.3. Arguments ":seconds" and ":last" 294 Implementations SHOULD let entries in the tracking list expire after 295 a short period of time. The user can explicitly control the length 296 of this expiration time by means of the ":seconds" argument, which 297 accepts an integer value specifying the timeout value in seconds. If 298 the ":seconds" argument is omitted, an appropriate default value MUST 299 be used. A default expiration time of around 7 days is usually 300 appropriate. Sites SHOULD impose a maximum limit on the expiration 301 time. If that limit is exceeded by the ":seconds" argument, the 302 maximum value MUST silently be substituted; exceeding the limit MUST 303 NOT produce an error. If the ":seconds" argument is zero, the 304 "duplicate" test MUST yield "false" unconditionally. 306 When the ":last" argument is omitted, the expiration time for entries 307 in the duplicate tracking list MUST be measured relative to the 308 moment at which the entry was first created; i.e., at the end of the 309 successful script execution during which "duplicate" test returned 310 "false" for a message with that particular unique ID value. This 311 means that subsequent duplicate messages have no influence on the 312 time at which the entry in the duplicate tracking list finally 313 expires. 315 In contrast, when the ":last" argument is specified, the expiration 316 time MUST be measured relative to the last script execution during 317 which the "duplicate" test was used to check the entry's unique ID 318 value. This effectively means that the entry in the duplicate 319 tracking list will not expire while duplicate messages with the 320 corresponding unique ID keep being delivered within intervals smaller 321 than the expiration time. 323 It is possible to write Sieve scripts where during a single execution 324 more than one "duplicate" test is evaluated with the same unique ID 325 value and ":handle" argument but different ":seconds" or ":last" 326 arguments. The resulting behavior is left undefined by this 327 specification, so such constructs should be avoided. Implementations 328 MAY choose to use the ":seconds" and ":last" arguments from the 329 "duplicate" test that was evaluated last. 331 3.4. Interaction with Other Sieve Extensions 333 The "duplicate" test does not support either the "index" 334 [DATE-INDEX], or "mime" [SIEVE-MIME] extensions directly, meaning 335 that none of the ":index", ":mime" or associated arguments are added 336 to the "duplicate" test when these extensions are active. The 337 ":uniqueid" argument can be used in combination with the "variables" 338 [VARIABLES] extension to achieve the same result indirectly. 340 Normally, Sieve scripts are executed at final delivery. However, 341 with the "imapsieve" [IMAPSIEVE] extension, Sieve scripts are invoked 342 when the IMAP [IMAP] server performs operations on the message store, 343 e.g. when messages are uploaded, flagged, or moved to another 344 location. The "duplicate" test is devised for use at final delivery 345 and the semantics in the "imapsieve" context are left undefined. 346 Therefore, implementations SHOULD NOT allow the "duplicate" test to 347 be used in the context of "imapsieve". 349 4. Sieve Capability Strings 351 A Sieve implementation that defines the "duplicate" test command will 352 advertise the capability string "duplicate". 354 5. Examples 355 5.1. Example 1 357 In this basic example, message duplicates are detected by tracking 358 the Message-ID header. Duplicate deliveries are stored in a special 359 folder contained in the user's Trash folder. If the folder does not 360 exist, it is created automatically using the "mailbox" [MAILBOX] 361 extension. This way, the user has a chance to recover messages when 362 necessary. Messages that are not recognized as duplicates are stored 363 in the user's inbox as normal. 365 require ["duplicate", "fileinto", "mailbox"]; 367 if duplicate { 368 fileinto :create "Trash/Duplicate"; 369 } 371 5.2. Example 2 373 This example shows a more complex use of the "duplicate" test. The 374 user gets network alerts from a set of remote automated monitoring 375 systems. Several notifications can be received about the same event 376 from different monitoring systems. The Message-ID of these messages 377 is different, because these are all distinct messages from different 378 senders. To avoid being notified more than a single time about the 379 same event the user writes the following script: 381 require ["duplicate", "variables", "imap4flags", 382 "fileinto"]; 384 if header :matches "subject" "ALERT: *" { 385 if duplicate :seconds 60 :uniqueid "${1}" { 386 setflag "\\seen"; 387 } 388 fileinto "Alerts"; 389 } 391 The subjects of the notification message are structured with a 392 predictable pattern which includes a description of the event. In 393 the script above, the "duplicate" test is used to detect duplicate 394 alert events. The message subject is matched against a pattern and 395 the event description is extracted using the "variables" [VARIABLES] 396 extension. If a message with that event in the subject was received 397 before, but more than a minute ago, it is not detected as a duplicate 398 due to the specified ":seconds" argument. In the the event of a 399 duplicate, the message is marked as "seen" using the "imap4flags" 400 [IMAP4FLAGS] extension. All alert messages are put into the "Alerts" 401 mailbox irrespective of whether those messages are duplicates or not. 403 5.3. Example 3 405 This example shows how the "duplicate" test can be used to limit the 406 frequency of notifications sent using the "enotify" [NOTIFY] 407 extension. Consider the following scenario: a mail user receives 408 XMPP notifications [NOTIFY-XMPP] about new mail through Sieve, but 409 sometimes a single contact sends many messages in a short period of 410 time. Now the user wants to prevent being notified of all of those 411 messages. The user wants to be notified about messages from each 412 person at most once per 30 minutes and writes the following script: 414 require ["variables", "envelope", "enotify", "duplicate"]; 416 if envelope :matches "from" "*" { set "sender" "${1}"; } 417 if header :matches "subject" "*" { set "subject" "${1}"; } 419 if not duplicate :seconds 1800 :uniqueid "${sender}" 420 { 421 notify :message "[SIEVE] ${sender}: ${subject}" 422 "xmpp:user@im.example.com"; 423 } 425 The example shown above uses the message envelope sender rather than 426 the Message-ID header as the unique ID for duplicate tracking. 428 The example can be extended to allow more messages from the same 429 sender in close succession as long as the discussed subject is 430 different. This can be achieved as follows: 432 require ["variables", "envelope", "enotify", "duplicate"]; 434 if envelope :matches "from" "*" { set "sender" "${1}"; } 435 if header :matches "subject" "*" { set "subject" "${1}"; } 437 # account for 'Re:' prefix 438 if string :comparator "i;ascii-casemap" 439 :matches "${subject}" "Re:*" 440 { 441 set "subject" "${1}"; 442 } 443 if not duplicate :seconds 1800 444 :uniqueid "${sender} ${subject}" 445 { 446 notify :message "[SIEVE] ${sender}: ${subject}" 447 "xmpp:user@im.example.com"; 448 } 450 This uses a combination of the message envelope sender and the 451 subject of the message as the unique ID for duplicate tracking. 453 5.4. Example 4 455 For this example, the mail user uses the "duplicate" test for two 456 separate applications: for discarding duplicate events from a 457 notification system and to mark certain follow-up messages in a 458 software support mailing as "seen" using the "imap4flags" 459 [IMAP4FLAGS] extension. 461 The two "duplicate" tests in the following example each use a 462 different header to identify messages. However, these "X-Event-ID" 463 and "X-Ticket-ID headers can have similar values in this case (e.g. 464 both based on a time stamp), meaning that one "duplicate" test can 465 erroneously detect duplicates based on ID values tracked by the 466 other. Therefore, the user wants to prevent the second "duplicate" 467 test from matching ID values tracked by the first "duplicate" test 468 and vice versa. This is achieved by specifying different ":handle" 469 arguments for these tests. 471 require ["duplicate", "imap4flags"]; 473 if duplicate :header "X-Event-ID" :handle "notifier" { 474 discard; 475 } 476 if allof ( 477 duplicate :header "X-Ticket-ID" :handle "support", 478 address "to" "support@example.com", 479 header :contains "subject" "fileserver") 480 { 481 setflag "\\seen"; 482 } 484 6. Security Considerations 486 A flood of unique messages could cause the list of tracked message ID 487 values to grow indefinitely. Therefore, implementations SHOULD limit 488 the number of entries in the duplicate tracking list. When limiting 489 the number of entries, implementations SHOULD discard the oldest ones 490 first. 492 7. IANA Considerations 494 The following template specifies the IANA registration of the Sieve 495 extension specified in this document: 497 To: iana@iana.org 498 Subject: Registration of new Sieve extension 500 Capability name: duplicate 501 Description: Adds test 'duplicate' that can be used to test 502 whether a particular message is a duplicate; 503 i.e., whether a copy of it was seen before by the 504 delivery agent that is executing the Sieve 505 script. 506 RFC number: this RFC 507 Contact address: Sieve mailing list 509 This information should be added to the list of sieve extensions 510 given on http://www.iana.org/assignments/sieve-extensions. 512 8. Acknowledgements 514 Thanks to Brian Carpenter, Cyrus Daboo, Arnt Gulbrandsen, Tony 515 Hansen, Kristin Hubner, Barry Leiba, Alexey Melnikov, Subramanian 516 Moonesamy, Tom Petch, Hector Santos, Robert Sparks, Aaron Stone, and 517 Stefan Winter for reviews and suggestions. With special thanks to 518 Ned Freed for his guidance and support. 520 9. References 522 9.1. Normative References 524 [DATE-INDEX] 525 Freed, N., "Sieve Email Filtering: Date and Index 526 Extensions", RFC 5260, July 2008. 528 [IMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 529 October 2008. 531 [IMAPSIEVE] 532 Leiba, B., "Support for Internet Message Access Protocol 533 (IMAP) Events in Sieve", RFC 6785, November 2012. 535 [INCLUDE] Daboo, C. and A. Stone, "Sieve Email Filtering: Include 536 Extension", RFC 6609, May 2012. 538 [KEYWORDS] 539 Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 543 Language", RFC 5228, January 2008. 545 [SIEVE-MIME] 546 Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 547 Tests, Iteration, Extraction, Replacement, and Enclosure", 548 RFC 5703, October 2009. 550 [VARIABLES] 551 Homme, K., "Sieve Email Filtering: Variables Extension", 552 RFC 5229, January 2008. 554 9.2. Informative References 556 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 557 4rev1", RFC 3501, March 2003. 559 [IMAP4FLAGS] 560 Melnikov, A., "Sieve Email Filtering: Imap4flags 561 Extension", RFC 5232, January 2008. 563 [MAILBOX] Melnikov, A., "The Sieve Mail-Filtering Language -- 564 Extensions for Checking Mailbox Status and Accessing 565 Mailbox Metadata", RFC 5490, March 2009. 567 [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 568 "Sieve Email Filtering: Extension for Notifications", 569 RFC 5435, January 2009. 571 [NOTIFY-XMPP] 572 Saint-Andre, P. and A. Melnikov, "Sieve Notification 573 Mechanism: Extensible Messaging and Presence Protocol 574 (XMPP)", RFC 5437, January 2009. 576 [VACATION] 577 Showalter, T. and N. Freed, "Sieve Email Filtering: 578 Vacation Extension", RFC 5230, January 2008. 580 Author's Address 582 Stephan Bosch 583 Enschede 584 NL 586 Email: stephan@rename-it.nl