idnits 2.17.1 draft-ietf-sieve-vacation-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 647. ** 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 (December 31, 2005) is 6688 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 579, 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. -------------------------------------------------------------------------------- 1 SIEVE Email Filtering Working T. Showalter 2 Group 3 Internet-Draft N. Freed, Ed. 4 Expires: July 4, 2006 Sun Microsystems 5 December 31, 2005 7 Sieve Email Filtering: Vacation Extension 8 draft-ietf-sieve-vacation-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 4, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes an extension to the Sieve email filtering 42 language for an autoresponder similar to that of the Unix "vacation" 43 command for replying to messages. Various safety features are 44 included to prevent problems such as message loops. 46 Change History (to be removed prior to publication as an RFC) 47 Changes from draft-showalter-sieve-vacation-06.txt: 49 1. Updated to XML source. 51 2. Added :from parameter. 53 3. Added :handle parameter. 55 4. Added more detailed description of :subject parameter 57 5. Clarified some discussion text. 59 6. Fixed various minor typos. 61 7. Refinement of duplicate response suppression semantics 63 8. Added a statement that vacation is incompatible with reject 65 9. Prohibited the use of 8bit material in MIME headers specified 66 when :mime is in effect. 68 10. Use "Auto:" instead of "Re:" in automatically generated subject 69 lines 71 11. Added an explicit list of registered "List-*" header fields to 72 check for 74 12. Switched Syntax: label to Usage: 76 13. Updated draft to refer to RFC 3028bis instead of RFC 3028. 78 14. Removed reference to section 2.4.2.4 of RFC 3028 since the 79 section no longer exists in the revised version. 81 15. Updated reference for Sieve reject, added text about refuse. 83 16. Added reference to RFC 2822 section 3.6.4 - explains how to 84 construct references fields. 86 17. The minimum of 1000 remembered responses and the requirement 87 that scripts fail when two or more vacation actions are executed 88 are now normative. 90 18. Added text making it explicit that it is OK to have additional 91 implementation-specific checks to see if a vacation response 92 should be sent. (This just reiterates the advice in RFC 3834.) 94 19. Added an implementation note about how to construct a hash of 95 vacation action parameters. 97 20. Clarified what to do when :subject isn't used and the original 98 message also doesn't contain a Subject field. 100 Table of Contents 102 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 103 2. Conventions used in this document . . . . . . . . . . . . . . 4 104 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 4 105 4. Vacation Action . . . . . . . . . . . . . . . . . . . . . . . 4 106 4.1. Days Parameter . . . . . . . . . . . . . . . . . . . . . . 4 107 4.2. Previous Response Tracking . . . . . . . . . . . . . . . . 5 108 4.3. Subject and from parameters . . . . . . . . . . . . . . . 7 109 4.4. MIME Parameter . . . . . . . . . . . . . . . . . . . . . . 7 110 4.5. Address Parameter and Limiting Replies to Personal 111 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 112 4.6. Restricting Replies to Automated Processes and Mailing 113 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 8 114 4.7. Interaction with Other Sieve Actions . . . . . . . . . . . 9 115 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 116 5. Response Message Generation . . . . . . . . . . . . . . . . . 10 117 5.1. SMTP MAIL FROM address . . . . . . . . . . . . . . . . . . 10 118 5.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 119 5.3. Subject . . . . . . . . . . . . . . . . . . . . . . . . . 10 120 5.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 121 5.5. To . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 122 5.6. Auto-submitted . . . . . . . . . . . . . . . . . . . . . . 11 123 5.7. Message Body . . . . . . . . . . . . . . . . . . . . . . . 11 124 5.8. In-Reply-To and References . . . . . . . . . . . . . . . . 11 125 6. Relationship to Recommendations for Automatic Responses to 126 Electronic Mail . . . . . . . . . . . . . . . . . . . . . . . 11 127 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 128 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 129 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 130 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 131 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 132 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 134 Intellectual Property and Copyright Statements . . . . . . . . . . 16 136 1. Introduction 138 This document defines an extension to the Sieve language defined in 139 [I-D.ietf-sieve-3028bis] for notification that messages to a 140 particular recipient will not be answered immediately. 142 2. Conventions used in this document 144 Conventions for notations are as in [I-D.ietf-sieve-3028bis] section 145 1.1. 147 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "REQUIRED" 148 and "MAY" in this document are to be interpreted as defined in 149 [RFC2119]. 151 3. Capability Identifier 153 Sieve implementations that implement vacation have an identifier of 154 "vacation" for use with the capability mechanism. 156 4. Vacation Action 158 Usage: vacation [":days" number] [":subject" string] 159 [":from" string] [":addresses" string-list] 160 [":mime"] [":handle" string] 162 The "vacation" action implements a vacation autoresponder similar to 163 the vacation command available under many versions of Unix. Its 164 purpose is to provide correspondents with notification that the user 165 is away for an extended period of time and that they should not 166 expect quick responses. 168 "Vacation" is used to respond to a message with another message. 169 Vacation's messages are always addressed to the Return-Path address 170 (that is, the envelope from address) of the message being responded 171 to. 173 4.1. Days Parameter 175 The ":days" argument is used to specify the period in which addresses 176 are kept and are not responded to, and is always specified in days. 177 The minimum value used for this parameter is normally 1. Sites MAY 178 define a different minimum value as long as the minimum is greater 179 than 0. Sites MAY also define a maximum days value, which MUST be 180 greater than 7, and SHOULD be greater than 30. 182 If ":days" is omitted, the default value is either 7 or the minimum 183 value (as defined above), whichever is greater. 185 If the parameter given to ":days" is less than the minimum value, 186 then the minimum value is used instead. 188 If ":days" exceeds the site-defined maximum, the site-defined maximum 189 is used instead. 191 4.2. Previous Response Tracking 193 "Vacation" keeps track of all of the responses it has sent to each 194 address in some period (as specified by the :days optional argument). 195 If vacation has not previously sent the response to this address 196 within the given time period, it sends the "reason" argument to the 197 SMTP MAIL FROM address [RFC2821] of the message that is being 198 responded to. (The SMTP MAIL FROM address should be available in the 199 Return-path: header field if Sieve processing occurs after final 200 delivery.) 202 Tracking is not just per address, but must also take the vacation 203 response itself into account. A script writer might, for example, 204 have a vacation action that will send a general notice only once in 205 any two-week period. However, even if a sender has received this 206 general notice, it may be important to send a specific notice when a 207 message about something timely or something specific has been 208 detected. 210 A particular vacation response can be identified in one of two ways. 211 The first way is via an explicit :handle argument, which attaches a 212 name to the response. All vacation statements that use the same 213 handle will be considered to be the same response for tracking 214 purposes. 216 The second way is via a synthesis of the :subject, :from, :mime, and 217 reason vacation command arguments. All vacation actions that do not 218 contain an explicit handle and which use an identical combination of 219 these arguments are considered to be the same for tracking purposes. 221 For instance, If coyote@desert.example.org sends mail to 222 roadrunner@acme.example.com twice, once with the subject "Cyrus bug" 223 and once with the subject "come over for dinner", and 224 roadrunner@acme.example.com has the script shown below, 225 coyote@desert.example.org would receive two responses, once with the 226 first message, once with the second. 228 require "vacation"; 229 if header :contains "subject" "cyrus" { 230 vacation "I'm out -- send mail to cyrus-bugs"; 231 } else { 232 vacation "I'm out -- call me at 304 555 1212"; 233 } 235 In the above example, coyote@desert.example.org gets the second 236 message despite having gotten the first one because separate vacation 237 responses have been triggered. This behavior is REQUIRED. 239 There is one important exception to this rule, however. If the Sieve 240 variables extension [I-D.ietf-sieve-variables] is used, the arguments 241 MUST NOT have undergone variable expansion prior to their use in 242 response tracking. This is so that examples like the following 243 script will only generate a single response to each incoming message 244 with a different subject line. 246 require ["vacation", "variables"]; 247 if header :matches "subject" "*" { 248 vacation :subject "Automatic response to: ${1}" 249 "I'm away -- send mail to foo in my absence"; 250 } 252 As noted above, the optional ":handle" parameter can be used to tell 253 the Sieve interpreter to treat two vacation actions with different 254 arguments as the same command for purposes of response tracking. The 255 argument to ":handle" is a string that identifies the type of 256 response being sent. For instance, if tweety@cage.example.org sends 257 mail to spike@doghouse.example.com twice, one with the subject 258 "lunch?" and once with the subject "dinner?", and 259 spike@doghouse.example.com has the script shown below, 260 tweety@cage.example.org will only receive a single response. (Which 261 response is sent depends on the order in which the messages are 262 processed.) 264 require "vacation"; 265 if header :contains "subject" "lunch" { 266 vacation :handle "ran-away" "I'm out and can't meet for lunch"; 267 } else { 268 vacation :handle "ran-away" "I'm out"; 269 } 271 NOTE: One way to implement the necessary mechanism here is to store a 272 hash of either the current handle and the recipient address or, if no 273 handle is provided, a hash of the vacation action parameters 274 specifying the message content and the recipient address. If a 275 script is changed, implementations MAY reset the records of who has 276 been responded to and when they have been responded to. 278 IMPLEMENTATION NOTE: Care must be taken in constructing a hash of 279 vacation action parameters. In particular, since most parameters are 280 optional, it is important not to let the same string used as the 281 value for different parameters produce the same hash value. One 282 possible way to accomplish this qpply the hash to a series of counted 283 or null terminated strings, one for each possible parameter in 284 particular order. 286 Implementations are free to limit the number of remembered responses, 287 however, the limit MUST NOT be less than 1000. When limiting the 288 number of tracked responses, implementations SHOULD discard the 289 oldest ones first. 291 4.3. Subject and from parameters 293 The ":subject" parameter specifies a subject line to attach to any 294 vacation response that is generated. UTF-8 characters can be used in 295 the string argument; implementations MUST convert the string to 296 [RFC2047] encoded words if and only if non-ASCII characters are 297 present. Implementations MUST generate an appropriate default 298 subject line as specified below if no :subject parameter is 299 specified. 301 A ":from" parameter may be used to specify an alternate address to 302 use in the From field of vacation messages. The string must specify 303 a valid [RFC2822] mailbox-list. Implementations SHOULD check the 304 syntax and generate an error when a syntactically invalid ":from" 305 parameter is specified. Implementations MAY also impose restrictions 306 on what addresses can specified in a ":from" parameter; it is 307 suggested that values which fail such a security check simply be 308 ignored rather than causing the vacation action to fail. 310 4.4. MIME Parameter 312 The ":mime" parameter, if supplied, specifies that the reason string 313 is, in fact, a MIME entity as defined in [RFC2045] section 2.4, 314 including both MIME headers and content. 316 If the optional :mime parameter is not supplied, the reason string is 317 considered to be a UTF-8 string. 319 require "vacation"; 320 vacation :mime text: 321 Content-Type: multipart/alternative; boundary=foo 323 --foo 325 I'm at the beach relaxing. Mmmm, surf... 327 --foo 328 Content-Type: text/html; charset=us-ascii 330 332 How to relax 333 334

