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.

Table of Contents

1.  Introduction
2.  Purpose
3.  Requirements
4.  Language
    4.1.  General
    4.2.  Email Specific
    4.3.  ARF Specific
5.  Characteristics of a Feedback Reporting Advertisement
    5.1.  Feedback Consumers
        5.1.1.  Feedback Consumer Policies
    5.2.  Feedback Generators
        5.2.1.  Feedback Generator Policies
    5.3.  Reporting Facility for End Users within an ADMD
        5.3.1.  End User Reporting Formats
    5.4.  Note about URIs
    5.5.  Formal Definition
6.  IANA Considerations
7.  Security Considerations
    7.1.  Inherited from MARF-BASE
    7.2.  TBD
8.  Acknowledgements
9.  Contributors
10.  References
    10.1.  Normative References
    10.2.  Informative References
Appendix A.  Sample Advertisements
Appendix B.  Public Discussion, History and Support
Appendix C.  Document History & Open Issues
    C.1.  draft-jdfalk-marf-reporting-discovery-00
    C.2.  draft-jdfalk-marf-reporting-discovery-01
§  Author's Address

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] (Shafranovich, Y., Levine, J., and M. Kucherawy, “An Extensible Format for Email Feedback Reports,” April 2010.) 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] (Shafranovich, Y., Levine, J., and M. Kucherawy, “An Extensible Format for Email Feedback Reports,” April 2010.) are intended to inform mail operators about:

• email abuse originating from their networks;
• 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:

• Any ADMD may advertise its willingness to receive reports from the internet at large, given particular criteria included in or referenced by the advertisement;
• Any ADMD may advertise their willingness to provide reports to the Internet at large, given particular criteria included in or referenced by the advertisement;
• 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] (Shafranovich, Y., Levine, J., and M. Kucherawy, “An Extensible Format for Email Feedback Reports,” April 2010.) 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] (Kucherawy, M., “Reporting of DKIM Verification Failures,” April 2010.) 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] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) and [DKIM‑REPORTING] (Kucherawy, M., “Reporting of DKIM Verification Failures,” April 2010.), the advertisement is in the form of a [DNS] (Mockapetris, P., “Domain Names -- Implementation and Specification,” November 1987.) 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

4.2.  Email Specific

[EMAIL‑ARCH] (Crocker, D., “Internet Mail Architecture,” July 2009.) 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] (Shafranovich, Y., Levine, J., and M. Kucherawy, “An Extensible Format for Email Feedback Reports,” April 2010.) introduces terms and concepts that are necessary for a full understanding of this memo, and thus readers are advised to read it before continuing.

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] (Mockapetris, P., “Domain Names -- Implementation and Specification,” November 1987.) 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] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) 'd=' value used on outgoing signatures, and/or in the DNS domain matching the one present in the [SMTP] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.) 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] (Crispin, M., “INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1,” March 2003.) or [POP] (Myers, J. and M. Rose, “Post Office Protocol - Version 3,” May 1996.) 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] (Shafranovich, Y., Levine, J., and M. Kucherawy, “An Extensible Format for Email Feedback Reports,” April 2010.)) 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] (Shafranovich, Y., Levine, J., and M. Kucherawy, “An Extensible Format for Email Feedback Reports,” April 2010.)) 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".

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] (Shafranovich, Y., Levine, J., and M. Kucherawy, “An Extensible Format for Email Feedback Reports,” April 2010.)) is supported. Optional; defaults to "ARF".

gt

colon-separated list of ARF ([MARF‑BASE] (Shafranovich, Y., Levine, J., and M. Kucherawy, “An Extensible Format for Email Feedback Reports,” April 2010.)) 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.

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] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.) or [SUBMISSION] (Gellens, R. and J. Klensin, “Message Submission for Mail,” April 2006.) 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] (Shafranovich, Y., Levine, J., and M. Kucherawy, “An Extensible Format for Email Feedback Reports,” April 2010.)) report may be sent to the email address defined in "ur" above, using the [SMTP] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.) server defined in "us" above (if any).

822

an email message containing a message/rfc822 [MIME] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) part may be sent to the email address defined in "ur" above, using the [SMTP] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.) server defined in "us" above (if any).

HTTP

a message/rfc822 [MIME] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) document may be transmitted via [HTTP] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) 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] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) 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:

7.1.  Inherited from MARF-BASE

All of the Security Considerations from [MARF‑BASE] (Shafranovich, Y., Levine, J., and M. Kucherawy, “An Extensible Format for Email Feedback Reports,” April 2010.) 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] (Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF), “Abuse Reporting Standards Subgroup of the ASRG,” May 2005.).

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

10.2. Informative References

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

• NEEDED: WG input, references cleanup, ABNF and other formal definitions, and probably lots of other stuff.
• QUESTION: do there need to be IANA considerations for extensibility?
• QUESTION: should this include IODEF as a format?

C.2.  draft-jdfalk-marf-reporting-discovery-01

• Removed "MARF Working Group" until the MARF WG takes up the document.
• Changed from "Experimental" to "Standards Track".
• Various non-normative textual & formatting improvements, most importantly changing "hangtext" to "hangText" because xml2rfc is (surprisingly) case-sensitive.
• Added the PTR record as another place to look for advertisements published by ARF consumers. (This may require additional clarifications later in the text.)
• Moved a few references from normative to informative.
• NEEDED: sections describing the entire process, from advertisement to message transfer to discovery to reporting.
• QUESTION: should the advertisement for MUAs be moved to a separate draft?
• Questions & needs listed for version 00 remain valid.

Author's Address