Network Working Group J. Falk Internet-Draft Return Path Intended status: Experimental May 12, 2010 Expires: November 13, 2010 Advertising and Discovering Willingness to Provide or Receive ARF Reports draft-jdfalk-marf-reporting-discovery-01.txt Abstract This document defines a method for network operators to advertise their willingness to send feedback about received email to other parties, and for those other parties to advertise their willingness to receive such feedback. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 13, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Falk Expires November 13, 2010 [Page 1] Internet-Draft ARF Reporting Discovery May 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Language . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Email Specific . . . . . . . . . . . . . . . . . . . . . . 4 4.3. ARF Specific . . . . . . . . . . . . . . . . . . . . . . . 4 5. Characteristics of a Feedback Reporting Advertisement . . . . 5 5.1. Feedback Consumers . . . . . . . . . . . . . . . . . . . . 5 5.1.1. Feedback Consumer Policies . . . . . . . . . . . . . . 6 5.2. Feedback Generators . . . . . . . . . . . . . . . . . . . 6 5.2.1. Feedback Generator Policies . . . . . . . . . . . . . 6 5.3. Reporting Facility for End Users within an ADMD . . . . . 6 5.3.1. End User Reporting Formats . . . . . . . . . . . . . . 7 5.4. Note about URIs . . . . . . . . . . . . . . . . . . . . . 7 5.5. Formal Definition . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7.1. Inherited from MARF-BASE . . . . . . . . . . . . . . . . . 8 7.2. TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Sample Advertisements . . . . . . . . . . . . . . . . 10 Appendix B. Public Discussion, History and Support . . . . . . . 10 Appendix C. Document History & Open Issues . . . . . . . . . . . 10 C.1. draft-jdfalk-marf-reporting-discovery-00 . . . . . . . . . 10 C.2. draft-jdfalk-marf-reporting-discovery-01 . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Falk Expires November 13, 2010 [Page 2] Internet-Draft ARF Reporting Discovery May 2010 1. Introduction As the spam problem continues to expand and potential solutions evolve, network operators are increasingly exchanging abuse reports among themselves and other parties. While [MARF-BASE] defines the Abuse Reporting Format (ARF) for these reports, it assumes that the operators will use some undefined method to discover each other and enter into any necessary agreements. The advertisement method defined in this memo is intended to ease the process for potential ARF recipients to discover whether a particular Administrative Domain (ADMD) has the facility and willingness to generate ARF reports, and for ARF generators to discover whether a particular ADMD is able and willing to receive ARF reports. Also included is a facility for end-user MUAs to discover whether there is an abuse reporting address within their own ADMD. This document only defines the process for advertisement and discovery of feedback recipients. Determination of when it is appropriate to send feedback or how trust may be established between report generators and report recipients is outside the scope of this document. It is assumed that best practices will evolve over time, and will be codified in future documents. 2. Purpose The reports defined in [MARF-BASE] are intended to inform mail operators about: o email abuse originating from their networks; o potential issues with the perceived quality of outbound mail, such as email service providers sending mail that attracts the attention of automated abuse detection systems. To support these purposes, this document addresses three primary use cases: o Any ADMD may advertise its willingness to receive reports from the internet at large, given particular criteria included in or referenced by the advertisement; o Any ADMD may advertise their willingness to provide reports to the Internet at large, given particular criteria included in or referenced by the advertisement; o Any ADMD may advertise the method for their own end users to report issues directly (likely through their MUA), so that these reports may be handled through that ADMD's own policies -- which may include distribution to another ADMD in the form of an ARF message. This specification also inherits from [MARF-BASE] that it is intended specifically for communications among providers regarding email abuse Falk Expires November 13, 2010 [Page 3] Internet-Draft ARF Reporting Discovery May 2010 and related issues, and SHOULD NOT be used for other reports. For example, the [DKIM-REPORTING] extension includes its own ARF recipient discovery method which should not be confused with the method defined in this memo. 3. Requirements The advertisement and discovery process must be easily accessible to the software involved in providing email service, preferably using concepts and technologies an email operator can be assumed to be familiar with. Thus, following the examples of [DKIM] and [DKIM-REPORTING], the advertisement is in the form of a [DNS] TXT record. While this may provide challenges for offline processing, this is outweighed by the advantages of security and maintainability. In order to reflect current usage, advertisements must also provide the ability to reference complex "terms of service" or other documents outside of the scope of a simple discovery method. This is accomplished through the inclusion of a URI. And finally, the advertisement must be readable by humans (assuming they have access to this memo) as well as software specifically written for the purpose. 4. Language This section defines various terms used throughout this document. 4.1. General 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 [KEYWORDS]. 4.2. Email Specific [EMAIL-ARCH] introduces several terms and concepts that are used in this memo, and thus readers are advised to become familiar with it as well. 4.3. ARF Specific [MARF-BASE] introduces terms and concepts that are necessary for a full understanding of this memo, and thus readers are advised to read it before continuing. Falk Expires November 13, 2010 [Page 4] Internet-Draft ARF Reporting Discovery May 2010 5. Characteristics of a Feedback Reporting Advertisement An advertisement of willingness to generate or receive feedback is accomplished by publishing a TXT record in the [DNS] using the name '_report' within the given DNS domain. In the case of a feedback consumer, the advertisement should be published in the DNS domain matching the [DKIM] 'd=' value used on outgoing signatures, and/or in the DNS domain matching the one present in the [SMTP] MAIL commands it issues when sending mail, and/or in the DNS domain referenced by the DNS PTR record of the IP address of the border MTA used to transfer the message outside of its ADMD. In the case of a feedback generator, to inquire whether or not an ADMD wishes to receive feedback reports, the DNS domain to which the report should be sent is determined (using a mechanism at the discretion of the generator) and then a TXT record query to the above name is issued. For example, if a report generator wishes to generate a report about a message bearing DNS domain 'example.com', the generator would issue a TXT record query for `_report.example.com'. In the case of a feedback generator soliciting reports from its own end users, the advertisement will be associated with the host that provides [IMAP] or [POP] service to that user. For example, when the user's IMAP server is imap.example.net, the applicable advertisement will be found at _report.imap.example.net. 5.1. Feedback Consumers r the address to which reports should be sent. Required; no default. rf the format of the report requested; currently only "ARF" ([MARF-BASE]) is supported. Optional; defaults to ARF. ri requested report interval; may not be supported by all implementors. Optional; if omitted, all reports may be sent. rt colon-separated list of ARF ([MARF-BASE]) feedback types for which reports are requested. Optional; if omitted, all report types may be sent. re email address of a person or role account responsible for handling any issues related to receiving reports. Optional, but SHOULD be defined; defaults to postmaster@ the DNS domain. rp stated policy, as listed below. Optional; defaults to "o". Falk Expires November 13, 2010 [Page 5] Internet-Draft ARF Reporting Discovery May 2010 ru URI for additional contact information. Optional, but SHOULD be defined; there is no default value. 5.1.1. Feedback Consumer Policies Policies are listed in the "rp" tag, described above. o open to reports from all sources. This is the default. u restricted to reports from the ADMD's own users, as defined in additional fields below. c closed; no reports are requested. This option is intended for testing purposes. 5.2. Feedback Generators gf the format of reports offered; currently only "ARF" ([MARF-BASE]) is supported. Optional; defaults to "ARF". gt colon-separated list of ARF ([MARF-BASE]) feedback types for which reports are available. (Optional; if omitted, any report types may be generated.) ge email address of a person (or role account) responsible for handling any issues related to receiving reports. Optional, but SHOULD be defined; defaults to postmaster@ the DNS domain. gp stated policy, as listed below. Optional; defaults to "o". gu URI for additional information. This field SHOULD be defined for a policy of "o" or "c", and MUST be defined when the policy is "r". Otherwise, the field is optional; there is no default. 5.2.1. Feedback Generator Policies Policies are listed in the "gp" tag, described above. o open to providing reports to any consumer. This option is the default policy. r open to providing reports only after the prospective consumer has completed an application process, which may be found at the URI defined by the "gu" tag above. c closed; no reports are available. This option is intended for testing purposes. 5.3. Reporting Facility for End Users within an ADMD When the advertisement is intended to permit end users to report messages, it MUST include "rp=u" and SHOULD define the "re" field. Falk Expires November 13, 2010 [Page 6] Internet-Draft ARF Reporting Discovery May 2010 uf a colon-separated list of report formats accepted. Required. ur the email address to which reports MUST be addressed if using either the "ARF" or "822" formats. us an [SMTP] or [SUBMISSION] server via which reports MUST be submitted if using the "ARF" or "822" formats defined above. Optional; if not defined, implementors SHOULD use whichever SMTP server was configured by the user. uu a URI to which the report MUST be submitted if using the "HTTP" format. Otherwise optional. 5.3.1. End User Reporting Formats The format is defined in the "uf" field, described above. ARF an ARF ([MARF-BASE]) report may be sent to the email address defined in "ur" above, using the [SMTP] server defined in "us" above (if any). 822 an email message containing a message/rfc822 [MIME] part may be sent to the email address defined in "ur" above, using the [SMTP] server defined in "us" above (if any). HTTP a message/rfc822 [MIME] document may be transmitted via [HTTP] POST to the URI defined in "uu" below. 5.4. Note about URIs While this memo assumes that advertisements will contain http:// or similar URIs, implementors should be aware that the URI-related fields can carry many different types of data depending on the URI scheme used. For more information, please consult the URI Schemes registry maintained by IANA. 5.5. Formal Definition The formal definition using [ABNF] is TBD. 6. IANA Considerations This memo includes no request to IANA, though that may change in later drafts. 7. Security Considerations The following security considerations apply when generating or processing a feedback report: Falk Expires November 13, 2010 [Page 7] Internet-Draft ARF Reporting Discovery May 2010 7.1. Inherited from MARF-BASE All of the Security Considerations from [MARF-BASE] are inherited here. 7.2. TBD Additional security considerations are likely, and TBD. 8. Acknowledgements This document was heavily influenced by discussions on the topic within the IRTF Anti-Spam Research Group, collected at [ASRG-ABUSE]. 9. Contributors Many thanks to Murray Kucherawy, Alessandro Vesely, Todd Herr, Jacob Rideout, Derek Diget, Yakov Shafranovitch, and Barry Leiba for their suggestions and contributions. 10. References 10.1. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [DNS] Mockapetris, P., "Domain Names -- Implementation and Specification", RFC 1035, November 1987. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [MARF-BASE] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC TBD, April 2010. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. Falk Expires November 13, 2010 [Page 8] Internet-Draft ARF Reporting Discovery May 2010 10.2. Informative References [ASRG-ABUSE] Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF), "Abuse Reporting Standards Subgroup of the ASRG", May 2005. [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [DKIM-REPORTING] Kucherawy, M., "Reporting of DKIM Verification Failures", April 2010, . [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [HTTP] 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. [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [MAIL] Resnick, P., "Internet Message Format", RFC 5322, October 2008. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, May 1996. [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003. [SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005. Falk Expires November 13, 2010 [Page 9] Internet-Draft ARF Reporting Discovery May 2010 Appendix A. Sample Advertisements TBD Appendix B. Public Discussion, History and Support [REMOVE BEFORE PUBLICATION] Public discussion of this proposed specification is handled via the marf@ietf.org mailing list. The list is open. Access to subscription forms and to list archives can be found at http://www.ietf.org/mail-archive/web/marf/current/maillist.html Appendix C. Document History & Open Issues [REMOVE BEFORE PUBLICATION] C.1. draft-jdfalk-marf-reporting-discovery-00 o NEEDED: WG input, references cleanup, ABNF and other formal definitions, and probably lots of other stuff. o QUESTION: do there need to be IANA considerations for extensibility? o QUESTION: should this include IODEF as a format? C.2. draft-jdfalk-marf-reporting-discovery-01 o Removed "MARF Working Group" until the MARF WG takes up the document. o Changed from "Experimental" to "Standards Track". o Various non-normative textual & formatting improvements, most importantly changing "hangtext" to "hangText" because xml2rfc is (surprisingly) case-sensitive. o Added the PTR record as another place to look for advertisements published by ARF consumers. (This may require additional clarifications later in the text.) o Moved a few references from normative to informative. o NEEDED: sections describing the entire process, from advertisement to message transfer to discovery to reporting. o QUESTION: should the advertisement for MUAs be moved to a separate draft? o Questions & needs listed for version 00 remain valid. Falk Expires November 13, 2010 [Page 10] Internet-Draft ARF Reporting Discovery May 2010 Author's Address J. Falk Return Path 8001 Arista Place, Suite 300 Broomfield, CO 80021 US Email: ietf@cybernothing.org URI: http://www.returnpath.net/ Falk Expires November 13, 2010 [Page 11]