idnits 2.17.1 draft-ietf-sieve-vacation-07.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, updated by RFC 4748 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 726. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 732. 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 IETF Trust 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 (March 3, 2007) is 6261 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) == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-12 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) Summary: 2 errors (**), 0 flaws (~~), 4 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: September 4, 2007 Sun Microsystems 6 March 3, 2007 8 Sieve Email Filtering: Vacation Extension 9 draft-ietf-sieve-vacation-07 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 September 4, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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) 49 Changes from draft-showalter-sieve-vacation-06.txt: 51 1. Updated to XML source. 53 2. Added :from parameter. 55 3. Added :handle parameter. 57 4. Added more detailed description of :subject parameter 59 5. Clarified some discussion text. 61 6. Fixed various minor typos. 63 7. Refinement of duplicate response suppression semantics 65 8. Added a statement that vacation is incompatible with reject 67 9. Prohibited the use of 8bit material in MIME headers specified 68 when :mime is in effect. 70 10. Use "Auto:" instead of "Re:" in automatically generated subject 71 lines 73 11. Added an explicit list of registered "List-*" header fields to 74 check for 76 12. Switched Syntax: label to Usage: 78 13. Updated draft to refer to RFC 3028bis instead of RFC 3028. 80 14. Removed reference to section 2.4.2.4 of RFC 3028 since the 81 section no longer exists in the revised version. 83 15. Updated reference for Sieve reject, added text about refuse. 85 16. Added reference to RFC 2822 section 3.6.4 - explains how to 86 construct references fields. 88 17. The minimum of 1000 remembered responses and the requirement 89 that scripts fail when two or more vacation actions are executed 90 are now normative. 92 18. Added text making it explicit that it is OK to have additional 93 implementation-specific checks to see if a vacation response 94 should be sent. (This just reiterates the advice in RFC 3834.) 96 19. Added an implementation note about how to construct a hash of 97 vacation action parameters. 99 20. Clarified what to do when :subject isn't used and the original 100 message also doesn't contain a Subject field. 102 21. Corrected typos, added Internationalization Considerations 103 section. 105 22. Updated IANA Considerations with new registrtion form 107 Table of Contents 109 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 110 2. Conventions used in this document . . . . . . . . . . . . . . 4 111 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4 112 4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4 113 4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4 114 4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 5 115 4.3. Subject and From Parameters . . . . . . . . . . . . . . . 7 116 4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 7 117 4.5. Address Parameter and Limiting Replies to Personal 118 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 119 4.6. Restricting Replies to Automated Processes and Mailing 120 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8 121 4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 9 122 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 123 5. Response Message Generation . . . . . . . . . . . . . . . . . 10 124 5.1. SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 10 125 5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 126 5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10 127 5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 128 5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 129 5.6. Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 11 130 5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 11 131 5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 11 132 6. Relationship to Recommendations for Automatic Responses to 133 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11 134 7. Internationalization Considerations . . . . . . . . . . . . . 11 135 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 136 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 137 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 138 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 139 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 140 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 142 Intellectual Property and Copyright Statements . . . . . . . . . . 16 144 1. Introduction 146 This document defines an extension to the Sieve language defined in 147 [I-D.ietf-sieve-3028bis] for notification that messages to a 148 particular recipient will not be answered immediately. 150 2. Conventions used in this document 152 Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 153 1.1. 155 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED" 156 and "MAY" in this document are to be interpreted as defined in 157 [RFC2119]. 159 3. Capability Identifier 161 Sieve implementations that implement vacation have an identifier of 162 "vacation" for use with the capability mechanism. 164 4. Vacation Action 166 Usage: vacation [":days" number] [":subject" string] 167 [":from" string] [":addresses" string-list] 168 [":mime"] [":handle" string] 170 The "vacation" action implements a vacation autoresponder similar to 171 the vacation command available under many versions of Unix. Its 172 purpose is to provide correspondents with notification that the user 173 is away for an extended period of time and that they should not 174 expect quick responses. 176 "Vacation" is used to respond to a message with another message. 177 Vacation's messages are always addressed to the Return-Path address 178 (that is, the envelope from address) of the message being responded 179 to. 181 4.1. Days Parameter 183 The ":days" argument is used to specify the period in which addresses 184 are kept and are not responded to, and is always specified in days. 185 The minimum value used for this parameter is normally 1. Sites MAY 186 define a different minimum value as long as the minimum is greater 187 than 0. Sites MAY also define a maximum days value, which MUST be 188 greater than 7, and SHOULD be greater than 30. 190 If ":days" is omitted, the default value is either 7 or the minimum 191 value (as defined above), whichever is greater. 193 If the parameter given to ":days" is less than the minimum value, 194 then the minimum value is used instead. 196 If ":days" exceeds the site-defined maximum, the site-defined maximum 197 is used instead. 199 4.2. Previous Response Tracking 201 "Vacation" keeps track of all of the responses it has sent to each 202 address in some period (as specified by the :days optional argument). 203 If vacation has not previously sent the response to this address 204 within the given time period, it sends the "reason" argument to the 205 SMTP MAIL FROM address [RFC2821] of the message that is being 206 responded to. (The SMTP MAIL FROM address should be available in the 207 Return-path: header field if Sieve processing occurs after final 208 delivery.) 210 Tracking is not just per address, but must also take the vacation 211 response itself into account. A script writer might, for example, 212 have a vacation action that will send a general notice only once in 213 any two-week period. However, even if a sender has received this 214 general notice, it may be important to send a specific notice when a 215 message about something timely or something specific has been 216 detected. 218 A particular vacation response can be identified in one of two ways. 219 The first way is via an explicit :handle argument, which attaches a 220 name to the response. All vacation statements that use the same 221 handle will be considered to be the same response for tracking 222 purposes. 224 The second way is via a synthesis of the :subject, :from, :mime, and 225 reason vacation command arguments. All vacation actions that do not 226 contain an explicit handle and which use an identical combination of 227 these arguments are considered to be the same for tracking purposes. 229 For instance, If coyote@desert.example.org sends mail to 230 roadrunner@acme.example.com twice, once with the subject "Cyrus bug" 231 and once with the subject "come over for dinner", and 232 roadrunner@acme.example.com has the script shown below, 233 coyote@desert.example.org would receive two responses, once with the 234 first message, once with the second. 236 require "vacation"; 237 if header :contains "subject" "cyrus" { 238 vacation "I'm out -- send mail to cyrus-bugs"; 239 } else { 240 vacation "I'm out -- call me at +1 304 555 0123"; 241 } 243 In the above example, coyote@desert.example.org gets the second 244 message despite having gotten the first one because separate vacation 245 responses have been triggered. This behavior is REQUIRED. 247 There is one important exception to this rule, however. If the Sieve 248 variables extension [I-D.ietf-sieve-variables] is used, the arguments 249 MUST NOT have undergone variable expansion prior to their use in 250 response tracking. This is so that examples like the following 251 script will only generate a single response to each incoming message 252 with a different subject line. 254 require ["vacation", "variables"]; 255 if header :matches "subject" "*" { 256 vacation :subject "Automatic response to: ${1}" 257 "I'm away -- send mail to foo in my absence"; 258 } 260 As noted above, the optional ":handle" parameter can be used to tell 261 the Sieve interpreter to treat two vacation actions with different 262 arguments as the same command for purposes of response tracking. The 263 argument to ":handle" is a string that identifies the type of 264 response being sent. For instance, if tweety@cage.example.org sends 265 mail to spike@doghouse.example.com twice, one with the subject 266 "lunch?" and once with the subject "dinner?", and 267 spike@doghouse.example.com has the script shown below, 268 tweety@cage.example.org will only receive a single response. (Which 269 response is sent depends on the order in which the messages are 270 processed.) 272 require "vacation"; 273 if header :contains "subject" "lunch" { 274 vacation :handle "ran-away" "I'm out and can't meet for lunch"; 275 } else { 276 vacation :handle "ran-away" "I'm out"; 277 } 279 NOTE: One way to implement the necessary mechanism here is to store a 280 hash of either the current handle and the recipient address or, if no 281 handle is provided, a hash of the vacation action parameters 282 specifying the message content and the recipient address. If a 283 script is changed, implementations MAY reset the records of who has 284 been responded to and when they have been responded to. 286 IMPLEMENTATION NOTE: Care must be taken in constructing a hash of 287 vacation action parameters. In particular, since most parameters are 288 optional, it is important not to let the same string used as the 289 value for different parameters produce the same hash value. One 290 possible way to accomplish this apply the hash to a series of counted 291 or null terminated strings, one for each possible parameter in 292 particular order. 294 Implementations are free to limit the number of remembered responses, 295 however, the limit MUST NOT be less than 1000. When limiting the 296 number of tracked responses, implementations SHOULD discard the 297 oldest ones first. 299 4.3. Subject and From Parameters 301 The ":subject" parameter specifies a subject line to attach to any 302 vacation response that is generated. UTF-8 characters can be used in 303 the string argument; implementations MUST convert the string to 304 [RFC2047] encoded words if and only if non-ASCII characters are 305 present. Implementations MUST generate an appropriate default 306 subject line as specified below if no :subject parameter is 307 specified. 309 A ":from" parameter may be used to specify an alternate address to 310 use in the From field of vacation messages. The string must specify 311 a valid [RFC2822] mailbox-list. Implementations SHOULD check the 312 syntax and generate an error when a syntactically invalid ":from" 313 parameter is specified. Implementations MAY also impose restrictions 314 on what addresses can specified in a ":from" parameter; it is 315 suggested that values which fail such a validity check simply be 316 ignored rather than causing the vacation action to fail. 318 4.4. MIME Parameter 320 The ":mime" parameter, if supplied, specifies that the reason string 321 is, in fact, a MIME entity as defined in [RFC2045] section 2.4, 322 including both MIME headers and content. 324 If the optional :mime parameter is not supplied, the reason string is 325 considered to be a UTF-8 string. 327 require "vacation"; 328 vacation :mime text: 329 Content-Type: multipart/alternative; boundary=foo 331 --foo 333 I'm at the beach relaxing. Mmmm, surf... 335 --foo 336 Content-Type: text/html; charset=us-ascii 338 340 How to relax 341 342

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