idnits 2.17.1 draft-ietf-sieve-vacation-06.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 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 715. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 2, 2006) is 6658 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-sieve-refuse-reject' is defined on line 644, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-04 == Outdated reference: A later version (-08) exists of draft-ietf-sieve-variables-04 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIEVE Email Filtering Working T. Showalter 3 Group 4 Internet-Draft N. Freed, Ed. 5 Expires: August 6, 2006 Sun Microsystems 6 February 2, 2006 8 Sieve Email Filtering: Vacation Extension 9 draft-ietf-sieve-vacation-06 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 This Internet-Draft will expire on August 6, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes an extension to the Sieve email filtering 43 language for an autoresponder similar to that of the Unix "vacation" 44 command for replying to messages. Various safety features are 45 included to prevent problems such as message loops. 47 Change History (to be removed prior to publication as an RFC) 48 Changes from draft-showalter-sieve-vacation-06.txt: 50 1. Updated to XML source. 52 2. Added :from parameter. 54 3. Added :handle parameter. 56 4. Added more detailed description of :subject parameter 58 5. Clarified some discussion text. 60 6. Fixed various minor typos. 62 7. Refinement of duplicate response suppression semantics 64 8. Added a statement that vacation is incompatible with reject 66 9. Prohibited the use of 8bit material in MIME headers specified 67 when :mime is in effect. 69 10. Use "Auto:" instead of "Re:" in automatically generated subject 70 lines 72 11. Added an explicit list of registered "List-*" header fields to 73 check for 75 12. Switched Syntax: label to Usage: 77 13. Updated draft to refer to RFC 3028bis instead of RFC 3028. 79 14. Removed reference to section 2.4.2.4 of RFC 3028 since the 80 section no longer exists in the revised version. 82 15. Updated reference for Sieve reject, added text about refuse. 84 16. Added reference to RFC 2822 section 3.6.4 - explains how to 85 construct references fields. 87 17. The minimum of 1000 remembered responses and the requirement 88 that scripts fail when two or more vacation actions are executed 89 are now normative. 91 18. Added text making it explicit that it is OK to have additional 92 implementation-specific checks to see if a vacation response 93 should be sent. (This just reiterates the advice in RFC 3834.) 95 19. Added an implementation note about how to construct a hash of 96 vacation action parameters. 98 20. Clarified what to do when :subject isn't used and the original 99 message also doesn't contain a Subject field. 101 21. Corrected typos, added Internationalization Considerations 102 section. 104 Table of Contents 106 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 107 2. Conventions used in this document . . . . . . . . . . . . . . 4 108 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4 109 4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4 110 4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4 111 4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 5 112 4.3. Subject and from parameters . . . . . . . . . . . . . . . 7 113 4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 7 114 4.5. Address Parameter and Limiting Replies to Personal 115 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 116 4.6. Restricting Replies to Automated Processes and Mailing 117 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8 118 4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 9 119 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 120 5. Response Message Generation . . . . . . . . . . . . . . . . . 10 121 5.1. SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 10 122 5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 123 5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10 124 5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 125 5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 126 5.6. Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 11 127 5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 11 128 5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 11 129 6. Relationship to Recommendations for Automatic Responses to 130 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11 131 7. Internationalization Considerations . . . . . . . . . . . . . 11 132 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 133 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 134 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 135 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 136 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 137 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 139 Intellectual Property and Copyright Statements . . . . . . . . . . 17 141 1. Introduction 143 This document defines an extension to the Sieve language defined in 144 [I-D.ietf-sieve-3028bis] for notification that messages to a 145 particular recipient will not be answered immediately. 147 2. Conventions used in this document 149 Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 150 1.1. 152 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED" 153 and "MAY" in this document are to be interpreted as defined in 154 [RFC2119]. 156 3. Capability Identifier 158 Sieve implementations that implement vacation have an identifier of 159 "vacation" for use with the capability mechanism. 161 4. Vacation Action 163 Usage: vacation [":days" number] [":subject" string] 164 [":from" string] [":addresses" string-list] 165 [":mime"] [":handle" string] 167 The "vacation" action implements a vacation autoresponder similar to 168 the vacation command available under many versions of Unix. Its 169 purpose is to provide correspondents with notification that the user 170 is away for an extended period of time and that they should not 171 expect quick responses. 173 "Vacation" is used to respond to a message with another message. 174 Vacation's messages are always addressed to the Return-Path address 175 (that is, the envelope from address) of the message being responded 176 to. 178 4.1. Days Parameter 180 The ":days" argument is used to specify the period in which addresses 181 are kept and are not responded to, and is always specified in days. 182 The minimum value used for this parameter is normally 1. Sites MAY 183 define a different minimum value as long as the minimum is greater 184 than 0. Sites MAY also define a maximum days value, which MUST be 185 greater than 7, and SHOULD be greater than 30. 187 If ":days" is omitted, the default value is either 7 or the minimum 188 value (as defined above), whichever is greater. 190 If the parameter given to ":days" is less than the minimum value, 191 then the minimum value is used instead. 193 If ":days" exceeds the site-defined maximum, the site-defined maximum 194 is used instead. 196 4.2. Previous Response Tracking 198 "Vacation" keeps track of all of the responses it has sent to each 199 address in some period (as specified by the :days optional argument). 200 If vacation has not previously sent the response to this address 201 within the given time period, it sends the "reason" argument to the 202 SMTP MAIL FROM address [RFC2821] of the message that is being 203 responded to. (The SMTP MAIL FROM address should be available in the 204 Return-path: header field if Sieve processing occurs after final 205 delivery.) 207 Tracking is not just per address, but must also take the vacation 208 response itself into account. A script writer might, for example, 209 have a vacation action that will send a general notice only once in 210 any two-week period. However, even if a sender has received this 211 general notice, it may be important to send a specific notice when a 212 message about something timely or something specific has been 213 detected. 215 A particular vacation response can be identified in one of two ways. 216 The first way is via an explicit :handle argument, which attaches a 217 name to the response. All vacation statements that use the same 218 handle will be considered to be the same response for tracking 219 purposes. 221 The second way is via a synthesis of the :subject, :from, :mime, and 222 reason vacation command arguments. All vacation actions that do not 223 contain an explicit handle and which use an identical combination of 224 these arguments are considered to be the same for tracking purposes. 226 For instance, If coyote@desert.example.org sends mail to 227 roadrunner@acme.example.com twice, once with the subject "Cyrus bug" 228 and once with the subject "come over for dinner", and 229 roadrunner@acme.example.com has the script shown below, 230 coyote@desert.example.org would receive two responses, once with the 231 first message, once with the second. 233 require "vacation"; 234 if header :contains "subject" "cyrus" { 235 vacation "I'm out -- send mail to cyrus-bugs"; 236 } else { 237 vacation "I'm out -- call me at +1 304 555 0123"; 238 } 240 In the above example, coyote@desert.example.org gets the second 241 message despite having gotten the first one because separate vacation 242 responses have been triggered. This behavior is REQUIRED. 244 There is one important exception to this rule, however. If the Sieve 245 variables extension [I-D.ietf-sieve-variables] is used, the arguments 246 MUST NOT have undergone variable expansion prior to their use in 247 response tracking. This is so that examples like the following 248 script will only generate a single response to each incoming message 249 with a different subject line. 251 require ["vacation", "variables"]; 252 if header :matches "subject" "*" { 253 vacation :subject "Automatic response to: ${1}" 254 "I'm away -- send mail to foo in my absence"; 255 } 257 As noted above, the optional ":handle" parameter can be used to tell 258 the Sieve interpreter to treat two vacation actions with different 259 arguments as the same command for purposes of response tracking. The 260 argument to ":handle" is a string that identifies the type of 261 response being sent. For instance, if tweety@cage.example.org sends 262 mail to spike@doghouse.example.com twice, one with the subject 263 "lunch?" and once with the subject "dinner?", and 264 spike@doghouse.example.com has the script shown below, 265 tweety@cage.example.org will only receive a single response. (Which 266 response is sent depends on the order in which the messages are 267 processed.) 269 require "vacation"; 270 if header :contains "subject" "lunch" { 271 vacation :handle "ran-away" "I'm out and can't meet for lunch"; 272 } else { 273 vacation :handle "ran-away" "I'm out"; 274 } 276 NOTE: One way to implement the necessary mechanism here is to store a 277 hash of either the current handle and the recipient address or, if no 278 handle is provided, a hash of the vacation action parameters 279 specifying the message content and the recipient address. If a 280 script is changed, implementations MAY reset the records of who has 281 been responded to and when they have been responded to. 283 IMPLEMENTATION NOTE: Care must be taken in constructing a hash of 284 vacation action parameters. In particular, since most parameters are 285 optional, it is important not to let the same string used as the 286 value for different parameters produce the same hash value. One 287 possible way to accomplish this apply the hash to a series of counted 288 or null terminated strings, one for each possible parameter in 289 particular order. 291 Implementations are free to limit the number of remembered responses, 292 however, the limit MUST NOT be less than 1000. When limiting the 293 number of tracked responses, implementations SHOULD discard the 294 oldest ones first. 296 4.3. Subject and from parameters 298 The ":subject" parameter specifies a subject line to attach to any 299 vacation response that is generated. UTF-8 characters can be used in 300 the string argument; implementations MUST convert the string to 301 [RFC2047] encoded words if and only if non-ASCII characters are 302 present. Implementations MUST generate an appropriate default 303 subject line as specified below if no :subject parameter is 304 specified. 306 A ":from" parameter may be used to specify an alternate address to 307 use in the From field of vacation messages. The string must specify 308 a valid [RFC2822] mailbox-list. Implementations SHOULD check the 309 syntax and generate an error when a syntactically invalid ":from" 310 parameter is specified. Implementations MAY also impose restrictions 311 on what addresses can specified in a ":from" parameter; it is 312 suggested that values which fail such a validity check simply be 313 ignored rather than causing the vacation action to fail. 315 4.4. MIME Parameter 317 The ":mime" parameter, if supplied, specifies that the reason string 318 is, in fact, a MIME entity as defined in [RFC2045] section 2.4, 319 including both MIME headers and content. 321 If the optional :mime parameter is not supplied, the reason string is 322 considered to be a UTF-8 string. 324 require "vacation"; 325 vacation :mime text: 326 Content-Type: multipart/alternative; boundary=foo 328 --foo 330 I'm at the beach relaxing. Mmmm, surf... 332 --foo 333 Content-Type: text/html; charset=us-ascii 335 337 How to relax 338 339

