7c7 < Expires: September 2, 2005 March 2005 --- > Expires: November 7, 2005 May 6, 2005 11c11 < draft-shafranovich-feedback-report-00.txt --- > draft-shafranovich-feedback-report-01-pre1.txt 38c38 < This Internet-Draft will expire on September 2, 2005. --- > This Internet-Draft will expire on November 7, 2005. 56c56 < Shafranovich Expires September 2, 2005 [Page 1] --- > Shafranovich Expires November 7, 2005 [Page 1] 58c58 < Internet-Draft Format for Feedback Reports March 2005 --- > Internet-Draft Format for Feedback Reports May 2005 65c65 < 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 --- > 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 67,81c67,87 < 5. Format of 'message/feedback-report' Content Type . . . . . . 4 < 6. MIME Type Registration of message/feedback-report . . . . . 5 < 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 < 8. Security Considerations . . . . . . . . . . . . . . . . . . 6 < 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 6 < 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 < 10.1 Normative References . . . . . . . . . . . . . . . . . . 7 < 10.2 Informative References . . . . . . . . . . . . . . . . . 7 < Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 < A. Appendix A - An Sample Abuse Report . . . . . . . . . . . . 8 < B. Status of This Document [To Be Removed Upon Publication] . . 9 < B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 9 < B.2 Document Repository . . . . . . . . . . . . . . . . . . . 9 < B.3 Document History . . . . . . . . . . . . . . . . . . . . . 9 < Intellectual Property and Copyright Statements . . . . . . . 10 --- > 5. Format of 'message/feedback-report' Content Type . . . . . . 5 > 5.1 Required Fields . . . . . . . . . . . . . . . . . . . . . 5 > 5.2 Optional Fields Appearing Once . . . . . . . . . . . . . . 5 > 5.3 Optional Fields Appearing Multiple Times . . . . . . . . . 6 > 6. MIME Type Registration of message/feedback-report . . . . . 6 > 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 7 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 > 8.1 Initial Values for the Header Names Registry . . . . . . . 9 > 8.2 Initial values for the "Feedback-Type" registry . . . . . 10 > 9. Security Considerations . . . . . . . . . . . . . . . . . . 10 > 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 > 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 > 11.1 Normative References . . . . . . . . . . . . . . . . . . 11 > 11.2 Informative References . . . . . . . . . . . . . . . . . 11 > Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 > A. Appendix A - An Sample Abuse Report . . . . . . . . . . . . 12 > B. Status of This Document [To Be Removed Upon Publication] . . 13 > B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 13 > B.2 Document Repository and Public Website . . . . . . . . . . 13 > B.3 Document History . . . . . . . . . . . . . . . . . . . . . 13 > Intellectual Property and Copyright Statements . . . . . . . 15 106,112c112 < < < < < < < Shafranovich Expires September 2, 2005 [Page 2] --- > Shafranovich Expires November 7, 2005 [Page 2] 114c114 < Internet-Draft Format for Feedback Reports March 2005 --- > Internet-Draft Format for Feedback Reports May 2005 127c127 < these reports in accordance with RFC 2048 [4]. This format and --- > these reports in accordance with RFC 2048 [11]. This format and 132,133c132,139 < these reports. Determination of where these reports should be sent < is outside the scope of this document. --- > these reports. Determination of where these reports should be sent, > how trust among report senders and receivers is established, and > reports related to more than one message are outside the scope of > this document. > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. 136c142,143 < on public discussion and feedback --- > on public discussion and feedback. Readers are encourages to submit > their comments and suggestions. 143c150,151 < a. To inform ISPs about email abuse originating from their networks --- > o To inform ISPs about email abuse and viruses originating from or > related to their networks 145,146c153,155 < b. To provide feedback to email service providers about abuse < complaints --- > o To provide feedback about abuse complaints to email service > providers and relevant third parties (such as reputation > providers) 148,149c157 < c. To inform the author of the message that the receiver wants to < opt out. --- > o To inform email service provides about opt-out requests 151,152c159,163 < Note that the reports defined in this document are limited to < providing feedback about email only. --- > Please note that while the parent "multipart/report" content type > defined in RFC 3462 [1] is used for all kinds of administrative > messages, this format is intended specifically for communications > among providers regarding email abuse and related issues, and SHOULD > NOT be used for other reports. 154d164 < 3. Requirements 156d165 < The following requirements are necessary for feedback reports : 158d166 < a. They must be both human and machine readable 160,162c168,170 < b. Copy of the original email message or email headers must be < enclosed in order to allow the receiver to properly handle the < report. --- > Shafranovich Expires November 7, 2005 [Page 3] > > Internet-Draft Format for Feedback Reports May 2005 164a173 > 3. Requirements 165a175,176 > The following requirements are necessary for feedback reports (the > actual standard is defined in the next sections) : 166a178 > o They must be both human and machine readable 168,170c180,187 < Shafranovich Expires September 2, 2005 [Page 3] < < Internet-Draft Format for Feedback Reports March 2005 --- > o A copy of the original email message (body and headers) or the > message headers must be enclosed in order to allow the receiver to > properly handle the report. > > o The machine readable section must provide ability for report > generators to share metadata with receivers, > > o The format must be extensible. 175,177c192,194 < An email feedback report is a MIME message with a top level MIME < content type of "multipart/report" (as defined in RFC 3462 [1]). The < following apply: --- > To satisfy the requirements, an email feedback report is defined as a > MIME message with a top level MIME content type of "multipart/report" > (as defined in RFC 3462 [1]). The following apply: 180c197 < "feedback-report". --- > "feedback-report" 183c200 < description of the report --- > description of the report and MUST be included. 185,187c202,206 < c. The second MIME part of the message contains a machine readable < abuse report with the content type of "message/feedback-report" < (defined later on in this document). --- > c. The second MIME part of the message is a machine-readable section > with the content type of "message/feedback-report" (defined later > on in this document) and MUST be included. This section is > intended to convey metadata about the report in question that may > not be readily available from the included email message itself. 191c210 < (as defined in RFC 2046 [1]) OR a copy of the headers from the --- > (as defined in RFC 2046 [2]) OR a copy of the headers from the 193c212,213 < (as defined in RFC 3462 [1]). --- > (as defined in RFC 3462 [1]). This part MUST BE included (unlike > RFC 3462 [1]). 195c215,217 < e. Each abuse report should related to a single originating message. --- > e. Each feedback report MUST be related to only a SINGLE email > message. Summary and aggregate formats are outside the scope of > this specification. 197,202c219,226 < f. The subject line of the abuse report should read as "Email < Feedback Report for IP X.X.X.X" where "X.X.X.X" is the source IP < of the MTA from which the original message was received. If < email authentication is used, the sender may substitute the text < "for domain YYYYY.ZZZZ" where "YYYYY.ZZZZ" is the authenticated < domain. --- > f. The subject line of the feedback report SHOULD be the same as the > included email message and MAY include only the standard > > > > Shafranovich Expires November 7, 2005 [Page 4] > > Internet-Draft Format for Feedback Reports May 2005 204,205c228,231 < g. It is preferable that all original email headers are included < even though they are defined as optional in RFC 3462 [1]. --- > > forwarding prefix used by MUAs such as "FW:" (many smaller > operators using MUAs for abuse handling rely on the subject lines > for processing). 210,211c236,258 < The message/feedback-report content type consists of several header < fields as follows: --- > This content type provides a machine-readable section intended to let > the report generator convey metadata to the report receiver. The > intent of this section is it allow report generators to convey > metadata to report receivers that may not available or may not be > readily available from the originating email message or headers. > > The body of this content type consists of multiple "fields" formatted > according to the ABNF of RFC 822 [12] header "fields". This section > defines the initial set of fields provided by this specification. > Additional fields maybe registered according to the procedure > described later on in this document. Note that these fields > represent information that the receiver is asserting about the report > in question, but are not necessarily verifiable. Report receivers > MUST NOT assume that these assertions are always true. > > 5.1 Required Fields > > The following header fields are REQUIRED and MUST only appear once: > > o "Feedback-Type:" - contains the type of feedback report (as > defined in the corresponding IANA registry). This is intended to > let report generators distinguish among different types of > reports. 213,214c260,262 < a. "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from < which the original message was received. --- > o "User-Agent:" - indicates the name and version of the software > program that generated the report. The format of this field MUST > follow section 14.43 of RFC 2616 [3]. 216,218c264,266 < b. "Received-Date:" - date the original message was received. This < field is formatted in according to the definition in section 3.3 < of RFC 2822 [2] --- > o "Version" - indicates the version of specification that the report > generator is using to generate the report. The version number in > this specification is set to "0.1". 220a269 > 5.2 Optional Fields Appearing Once 221a271,272 > The following header fields are OPTIONAL and MUST NOT appear more > than once: 222a274,276 > o "Original-Mail-From:" - copy of the email address used in the MAIL > FROM portion of the original SMTP transaction. The format of this > field is defined in section 4.1.1.2 of RFC 2821 [4]. 224c278,280 < Shafranovich Expires September 2, 2005 [Page 4] --- > > > Shafranovich Expires November 7, 2005 [Page 5] 226c282,287 < Internet-Draft Format for Feedback Reports March 2005 --- > Internet-Draft Format for Feedback Reports May 2005 > > > o "Original-Rcpt-To:" - copy of the email address used in the RCPT > TO portion of the original SMTP transaction. The format of this > field is defined in section 4.1.1.3 of RFC 2821 [4]. 227a289,291 > o "Received-Date:" - indicates the date the original message was > received by the report generator. This field MUST BE formatted as > per section 3.3 of RFC 2822 [5]. 229,230c293,297 < c. "Original-Message-ID:" - contains the RFC 2822 [2] Message-ID of < the original message --- > o "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from > which the original message was received. IPv4 addresses are to be > formatted in dot-decimal notation as currently used by the > community. IPv6 addresses MUST BE formatted as per section 2.2 of > RFC 2373 [6]. 232,233d298 < d. "Feedback-Type:" - contains the type of feedback as defined in < the corresponding IANA registry. 235,239c300,322 < e. "Authenticated-Domain:" and "Authenticated-Domain-Method:" - < defines the authenticated domain and method used for perform that < authentication. The list of method tokens is contained in the < corresponding IANA registry. Note that the actual type of < authentication used is outside the scope of this document. --- > 5.3 Optional Fields Appearing Multiple Times > > The following set of header fields are OPTIONAL and MAY appear more > than once: > > o "Authentication-Results:" - indicates the result of an > authentication check run by the report generator. The format of > this field is is defined in draft-kucherawy-sender-auth-header > [7]. Report receivers should note that this field only indicates > an assertion made by the report generator. > > o "Reported-Domain:" - indicates a domain name that the report > generator believes to be relevant to the report. Domain format is > defined in section 2.3.1 of RFC 1035 [8]. > > o "Reported-URI:" - indicates a URI that the report generator > believes to be relevant to the report. URI format is defined in > RFC 2396 [13]. > > o "Removal-Recipient:" - indicates the email address to be removed > from the mailing list (only used with "opt-out" feedback report). > The format of this field is defined in section 3.4.1 of RFC 2822 > [5]. 245c328 < RFC 2048 [4], which will be submitted to IANA after IESG approval of --- > RFC 2048 [11], which will be submitted to IANA after IESG approval of 249a333,340 > > > > Shafranovich Expires November 7, 2005 [Page 6] > > Internet-Draft Format for Feedback Reports May 2005 > > 267c358 < See section 3 of RFC 3462 [1] --- > See the "Security Considerations" of this document. 269c360,361 < Interoperability considerations: none --- > Interoperability considerations: implementors MUST ignore any fields > they do not support 278,284d369 < < < Shafranovich Expires September 2, 2005 [Page 5] < < Internet-Draft Format for Feedback Reports March 2005 < < 299c384,410 < 7. IANA Considerations --- > 7. Extensibility > > Like many other formats and protocols, this format may need to be > extended overtime to fit the ever changing landscape of the Internet. > Therefore, extensibility is being provided via two IANA registries: > > > > Shafranovich Expires November 7, 2005 [Page 7] > > Internet-Draft Format for Feedback Reports May 2005 > > > one for feedback types and a second for header fields. The feedback > type registry is to be used in conjunction with the "Feedback-Type" > field above. The header name registry is intended for registration > of new metadata fields to be used in the machine readable portion > (part 2) of this format. Please note that version numbers do not > change with new field registrations unless a new specification of > this format is published. Also note that all new field registrations > can only registered OPTIONAL fields. Any new required fields REQUIRE > a new version of this specification to be published. > > In order to encourage extensibility and interoperability of this > format, implementors SHOULD ignore any fields they do not support. > > 8. IANA Considerations 303,304c414,420 < setup two registries for "Feedback-Type" and "Authentication-Domain- < Method" headers. Below are the initial values for these registries. --- > setup two registries: one for header field names and a second for > "Feedback-Type" values. This section contains the templates used for > registration of new entries in these registries and initial values. > New registrations to these two registries MUST have approval by an > Designated Expert in accordance with the Expert Review guidelines as > described in RFC 2434 [9]. Any new field registered is considered > OPTIONAL unless a new version of this specifiction is published. 306c422,424 < Initial values for the "Feedback-Type" registry: --- > For the header name registry, the following MUST be provided in an > RFC publication (or Internet draft with IETF consensus or IESG > approval) in order to register a new header field name: 308c426 < abuse - spam or some other kind of email abuse --- > 1. Name of the field being registered 310c428 < opt-out - a request to opt out from a mailing list. --- > 2. Short description of the field 312c430 < virus - report of a virus found in the originating message --- > 3. Whether the field can appear more than once 314c432 < Initial values for the "Authentication-Domain-Method" registry: --- > 4. Which "Feedback-Type" types does this field apply to (or "any") 316c434,435 < domainkeys - as defined in delany-domainkeys-base [5] --- > 5. The RFC number (or Internet draft name) in which this header is > registered 318c437,438 < iim - as defined in fenton-identified-mail [6] --- > If the header field being registered requires its own IANA registry, > than the appropriate registry MUST be properly defined. 320c440,442 < sender-id - as defined in lyon-senderid-core [7] --- > For the feedback type registry, the following MUST be provided in an > RFC publication (or Internet draft with IETF consensus or IESG > approval) in order to register a new header field name: 322d443 < spf - as defined in schlitt-spf-classic [8] 325d445 < 8. Security Considerations 327d446 < See section 3 of RFC 3462 [1] 329c448,450 < 9. Acknowledgments --- > Shafranovich Expires November 7, 2005 [Page 8] > > Internet-Draft Format for Feedback Reports May 2005 331,332d451 < The author would like to thank many of the members of the email < community who provided helpful comments and suggestions for this 333a453,469 > 1. Name of the feedback type being registered > > 2. Short description > > 3. The RFC number (or Internet draft name) in which this feedback > type is registered > > > 8.1 Initial Values for the Header Names Registry > > The data below is populated from this document. The RFC number used > for registration of these values is this document. > > Field Name: Authentication-Results > Description: results of authentication check > Multiple Appearances: Yes > Related "Feedback-Type": any 334a471,474 > Field Name: Feedback-Type > Description: type of feedback report > Multiple Appearances: No > Related "Feedback-Type": N/A 336c476,504 < Shafranovich Expires September 2, 2005 [Page 6] --- > Field Name: Original-Mail-From > Description: email address used in the MAIL FROM portion of the > original SMTP transaction > Multiple Appearances: No > Related "Feedback-Type": any > > Field Name: Original-Rcpt-To > Description: copy of the email address used in the RCPT TO portion of > the original SMTP transaction > Multiple Appearances: No > Related "Feedback-Type": any > > Field Name: Received-Date > Description: date the original message was received > Multiple Appearances: No > Related "Feedback-Type": any > > Field Name: Reported-Domain > Description: relevant domain name > Multiple Appearances: Yes > Related "Feedback-Type": any > > Field Name: Reported-URI > Description: relevant URI > Multiple Appearances: Yes > > > > Shafranovich Expires November 7, 2005 [Page 9] 338c506,507 < Internet-Draft Format for Feedback Reports March 2005 --- > Internet-Draft Format for Feedback Reports May 2005 > 339a509 > Related "Feedback-Type": any 340a511,551 > Field Name: Removal-Recipient > Description: email address to be removed from the mailing list > Multiple Appearances: Yes > Related "Feedback-Type": opt-out > > Field Name: Source-IP > Description: IPv4 or IPv6 address from which the original message was > received > Multiple Appearances: No > Related "Feedback-Type": any > > Field Name: User-Agent > Description: name and version of the program used > Multiple Appearances: No > Related "Feedback-Type": any > > Field Name: Version > Description: version of specification used > Multiple Appearances: No > Related "Feedback-Type": any > > 8.2 Initial values for the "Feedback-Type" registry > > The initial names and descriptions are provided below. The RFC > number used for registration of these values is this document. > > o abuse - spam or some other kind of email abuse > > o opt-out - a request to opt out from a mailing list. > > o virus - report of a virus found in the originating message > > > 9. Security Considerations > > See section 3 of RFC 3462 [1] > > 10. Acknowledgments > > The author would like to thank many of the members of the email > community who provided helpful comments and suggestions for this 344c555 < 10. References --- > 11. References 346d556 < 10.1 Normative References 348,350d557 < [1] Vaudreuil, G., "The Multipart/Report Content Type for the < Reporting of Mail System Administrative Messages", RFC 3462, < January 2003. 352d558 < [2] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 354,356c560,562 < [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail < Extensions (MIME) Part Two: Media Types", RFC 2046, < November 1996. --- > Shafranovich Expires November 7, 2005 [Page 10] > > Internet-Draft Format for Feedback Reports May 2005 358d563 < 10.2 Informative References 360,362c565 < [4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet < Mail Extensions (MIME) Part Four: Registration Procedures", < BCP 13, RFC 2048, November 1996. --- > 11.1 Normative References 364,366c567,569 < [5] Delany, M., "Domain-based Email Authentication Using Public-Keys < Advertised in the DNS (DomainKeys)", < draft-delany-domainkeys-base-02 (work in progress), March 2005. --- > [1] Vaudreuil, G., "The Multipart/Report Content Type for the > Reporting of Mail System Administrative Messages", RFC 3462, > January 2003. 368,370c571,573 < [6] Fenton, J. and M. Thomas, "Identified Internet Mail", < draft-fenton-identified-mail-01 (work in progress), < October 2004. --- > [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail > Extensions (MIME) Part Two: Media Types", RFC 2046, > November 1996. 372,373c575,577 < [7] Lyon, J., "Sender ID: Authenticating E-Mail", < draft-lyon-senderid-core-00 (work in progress), November 2004. --- > [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., > Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- > HTTP/1.1", RFC 2616, June 1999. 375,377c579,580 < [8] Wong, M., "Sender Policy Framework: Authorizing Use of Domains < in E-MAIL", draft-schlitt-spf-classic-00 (work in progress), < January 2005. --- > [4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, > April 2001. 378a582 > [5] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 380c584,585 < Author's Address --- > [6] Hinden, R. and S. Deering, "IP Version 6 Addressing > Architecture", RFC 2373, July 1998. 382,383c587,589 < Yakov Shafranovich < SolidMatrix Technologies, Inc. --- > [7] Kucherawy, M., "Message Header for Indicating Sender > Authentication Status", draft-kucherawy-sender-auth-header-02 > (work in progress), May 2005. 385,386c591,596 < Email: ietf@shaftek.org < URI: http://www.shaftek.org --- > [8] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, November 1987. > > [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA > Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. 387a598,599 > [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. 388a601 > 11.2 Informative References 389a603,605 > [11] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet > Mail Extensions (MIME) Part Four: Registration Procedures", > BCP 13, RFC 2048, November 1996. 390a607,608 > [12] Crocker, D., "Standard for the format of ARPA Internet text > messages", STD 11, RFC 822, August 1982. 392c610,616 < Shafranovich Expires September 2, 2005 [Page 7] --- > [13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform > Resource Identifiers (URI): Generic Syntax", RFC 2396, > August 1998. > > > > Shafranovich Expires November 7, 2005 [Page 11] 394c618 < Internet-Draft Format for Feedback Reports March 2005 --- > Internet-Draft Format for Feedback Reports May 2005 396a621,628 > Author's Address > > Yakov Shafranovich > SolidMatrix Technologies, Inc. > > Email: ietf@shaftek.org > URI: http://www.shaftek.org > 402c634 < Subject: Email Abuse Report for IP 10.67.41.167 --- > Subject: FW: Earn money 417,419d648 < Source-IP: 10.67.41.167 < Received-Date: Thu, 8 Mar 2005 14:00:00 EDT < Original-Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net 421c650,662 < --- > User-Agent: SomeGenerator/1.0 > Version: 0.1 > Original-Mail-From: > Original-Rcpt-To: > Received-Date: Thu, 8 Mar 2005 14:00:00 EDT > Source-IP: 10.67.41.167 > Authentication-Results: mail.example.com > smtp.mail=somespammer@example.com; > spf=fail > Reported-Domain: example.net > Reported-Uri: http://example.net/earn_money.html > Reported-Uri: mailto:user@example.com > Removal-Recipient: user@example.com 427a669,676 > > > > Shafranovich Expires November 7, 2005 [Page 12] > > Internet-Draft Format for Feedback Reports May 2005 > > 444,452d692 < < < < < Shafranovich Expires September 2, 2005 [Page 8] < < Internet-Draft Format for Feedback Reports March 2005 < < 457,458c697,702 < Comments about this document should be sent directly to the author at < via . --- > Discussion about this document should be directed to the ABUSE- > FEEDBACK-REPORT mailing list > which is > also reachable via . Of > course, comments directly to the author are always welcome (you can > send them via email to ). 460c704 < B.2 Document Repository --- > B.2 Document Repository and Public Website 463a708,709 > A public website regarding this draft and related efforts is located > at . 467,468c713,714 < Changes from draft-shafranovich-abuse-report-00 to < draft-shafranovich-feedback-report-00: --- > Changes from draft-shafranovich-feedback-report-00 to > draft-shafranovich-feedback-report-01-pre1: 470c716,717 < o Name of the format and report changed to 'feedback-report' --- > o Changed the introduction section< to clarify specific points that > are out of scope for this document 472c719,720 < o Minor spelling corrections --- > o Added pointers to a public mailing list for discussion and public > web page 474c722 < o Added authentication headers and registry --- > o Clarified the intent section and added some extra points to it 476d723 < o Added feedback-type header and registry. 480a728,730 > Shafranovich Expires November 7, 2005 [Page 13] > > Internet-Draft Format for Feedback Reports May 2005 482a733 > o Added a reference to RFC 2119 and changed the document to comply 483a735,736 > o Made it clear that the requirements section) is not the one > defining the standard 484a738,739 > o Clarified the main format section to make all three parts > mandatory 485a741,743 > o Changed section 4f regarding subject lines to mandate that subject > lines should be left intact. Removed the convention for subject > lines that was defined in the previous version 486a745,748 > o Added text to the the machine readable section clarifying its > intent. Also added RFC 2119 references, reorganized fields, > indicated whether specific header fields can appear more than once > and provided references as to how they should be formatted. 487a750,754 > o Removed "Original-Message-ID", "Authenticated-Domain:" and > "Authenticated-Domain-Method" from the draft including related > IANA registries. Added "Version", "User-Agent", Original-Mail- > From", "Original-Rcpt-To", "Reported-Uri", "Reported-Domain" and > "Authentication-Results". 488a756 > o Example has been updated to reflect new headers. 489a758,759 > o Added a new section on extensibility and changed the IANA section > to reflect that. 490a761,770 > Changes from draft-shafranovich-abuse-report-00 to > draft-shafranovich-feedback-report-00: > > o Name of the format and report changed to 'feedback-report' > > o Minor spelling corrections > > o Added authentication headers and registry > > o Added feedback-type header and registry. 504c784 < Shafranovich Expires September 2, 2005 [Page 9] --- > Shafranovich Expires November 7, 2005 [Page 14] 506c786 < Internet-Draft Format for Feedback Reports March 2005 --- > Internet-Draft Format for Feedback Reports May 2005 560c840 < Shafranovich Expires September 2, 2005 [Page 10] --- > Shafranovich Expires November 7, 2005 [Page 15]