An Extensible Format for Email Feedback Reports
RFC 5965
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
06 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2015-10-14
|
06 | (System) | Notify list changed from marf-chairs@ietf.org, draft-ietf-marf-base@ietf.org, ietf@cybernothing.org to ietf@cybernothing.org |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
|
2010-08-31
|
06 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue by Cindy Morgan |
|
2010-08-31
|
06 | Cindy Morgan | [Note]: changed to 'RFC 5965' by Cindy Morgan |
|
2010-08-30
|
06 | (System) | RFC published |
|
2010-05-27
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2010-05-27
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2010-05-27
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2010-05-27
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2010-05-24
|
06 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
|
2010-05-24
|
06 | (System) | IANA Action state changed to In Progress |
|
2010-05-24
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2010-05-24
|
06 | Amy Vezza | IESG has approved the document |
|
2010-05-24
|
06 | Amy Vezza | Closed "Approve" ballot |
|
2010-05-21
|
06 | (System) | New version available: draft-ietf-marf-base-06.txt |
|
2010-05-21
|
06 | (System) | Removed from agenda for telechat - 2010-05-20 |
|
2010-05-20
|
06 | Cindy Morgan | State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Cindy Morgan |
|
2010-05-20
|
06 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
|
2010-05-20
|
06 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
|
2010-05-20
|
06 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
|
2010-05-20
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
|
2010-05-20
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2010-05-20
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo |
|
2010-05-20
|
06 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2010-05-19
|
06 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss by David Harrington |
|
2010-05-19
|
06 | David Harrington | [Ballot comment] I support Tim's DISCUSS. in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are … [Ballot comment] I support Tim's DISCUSS. in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are we continuing its support here? what happens if a Recived-Date and an Arrival-Date bith exist, and are different? |
|
2010-05-19
|
06 | David Harrington | [Ballot discuss] |
|
2010-05-19
|
06 | Russ Housley | [Ballot comment] The introduction says: > > This memo seeks to define a standard extensible format by creating > the "message/feedback-report" [MIME] … [Ballot comment] The introduction says: > > This memo seeks to define a standard extensible format by creating > the "message/feedback-report" [MIME] type for these reports. > Two points. First, this specification defines the message/feedback- report. Please drop "seeks to". Second, the new MIME type is one part in the overall email feedback report, but talking about this one piece before talking about multipart/report in the introduction lead me to a different expectation. That incorrect expectation is corrected in the subsequent paragraph. A top-down ordering here would have helped me. Section 3.1 says: > > 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". [NOTE TO RFC EDITOR: This > should be changed to "1" at time of publication.] > Note that "0.1" is not valid under the Version ABNF definition. |
|
2010-05-19
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
|
2010-05-19
|
06 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2010-05-19
|
06 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
|
2010-05-19
|
06 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
|
2010-05-19
|
06 | Alexey Melnikov | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Alexey Melnikov |
|
2010-05-19
|
06 | Alexey Melnikov | [Note]: 'J.D. Falk <ietf@cybernothing.org> is the document shepherd.<br>' added by Alexey Melnikov |
|
2010-05-18
|
06 | David Harrington | [Ballot comment] I support Tim's DISCUSS. in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are … [Ballot comment] I support Tim's DISCUSS. in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are we continuing its support here? what happens if a Recived-Date and an Arrival-Date bith exist, and are different? |
|
2010-05-18
|
06 | David Harrington | [Ballot discuss] in section 4, there is no requirement as to envelope sender. How will this impact interoperability? Th ewhol epurpose of this document is … [Ballot discuss] in section 4, there is no requirement as to envelope sender. How will this impact interoperability? Th ewhol epurpose of this document is eliminate so receivers won't need to write custom software for each report sender's variations. Doesn't this lack of standard for envelope sender guarantee receivers will need to write custom software for each envelope sender choice? |
|
2010-05-18
|
06 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to Discuss from No Objection by David Harrington |
|
2010-05-18
|
06 | David Harrington | [Ballot comment] I support Tim's DISCUSS. in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are … [Ballot comment] I support Tim's DISCUSS. in sectio 3.2, last paragraph, the historic field should also be accepted - why, if it is historic are we continuing its support here? what happens if a Recived-Date and an Arrival-Date bith exist, and are different? |
|
2010-05-18
|
06 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded by David Harrington |
|
2010-05-18
|
06 | Peter Saint-Andre | [Ballot comment] Cleared. |
|
2010-05-18
|
06 | Peter Saint-Andre | [Ballot discuss] |
|
2010-05-18
|
06 | Peter Saint-Andre | [Ballot Position Update] Position for Peter Saint-Andre has been changed to Yes from Discuss by Peter Saint-Andre |
|
2010-05-18
|
05 | (System) | New version available: draft-ietf-marf-base-05.txt |
|
2010-05-18
|
06 | Peter Saint-Andre | [Ballot comment] I support Tim's DISCUSS positions. |
|
2010-05-18
|
06 | Peter Saint-Andre | [Ballot discuss] 1. The security considerations probably need to note that the "User-Agent" field is merely asserted and cannot be relied upon (e.g., it is … [Ballot discuss] 1. The security considerations probably need to note that the "User-Agent" field is merely asserted and cannot be relied upon (e.g., it is often forged by HTTP user agents and presumably MUAs too). 2. Do we really want to be encouraging "x-" for header names? Is there any harm in deprecating this usage here and allowing any header names? 3. No information is provided regarding versioning of the protocol itself. You might consider text like this: ### The numbering scheme for MARF versions is "<major>.<minor>". The major and minor numbers MUST be treated as separate integers and each number MAY be incremented higher than a single digit. Thus, "MARF 2.4" would be a lower version than "MARF 2.13", which in turn would be lower than "MARF 12.3". Leading zeros (e.g., "MARF 6.01") MUST NOT be generated and MUST be ignored if found. The major version number will be incremented only if the data formats and protocol actions have changed so dramatically that an older version entity would not be able to interoperate with a newer version entity if it simply ignored the data it did not understand and took the actions defined in the older specification. As an example, the major version number needs to be incremented if new required fields are defined. The minor version number will be incremented only if significant, non-required capabilities have been added to the core protocol (e.g., new optional fields or feedback report types). The minor version number MUST be ignored by an entity with a smaller minor version number, but MAY be used for informational purposes by the entity with the larger minor version number. ### |
|
2010-05-18
|
06 | Peter Saint-Andre | [Ballot Position Update] New position, Discuss, has been recorded by Peter Saint-Andre |
|
2010-05-18
|
06 | Sean Turner | [Ballot comment] I support Tim's DISCUSS positions. |
|
2010-05-18
|
06 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner |
|
2010-05-18
|
06 | Tim Polk | [Ballot comment] It would be helpful (IMHO, anyway) if section 3 included a forward pointer to section 5 (extensibility). The content of section 3 … [Ballot comment] It would be helpful (IMHO, anyway) if section 3 included a forward pointer to section 5 (extensibility). The content of section 3 does not indicate that a marf processor should expect to see unknown fields. |
|
2010-05-18
|
06 | Tim Polk | [Ballot discuss] This discuss has three parts: The first issue is actionable, the second and third are intended as a discuss-discuss. (1) This document is … [Ballot discuss] This discuss has three parts: The first issue is actionable, the second and third are intended as a discuss-discuss. (1) This document is conspicuously silent regarding S/MIME. Considering the importance of vetting the source of an abuse report, it would seem that S/MIME is ideal. The mechanisms that are explicitly highlighted are much weaker than S/MIME. S/MIME would mitigate some of the risks identified currently in section 7 - they derive in part from the weak authentication properties associated with the other mechanisms. Issues regarding the usability of S/MIME are generally irrelevant for MARF, since the set of trusted sources is fairly small and many reports are generated automatically. (2) This is the discuss-discuss. To be clear, I am not asking for any action regarding this issue at this time. After the telechat, I will revise this issue to make it actionable or I will delete this issue. The MARF message report has three components: a human readable report; a machine readable report; and the offending message. I am worried about instances where the human readable and machine readable reports are inconsistent. If an administrator initiates processes based on the human readable report, but the process is directed by the machine readable report, and attacker can exploit this to cause harm. I would like to know if the wg considered such a scenario, and whether any mitigating controls were identified. Personally, I would like to be sure the source of a message is strongly authenticated (e.g., verify the S/MIME signature from a trusted source) before initiating such a process based on the human readable report. (3) This is the discuss-discuss. To be clear, I am not asking for any action regarding this issue at this time. After the telechat, I will revise this sisue to make it actionable or I will delete this issue. Should the ABNF include a production that allows for encountering unknown fileds (i.e., optional fields defined in later specifications)? [See related comment below] |
|
2010-05-18
|
06 | Tim Polk | [Ballot comment] It would be helpful (IMHO, anyway) if section 3 included a forward pointer to section 5 (extensibility). The content of section 3 … [Ballot comment] It would be helpful (IMHO, anyway) if section 3 included a forward pointer to section 5 (extensibility). The content of section 3 does not indicate that a marf processor should expect to see unknown fields. |
|
2010-05-18
|
06 | Tim Polk | [Ballot discuss] This discuss has two parts: The first issue is actionable, the second is intended as a discuss-discuss. (1) This document is conspicuously silent … [Ballot discuss] This discuss has two parts: The first issue is actionable, the second is intended as a discuss-discuss. (1) This document is conspicuously silent regarding S/MIME. Considering the importance of vetting the source of an abuse report, it would seem that S/MIME is ideal. The mechanisms that are explicitly highlighted are much weaker than S/MIME. S/MIME would mitigate some of the risks identified currently in section 7 - they derive in part from the weak authentication properties associated with the other mechanisms. Issues regarding the usability of S/MIME are generally irrelevant for MARF, since the set of trusted sources is fairly small and many reports are generated automatically. (2) This is the discuss-discuss. To be clear, I am not asking for any action regarding this issue at this time. After the telechat, I will revise this issue to make it actionable or I will delete this issue. The MARF message report has three components: a human readable report; a machine readable report; and the offending message. I am worried about instances where the human readable and machine readable reports are inconsistent. If an administrator initiates processes based on the human readable report, but the process is directed by the machine readable report, and attacker can exploit this to cause harm. I would like to know if the wg considered such a scenario, and whether any mitigating controls were identified. Personally, I would like to be sure the source of a message is strongly authenticated (e.g., verify the S/MIME signature from a trusted source) before initiating such a process based on the human readable report. (3) This is the discuss-discuss. To be clear, I am not asking for any action regarding this issue at this time. After the telechat, I will revise this sisue to make it actionable or I will delete this issue. Should the ABNF include a production that allows for encountering unknown fileds (i.e., optional fields defined in later specifications)? [See related comment below] |
|
2010-05-18
|
06 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
|
2010-05-14
|
06 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2010-05-10
|
06 | Amanda Baber | IANA comments: Upon approval of this document, IANA will perform the following actions: ACTION 1: make the following assignment in the "Message Media Types" registry … IANA comments: Upon approval of this document, IANA will perform the following actions: ACTION 1: make the following assignment in the "Message Media Types" registry at http://www.iana.org/assignments/media-types/message/ id Reference --------------- ------------ feedback-report [RFCmarf-base-04] ACTION 2: Create the following registry at http://www.iana.org/assignments/TBD Registry Name: Feedback Report Header Fields Registration Procedures: Specification Required The registry will have the following columns: - Field Name - Description - Multiple Appearances: No - Related "Feedback-Type" - Status - Reference The content will be taken from section 6.2. ACTION 3: Create the following registry at http://www.iana.org/assignments/TBD Registry Name: Feedback Report Type Values Registration Procedure: Specification Required The registry will have the following columns: - Feedback Type Name - Description - Status - Reference The content will be taken from section 6.3. |
|
2010-05-07
|
06 | Alexey Melnikov | [Note]: 'J.D. Falk <ietf@cybernothing.org> is the document shepherd.<br>This document needs a quick update after IETF LC.' added by Alexey Melnikov |
|
2010-05-07
|
06 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
|
2010-05-07
|
06 | Alexey Melnikov | Ballot has been issued by Alexey Melnikov |
|
2010-05-07
|
06 | Alexey Melnikov | Created "Approve" ballot |
|
2010-05-07
|
06 | Alexey Melnikov | Placed on agenda for telechat - 2010-05-20 by Alexey Melnikov |
|
2010-05-03
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Dave Cridland |
|
2010-05-03
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Dave Cridland |
|
2010-04-30
|
06 | Cindy Morgan | Last call sent |
|
2010-04-30
|
06 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
|
2010-04-30
|
06 | Alexey Melnikov | Last Call was requested by Alexey Melnikov |
|
2010-04-30
|
06 | Alexey Melnikov | State Changes to Last Call Requested from AD Evaluation::AD Followup by Alexey Melnikov |
|
2010-04-30
|
06 | (System) | Ballot writeup text was added |
|
2010-04-30
|
06 | (System) | Last call text was added |
|
2010-04-30
|
06 | (System) | Ballot approval text was added |
|
2010-04-30
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2010-04-30
|
04 | (System) | New version available: draft-ietf-marf-base-04.txt |
|
2010-04-24
|
06 | Alexey Melnikov | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I, J.D. Falk, am acting as Document Shepherd. Along with the WG Chairs, I have reviewed this version and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This specification has been reviewed, refined, and implemented by dozens of generators and hundreds of consumers of the format. Though some discussion occurred during the WGLC, the answers were either found in the document or previously recognized as being out of scope. The Document Shepherd has no concerns about the level of review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? Quite a few of the foremost experts in email protocols and abuse reporting practices, including many who were not previously IETF participants, were involved in the discussions leading to this draft. I do not believe that additional review is warranted. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no such concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? When meeting during IETF 77 and on the WG mailing list, consensus around the points in this document has been clear and solid. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No conflict. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. I believe that all of these requirements have been satisfied. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The Normative and Informative reference sections are complete, and there are no downward Normative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA registries are clear and actionable. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No errors were found by http://tools.ietf.org/tools/bap/abnf.cgi . (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Technical Summary This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. Working Group Summary The majority of development of this specification took place outside of the IETF between 2005 and 2007, resulting in a de facto standard with many large-scale implementations. The recent work within the MARF Working Group has resulted in a more precise document, and has revealed some items for discussion in future documents. Document Quality The Working Group is aware of more than a dozen generators of reports which follow this specification, and hundreds of consumers of those reports. These include most of the largest mailbox providers and email service providers, and many smaller operators. Many of the WG members are also implementors, and many additional implementers who are not currently WG participants have reviewed this document and/or earlier revisions. |
|
2010-04-24
|
06 | Alexey Melnikov | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I, J.D. Falk, am acting as Document Shepherd. Along with the WG Chairs, I have reviewed this version and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This specification has been reviewed, refined, and implemented by dozens of generators and hundreds of consumers of the format. Though some discussion occurred during the WGLC, the answers were either found in the document or previously recognized as being out of scope. The Document Shepherd has no concerns about the level of review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? Quite a few of the foremost experts in email protocols and abuse reporting practices, including many who were not previously IETF participants, were involved in the discussions leading to this draft. I do not believe that additional review is warranted. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no such concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? When meeting during IETF 77 and on the WG mailing list, consensus around the points in this document has been clear and solid. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No conflict. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. I believe that all of these requirements have been satisfied. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The Normative and Informative reference sections are complete, and there are no downward Normative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA registries are clear and actionable. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No errors were found by http://tools.ietf.org/tools/bap/abnf.cgi . (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Technical Summary This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. Working Group Summary The majority of development of this specification took place outside of the IETF between 2005 and 2007, resulting in a de facto standard with many large-scale implementations. The recent work within the MARF Working Group has resulted in a more precise document, and has revealed some items for discussion in future documents. Document Quality The Working Group is aware of more than a dozen generators of reports which follow this specification, and hundreds of consumers of those reports. These include most of the largest mailbox providers and email service providers, and many smaller operators. Many of the WG members are also implementors, and many additional implementers who are not currently WG participants have reviewed this document and/or earlier revisions. |
|
2010-04-24
|
06 | Alexey Melnikov | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Alexey Melnikov |
|
2010-04-24
|
06 | Alexey Melnikov | State Change Notice email list have been change to marf-chairs@tools.ietf.org, draft-ietf-marf-base@tools.ietf.org, ietf@cybernothing.org from marf-chairs@tools.ietf.org, draft-ietf-marf-base@tools.ietf.org |
|
2010-04-24
|
06 | Alexey Melnikov | [Note]: 'J.D. Falk <ietf@cybernothing.org> is the document shepherd' added by Alexey Melnikov |
|
2010-04-24
|
06 | Alexey Melnikov | State Changes to AD Evaluation from Publication Requested by Alexey Melnikov |
|
2010-04-21
|
06 | Alexey Melnikov | Earlier history may be found in the Comment Log for <a href="/doc/draft-shafranovich-feedback-report/">draft-shafranovich-feedback-report</a>. |
|
2010-04-21
|
03 | (System) | New version available: draft-ietf-marf-base-03.txt |
|
2010-04-06
|
02 | (System) | New version available: draft-ietf-marf-base-02.txt |
|
2010-02-23
|
01 | (System) | New version available: draft-ietf-marf-base-01.txt |
|
2010-01-27
|
06 | (System) | Earlier history may be found in the Comment Log for <a href="/doc/draft-shafranovich-feedback-report/">draft-shafranovich-feedback-report</a>. |
|
2010-01-27
|
06 | (System) | Draft Added by the IESG Secretary in state 0. by system |
|
2010-01-26
|
00 | (System) | New version available: draft-ietf-marf-base-00.txt |