I'm at the beach relaxing. 335 Mmmm, surf... 336 338 --foo-- 339 . 341 4.5. Address Parameter and Limiting Replies to Personal Messages 343 "Vacation" MUST NOT respond to a message unless the recipient user's 344 email address is in a "To", "Cc", "Bcc", "Resent-To", "Resent-Cc", or 345 "Resent-Bcc" line of the original message. An email address is 346 considered to belong to the recipient if it is one of: 348 1. An email address known by the implementation to be associated 349 with the recipient, 351 2. the final envelope recipient address if it's available to the 352 implementation, or 354 3. an address specified by the script writer via the ":addresses" 355 argument described in the next paragraph. 357 Users can supply additional mail addresses that are theirs with the 358 ":addresses" argument, which takes a string-list listing additional 359 addresses that a user might have. These addresses are considered to 360 belong to the recipient user in addition to the addresses known to 361 the implementation. 363 4.6. Restricting Replies to Automated Processes and Mailing Lists 365 Implementations MAY refuse to send a vacation response to a message 366 which contains any header or content that makes it appear that a 367 response would not be appropriate. 369 Implementations MUST have a list of addresses that "vacation" MUST 370 NOT send mail to. However, the contents of this list are 371 implementation defined. The purpose of this list is to stop mail 372 from going to addresses used by system daemons that would not care if 373 the user is actually reading her mail. 375 Implementations are encouraged, however, to include well-known 376 addresses like "MAILER-DAEMON", "LISTSERV", "majordomo", and other 377 addresses typically used only by automated systems. Additionally, 378 addresses ending in "-request" or beginning in "owner-", i.e., 379 reserved for mailing list software, are also suggested. 381 Implementors may take guidance from [RFC2142], but should be careful. 382 Some addresses, like "POSTMASTER", are generally actually managed by 383 people, and people do care if the user is going to be unavailable. 385 Implementations SHOULD NOT respond to any message that contains a 386 "List-Id" [RFC2919], "List-Help", "List-Subscribe", "List- 387 Unsubscribe", "List-Post", "List-Owner" or "List-Archive" [RFC2369] 388 header field. 390 Implementations SHOULD NOT respond to any message that has an "Auto- 391 submitted" header field with a value other than "no". This header 392 field is described in [RFC3834]. 394 4.7. Interaction with Other Sieve Actions 396 Vacation does not affect Sieve's implicit keep action. 398 Vacation can only be executed once per script. A script MUST fail 399 with an appropriate error if it attempts to execute two or more 400 vacation actions. 402 Implementations MUST NOT consider vacation used with discard, keep, 403 fileinto, or redirect an error. The vacation action is incompatible 404 with the Sieve reject and refuse actions [I-D.ietf-sieve-refuse- 405 reject]. 407 4.8. Examples 409 Here is a simple use of vacation. 411 require "vacation"; 412 vacation :days 23 :addresses ["tjs@example.edu", 413 "ts4z@landru.example.edu"] 414 "I'm away until October 19. 416 If it's an emergency, call 911, I guess." ; 418 By mingling vacation with other rules, users can do something more 419 selective. 421 require "vacation"; 422 if header :contains "from" "boss@example.edu" { 423 redirect "pleeb@isp.example.org"; 424 } else { 425 vacation "Sorry, I'm away, I'll read your 426 message when I get around to it."; 427 } 429 5. Response Message Generation 431 This section details the requirements for the generated response 432 message. 434 It is worth noting that the input message and arguments may be in 435 UTF-8, and that implementations MUST deal with UTF-8 input, although 436 implementations MAY transcode to other character sets as regional 437 taste dictates. When :mime is used the reason argument also contains 438 MIME header information. The headers must conform to MIME 439 conventions; in particular, 8bit text is not allowed. 440 Implementations SHOULD reject vacation :mime actions containing 8bit 441 header material. 443 5.1. SMTP MAIL FROM address 445 The SMTP MAIL FROM address of the message envelope SHOULD be set to 446 <>. NOTIFY=NEVER SHOULD also be set in the RCPT TO line during the 447 SMTP transaction if the NOTARY SMTP extension [RFC3461] is available. 449 5.2. Date 451 The Date field SHOULD be set to the date and time when the vacation 452 response was generated. Note that this may not be the same as the 453 time the message was delivered to the user. 455 5.3. Subject 457 Users can specify the Subject of the reply with the ":subject" 458 parameter. If the :subject parameter is not supplied, then the 459 subject is generated as follows: The subject is set to the characters 460 "Auto: " followed by the original subject. An appropriate fixed 461 Subject such as "Automated reply" SHOULD be used in the event that 462 :subject isn't specified and the original message doesn't contain a 463 Subject field. 465 5.4. From 467 Unless explicitly overridden with a :from parameter, the From field 468 SHOULD be set to the address of the owner of the Sieve script. 470 5.5. To 472 The To field SHOULD be set to the address of the recipient of the 473 response. 475 5.6. Auto-submitted 477 An Auto-Submitted field with a value of "auto-replied" SHOULD be 478 included in the message header of any vacation message sent. 480 5.7. Message Body 482 The body of the message is taken from the reason string in the 483 vacation command. 485 5.8. In-Reply-To and References 487 Replies MUST have the In-Reply-To field set to the Message-ID of the 488 original message, and the References field SHOULD be updated with the 489 Message-ID of the original message. 491 If the original message lacks a Message-ID, an In-Reply-To need not 492 be generated, and References need not be changed. 494 Section 3.6.4 of [RFC2822] provides a complete description of how 495 References fields should be generated. 497 6. Relationship to Recommendations for Automatic Responses to 498 Electronic Mail 500 The vacation extension implements a "Personal Responder" in the 501 terminology defined in [RFC3834]. Care has been taken in this 502 specification to comply with the recommendations [RFC3834] makes in 503 regards to how personal responders should behave. 505 7. Security Considerations 507 It is critical that implementations correctly implement the behavior 508 and restrictions described throughout this document. Replies MUST 509 NOT be sent out in response to messages not sent directly to the 510 user, and replies MUST NOT be sent out more often than the :days 511 argument states unless the script changes. 513 If mail is forwarded from a site that uses subaddressing, it may be 514 impossible to list all recipient addresses with ":addresses". 516 Security issues associated with mail auto-responders are fully 517 discussed in the security consideration section of [RFC3834]. This 518 document is believed not to introduce any additional security 519 considerations in this general area. 521 8. IANA Considerations 523 The following template specifies the IANA registration of the 524 vacation Sieve extension specified in this document: 526 To: iana@iana.org 527 Subject: Registration of new Sieve extension 529 Capability name: vacation 530 Capability keyword: vacation 531 Capability arguments: N/A 532 Standards Track/IESG-approved experimental RFC number: this RFC 533 Person and email address to contact for further information: 534 Ned Freed 535 E-Mail: ned.freed@mrochek.com 537 This information should be added to the list of Sieve extensions 538 given on http://www.iana.org/assignments/sieve-extensions. 540 9. References 542 9.1. Normative References 544 [I-D.ietf-sieve-3028bis] 545 Guenther, P. and T. Showalter, "Sieve: An Email Filtering 546 Language", draft-ietf-sieve-3028bis-04 (work in progress), 547 July 2005, . 550 [I-D.ietf-sieve-variables] 551 Homme, K., "Sieve Mail Filtering Language: Variables 552 Extension", draft-ietf-sieve-variables-04 (work in 553 progress), July 2005, . 556 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 557 Extensions (MIME) Part One: Format of Internet Message 558 Bodies", RFC 2045, November 1996. 560 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 561 Part Three: Message Header Extensions for Non-ASCII Text", 562 RFC 2047, November 1996. 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, March 1997. 567 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 568 April 2001. 570 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 571 Extension for Delivery Status Notifications (DSNs)", 572 RFC 3461, January 2003. 574 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 575 Electronic Mail", RFC 3834, August 2004. 577 9.2. Informative References 579 [I-D.ietf-sieve-refuse-reject] 580 Elvey, M. and A. Melnikov, "The SIEVE mail filtering 581 language - reject and refuse extensions", 582 draft-ietf-sieve-refuse-reject (work in progress), 583 May 2005, . 586 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 587 FUNCTIONS", RFC 2142, May 1997. 589 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 590 for Core Mail List Commands and their Transport through 591 Message Header Fields", RFC 2369, July 1998. 593 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 594 April 2001. 596 [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 597 and Namespace for the Identification of Mailing Lists", 598 RFC 2919, March 2001. 600 Appendix A. Acknowledgements 602 This extension is obviously inspired by Eric Allman's vacation 603 program under Unix. The authors owe a great deal to Carnegie Mellon 604 University, Cyrus Daboo, Lawrence Greenfield, Michael Haardt, Kjetil 605 Torgrim Homme, Arnt Gulbrandsen, Mark Mallett, Alexey Melnikov, 606 Jeffrey Hutzelman, Philip Guenther and many others whose names have 607 been lost during the inexcusably long gestation period of this 608 document. 610 Authors' Addresses 612 Tim Showalter 614 Email: tjs@psaux.com 616 Ned Freed (editor) 617 Sun Microsystems 618 3401 Centrelake Drive, Suite 410 619 Ontario, CA 92761-1205 620 USA 622 Phone: +1 909 457 4293 623 Email: ned.freed@mrochek.com 625 Intellectual Property Statement 627 The IETF takes no position regarding the validity or scope of any 628 Intellectual Property Rights or other rights that might be claimed to 629 pertain to the implementation or use of the technology described in 630 this document or the extent to which any license under such rights 631 might or might not be available; nor does it represent that it has 632 made any independent effort to identify any such rights. Information 633 on the procedures with respect to rights in RFC documents can be 634 found in BCP 78 and BCP 79. 636 Copies of IPR disclosures made to the IETF Secretariat and any 637 assurances of licenses to be made available, or the result of an 638 attempt made to obtain a general license or permission for the use of 639 such proprietary rights by implementers or users of this 640 specification can be obtained from the IETF on-line IPR repository at 641 http://www.ietf.org/ipr. 643 The IETF invites any interested party to bring to its attention any 644 copyrights, patents or patent applications, or other proprietary 645 rights that may cover technology that may be required to implement 646 this standard. Please address the information to the IETF at 647 ietf-ipr@ietf.org. 649 Disclaimer of Validity 651 This document and the information contained herein are provided on an 652 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 653 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 654 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 655 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 656 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 659 Copyright Statement 661 Copyright (C) The Internet Society (2005). This document is subject 662 to the rights, licenses and restrictions contained in BCP 78, and 663 except as set forth therein, the authors retain all their rights. 665 Acknowledgment 667 Funding for the RFC Editor function is currently provided by the 668 Internet Society.