MARF Working Group J. Falk Internet-Draft Return Path Intended status: Experimental May 7, 2010 Expires: November 8, 2010 Advertising and Discovering Willingness to Provide or Receive ARF Reports draft-jdfalk-marf-reporting-discovery-00.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 8, 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 8, 2010 [Page 1] Internet-Draft ARF Reporting Discovery May 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Language . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Email Specific . . . . . . . . . . . . . . . . . . . . . . 6 4.3. ARF Specific . . . . . . . . . . . . . . . . . . . . . . . 6 5. Characteristics of a Feedback Reporting Advertisement . . . . 7 5.1. Feedback Consumers . . . . . . . . . . . . . . . . . . . . 7 5.1.1. Feedback Consumer Policies . . . . . . . . . . . . . . 8 5.2. Feedback Generators . . . . . . . . . . . . . . . . . . . 8 5.2.1. Feedback Generator Policies . . . . . . . . . . . . . 8 5.3. Reporting Facility for End Users within an ADMD . . . . . 9 5.3.1. End User Reporting Formats . . . . . . . . . . . . . . 9 5.4. Note about URIs . . . . . . . . . . . . . . . . . . . . . 9 5.5. Formal Definition . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7.1. Inherited from MARF-BASE . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Sample Advertisements . . . . . . . . . . . . . . . . 16 Appendix B. Public Discussion, History and Support . . . . . . . 17 Appendix C. Document History . . . . . . . . . . . . . . . . . . 18 C.1. draft-jdfalk-marf-reporting-discovery-00 . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Falk Expires November 8, 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 a format 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 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. Falk Expires November 8, 2010 [Page 3] Internet-Draft ARF Reporting Discovery May 2010 2. Purpose The reports defined in [MARF-BASE] are intended for multiple purposes: o To inform ISPs about email abuse originating from or related to their networks; o To inform email service providers or other primarily outbound senders that there may be abuse issues regarding their mail; these issues include (but are not limited to) reports that the mail may be considered to be "spam" by a recipient of the message. To support these purposes, this document addresses three primary use cases: o Any ADMD may advertise their 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 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. Falk Expires November 8, 2010 [Page 4] Internet-Draft ARF Reporting Discovery May 2010 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. Falk Expires November 8, 2010 [Page 5] Internet-Draft ARF Reporting Discovery May 2010 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 8, 2010 [Page 6] Internet-Draft ARF Reporting Discovery May 2010 5. Characteristics of a Feedback Reporting Advertisement An advertisement of willingness to generate or receive feedback is found in the [DNS] record of a domain associated with the mail service, using a construct of _report.domain. In the case of a feedback generator, the advertisement will be associated with the domain which receives the email for which feedback may be generated. For example, when email is addressed to example.com, the advertisement will be located at _report.example.com. In the case of a feedback consumer, the advertisement will be associated with either the [DKIM] d= domain or the [SMTP] MAIL FROM domain of the email message for which feedback may be generated -- preferably both. In the case of a feedback generator soliciting reports from their own end users, the advertisement will be associated with the host which 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 the address to which reports should be sent. Required; no default. the format of the report requested; currently only "ARF" ([MARF-BASE]) is supported. Optional; defaults to ARF. requested report interval; may not be supported by all implementors. Optional; if omitted, all reports may be sent. colon-separated list of ARF ([MARF-BASE]) feedback types for which reports are requested. Optional; if omitted, all report types may be sent. 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 domain. stated policy, as listed below. Optional; defaults to "o". URI for additional contact information. Optional, but SHOULD be defined; there is no default value. Falk Expires November 8, 2010 [Page 7] Internet-Draft ARF Reporting Discovery May 2010 5.1.1. Feedback Consumer Policies Policies are listed in the "rp" tag, described above. open to reports from all sources. This is the default. restricted to reports from the domain's own users, as defined in additional fields below. closed; no reports are requested. This option is intended for testing purposes. 5.2. Feedback Generators the format of reports offered; currently only "ARF" ([MARF-BASE]) is supported. Optional; defaults to "ARF". colon-separated list of ARF ([MARF-BASE]) feedback types for which reports are available. (Optional; if omitted, any report types may be generated.) 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 domain. stated policy, as listed below. Optional; defaults to "o". 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. open to providing reports to any consumer. This option is the default policy. 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. closed; no reports are available. This option is intended for testing purposes. Falk Expires November 8, 2010 [Page 8] Internet-Draft ARF Reporting Discovery May 2010 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. a colon-separated list of report formats accepted. Required. the email address to which reports MUST be addressed if using either the "ARF" or "822" formats. 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. 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. 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). 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). 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. Falk Expires November 8, 2010 [Page 9] Internet-Draft ARF Reporting Discovery May 2010 6. IANA Considerations This memo includes no request to IANA, though that may change in later drafts. Falk Expires November 8, 2010 [Page 10] Internet-Draft ARF Reporting Discovery May 2010 7. Security Considerations The following security considerations apply when generating or processing a feedback report: 7.1. Inherited from MARF-BASE All of the Security Considerations from [MARF-BASE] are inherited here. Additional security considerations are likely, and TBD. Falk Expires November 8, 2010 [Page 11] Internet-Draft ARF Reporting Discovery May 2010 8. Acknowledgements This document was heavily influenced by discussions on the topic within the IRTF Anti-Spam Research Group, collected at [ASRG-ABUSE]. Falk Expires November 8, 2010 [Page 12] Internet-Draft ARF Reporting Discovery May 2010 9. Contributors Looking forward to contributions. Falk Expires November 8, 2010 [Page 13] Internet-Draft ARF Reporting Discovery May 2010 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. [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. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [MAIL] Resnick, P., "Internet Message Format", RFC 5322, October 2008. [MARF-BASE] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", April 2010. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. 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] Falk Expires November 8, 2010 [Page 14] Internet-Draft ARF Reporting Discovery May 2010 Kucherawy, M., "Reporting of DKIM Verification Failures", April 2010, . [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008. [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, May 1996. [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 8, 2010 [Page 15] Internet-Draft ARF Reporting Discovery May 2010 Appendix A. Sample Advertisements TBD Falk Expires November 8, 2010 [Page 16] Internet-Draft ARF Reporting Discovery May 2010 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 Falk Expires November 8, 2010 [Page 17] Internet-Draft ARF Reporting Discovery May 2010 Appendix C. Document History [REMOVE BEFORE PUBLICATION] C.1. draft-jdfalk-marf-reporting-discovery-00 o Needs 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? Falk Expires November 8, 2010 [Page 18] Internet-Draft ARF Reporting Discovery May 2010 Author's Address J.D. Falk Return Path 8001 Arista Place, Suite 300 Broomfield, CO 80021 US Email: ietf@cybernothing.org URI: http://www.returnpath.net/ Falk Expires November 8, 2010 [Page 19]