I'm at the beach relaxing. 340 Mmmm, surf... 341 343 --foo-- 344 . 346 4.5. Address Parameter and Limiting Replies to Personal Messages 348 "Vacation" MUST NOT respond to a message unless the recipient user's 349 email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or 350 "Resent-Bcc" line of the original message. An email address is 351 considered to belong to the recipient if it is one of: 353 1. An email address known by the implementation to be associated 354 with the recipient, 356 2. the final envelope recipient address if it's available to the 357 implementation, or 359 3. an address specified by the script writer via the ":addresses" 360 argument described in the next paragraph. 362 Users can supply additional mail addresses that are theirs with the 363 ":addresses" argument, which takes a string-list listing additional 364 addresses that a user might have. These addresses are considered to 365 belong to the recipient user in addition to the addresses known to 366 the implementation. 368 4.6. Restricting Replies to Automated Processes and Mailing Lists 370 Implementations MAY refuse to send a vacation response to a message 371 which contains any header or content that makes it appear that a 372 response would not be appropriate. 374 Implementations MUST have a list of addresses which "vacation" MUST 375 NOT send mail to. However, the contents of this list are 376 implementation defined. The purpose of this list is to stop mail 377 from going to addresses used by system daemons that would not care if 378 the user is actually reading her mail. 380 Implementations are encouraged, however, to include well-known 381 addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other 382 addresses typically used only by automated systems. Additionally, 383 addresses ending in "-request" or beginning in "owner-", i.e., 384 reserved for mailing list software, are also suggested. 386 Implementors may take guidance from [RFC2142], but should be careful. 387 Some addresses, like "POSTMASTER", are generally actually managed by 388 people, and people do care if the user is going to be unavailable. 390 Implementations SHOULD NOT respond to any message that contains a 391 "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List- 392 Unsubscribe", "List-Post", "List-Owner" or "List-Archive" [RFC2369] 393 header field. 395 Implementations SHOULD NOT respond to any message that has an "Auto- 396 submitted" header field with a value other than "no". This header 397 field is described in [RFC3834]. 399 4.7. Interaction with Other Sieve Actions 401 Vacation does not affect Sieve's implicit keep action. 403 Vacation can only be executed once per script. A script MUST fail 404 with an appropriate error if it attempts to execute two or more 405 vacation actions. 407 Implementations MUST NOT consider vacation used with discard, keep, 408 fileinto, or redirect an error. The vacation action is incompatible 409 with the Sieve reject and refuse actions [I-D.ietf-sieve-refuse- 410 reject]. 412 4.8. Examples 414 Here is a simple use of vacation. 416 require "vacation"; 417 vacation :days 23 :addresses ["tjs@example.edu", 418 "ts4z@landru.example.edu"] 419 "I'm away until October 19. 421 If it's an emergency, call 911, I guess." ; 423 By mingling vacation with other rules, users can do something more 424 selective. 426 require "vacation"; 427 if header :contains "from" "boss@example.edu" { 428 redirect "pleeb@isp.example.org"; 429 } else { 430 vacation "Sorry, I'm away, I'll read your 431 message when I get around to it."; 432 } 434 5. Response Message Generation 436 This section details the requirements for the generated response 437 message. 439 It is worth noting that the input message and arguments may be in 440 UTF-8, and that implementations MUST deal with UTF-8 input, although 441 implementations MAY transcode to other character sets as regional 442 taste dictates. When :mime is used the reason argument also contains 443 MIME header information. The headers must conform to MIME 444 conventions; in particular, 8bit text is not allowed. 445 Implementations SHOULD reject vacation :mime actions containing 8bit 446 header material. 448 5.1. SMTP MAIL FROM address 450 The SMTP MAIL FROM address of the message envelope SHOULD be set to 451 <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the 452 SMTP transaction if the NOTARY SMTP extension [RFC3461] is available. 454 5.2. Date 456 The Date field SHOULD be set to the date and time when the vacation 457 response was generated. Note that this may not be the same as the 458 time the message was delivered to the user. 460 5.3. Subject 462 Users can specify the Subject of the reply with the ":subject" 463 parameter. If the :subject parameter is not supplied, then the 464 subject is generated as follows: The subject is set to the characters 465 "Auto: " followed by the original subject. An appropriate fixed 466 Subject such as "Automated reply" SHOULD be used in the event that 467 :subject isn't specified and the original message doesn't contain a 468 Subject field. 470 5.4. From 472 Unless explicitly overridden with a :from parameter, the From field 473 SHOULD be set to the address of the owner of the Sieve script. 475 5.5. To 477 The To field SHOULD be set to the address of the recipient of the 478 response. 480 5.6. Auto-submitted 482 An Auto-Submitted field with a value of "auto-replied" SHOULD be 483 included in the message header of any vacation message sent. 485 5.7. Message Body 487 The body of the message is taken from the reason string in the 488 vacation command. 490 5.8. In-Reply-To and References 492 Replies MUST have the In-Reply-To field set to the Message-ID of the 493 original message, and the References field SHOULD be updated with the 494 Message-ID of the original message. 496 If the original message lacks a Message-ID, an In-Reply-To need not 497 be generated, and References need not be changed. 499 Section 3.6.4 of [RFC2822] provides a complete description of how 500 References fields should be generated. 502 6. Relationship to Recommendations for Automatic Responses to 503 Electronic Mail 505 The vacation extension implements a "Personal Responder" in the 506 terminology defined in [RFC3834]. Care has been taken in this 507 specification to comply with the recommendations of [RFC3834] 508 regarding how personal responders should behave. 510 7. Internationalization Considerations 512 Internationalization capabilities provided by the base Sieve language 513 are discussed in [I-D.ietf-sieve-3028bis]. However, the vacation 514 extension is the first Sieve extension to be defined that is capable 515 of creating entirely new messages. This section deals with 516 internationalization issues raised by the use of the vacation 517 extension. 519 Vacation messages are normally written using the UTF-8 charset, 520 allowing text to be written in most of the world's languages. 521 Additionally, the :mime parameter allows specification of arbitrary 522 MIME content. In particular, this makes it possible to use 523 multipart/alternative objects to specify vacation responses in 524 multiple languages simultaneously. 526 The Sieve language itself allows a vacation response to selected 527 based on the content of the original message. For example, the 528 Accept-Language or Content-Language header fields [RFC3282] could be 529 checked and used to select appropriate text: 531 require "vacation"; 532 if header :contains ["accept-language", "content-language"] "en" 533 { 534 vacation "I am away this week."; 535 } else { 536 vacation "Estoy ausente esta semana."; 537 } 539 Note that this rather simplistic test of the field values fails to 540 take the structure of the fields into account and hence could be 541 fooled by some more complex field values. A more elaborate test 542 could be used to deal with this problem. 544 The approach of explicitly coding language selection criteria in 545 scripts is preferred because in many cases language selection issues 546 are conflated with other selection issues. For example, it may be 547 appropriate to use informal text in one language for vacation 548 responses sent to a fellow employee while using more formal text in a 549 different language in a response sent to a total stranger outside the 550 company: 552 require "vacation"; 553 if address :matches "from" "*@ourdivision.example.com" 554 { 555 vacation :subject "Gone fishing" 556 "Having lots of fun! Back in a day or two!"; 557 } else { 558 vacation :subject "Je suis parti cette semaine" 559 "Je lirai votre message quand je retourne."; 560 } 561 IMPLEMENTATION NOTE: A graphical Sieve generation interface could in 562 principle be used to hide the complexity of specifying response 563 selection criteria from end users. Figuring out the right set of 564 options to present in a graphical interface is likely a nontrivial 565 proposition, but more because of the need to employ a variety of 566 criteria to select different sorts of responses to send to different 567 classes of people than because of the issues involved in selecting a 568 response in an appropriate language. 570 8. Security Considerations 572 It is critical that implementations correctly implement the behavior 573 and restrictions described throughout this document. Replies MUST 574 NOT be sent out in response to messages not sent directly to the 575 user, and replies MUST NOT be sent out more often than the :days 576 argument states unless the script changes. 578 If mail is forwarded from a site that uses subaddressing, it may be 579 impossible to list all recipient addresses with ":addresses". 581 Security issues associated with mail auto-responders are fully 582 discussed in the security consideration section of [RFC3834]. This 583 document is believed not to introduce any additional security 584 considerations in this general area. 586 9. IANA Considerations 588 The following template specifies the IANA registration of the 589 vacation Sieve extension specified in this document: 591 To: iana@iana.org 592 Subject: Registration of new Sieve extension 594 Capability name: vacation 595 Capability keyword: vacation 596 Capability arguments: N/A 597 Standards Track/IESG-approved experimental RFC number: this RFC 598 Person and email address to contact for further information: 599 Ned Freed 600 E-Mail: ned.freed@mrochek.com 602 This information should be added to the list of Sieve extensions 603 given on http://www.iana.org/assignments/sieve-extensions. 605 10. References 607 10.1. Normative References 609 [I-D.ietf-sieve-3028bis] 610 Guenther, P. and T. Showalter, "Sieve: An Email Filtering 611 Language", draft-ietf-sieve-3028bis-04 (work in progress), 612 July 2005, . 615 [I-D.ietf-sieve-variables] 616 Homme, K., "Sieve Mail Filtering Language: Variables 617 Extension", draft-ietf-sieve-variables-04 (work in 618 progress), July 2005, . 621 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 622 Extensions (MIME) Part One: Format of Internet Message 623 Bodies", RFC 2045, November 1996. 625 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 626 Part Three: Message Header Extensions for Non-ASCII Text", 627 RFC 2047, November 1996. 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, March 1997. 632 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 633 April 2001. 635 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 636 Extension for Delivery Status Notifications (DSNs)", 637 RFC 3461, January 2003. 639 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 640 Electronic Mail", RFC 3834, August 2004. 642 10.2. Informative References 644 [I-D.ietf-sieve-refuse-reject] 645 Elvey, M. and A. Melnikov, "The SIEVE mail filtering 646 language - reject and refuse extensions", 647 draft-ietf-sieve-refuse-reject (work in progress), 648 May 2005, . 651 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 652 FUNCTIONS", RFC 2142, May 1997. 654 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 655 for Core Mail List Commands and their Transport through 656 Message Header Fields", RFC 2369, July 1998. 658 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 659 April 2001. 661 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 662 and Namespace for the Identification of Mailing Lists", 663 RFC 2919, March 2001. 665 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, 666 May 2002. 668 Appendix A. Acknowledgements 670 This extension is obviously inspired by Eric Allman's vacation 671 program under Unix. The authors owe a great deal to Carnegie Mellon 672 University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil 673 Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov, 674 Jeffrey Hutzelman, Philip Guenther and many others whose names have 675 been lost during the inexcusably long gestation period of this 676 document. 678 Authors' Addresses 680 Tim Showalter 682 Email: tjs@psaux.com 684 Ned Freed (editor) 685 Sun Microsystems 686 3401 Centrelake Drive, Suite 410 687 Ontario, CA 92761-1205 688 USA 690 Phone: +1 909 457 4293 691 Email: ned.freed@mrochek.com 693 Intellectual Property Statement 695 The IETF takes no position regarding the validity or scope of any 696 Intellectual Property Rights or other rights that might be claimed to 697 pertain to the implementation or use of the technology described in 698 this document or the extent to which any license under such rights 699 might or might not be available; nor does it represent that it has 700 made any independent effort to identify any such rights. Information 701 on the procedures with respect to rights in RFC documents can be 702 found in BCP 78 and BCP 79. 704 Copies of IPR disclosures made to the IETF Secretariat and any 705 assurances of licenses to be made available, or the result of an 706 attempt made to obtain a general license or permission for the use of 707 such proprietary rights by implementers or users of this 708 specification can be obtained from the IETF on-line IPR repository at 709 http://www.ietf.org/ipr. 711 The IETF invites any interested party to bring to its attention any 712 copyrights, patents or patent applications, or other proprietary 713 rights that may cover technology that may be required to implement 714 this standard. Please address the information to the IETF at 715 ietf-ipr@ietf.org. 717 Disclaimer of Validity 719 This document and the information contained herein are provided on an 720 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 721 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 722 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 723 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 724 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 725 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 727 Copyright Statement 729 Copyright (C) The Internet Society (2006). This document is subject 730 to the rights, licenses and restrictions contained in BCP 78, and 731 except as set forth therein, the authors retain all their rights. 733 Acknowledgment 735 Funding for the RFC Editor function is currently provided by the 736 Internet Society.