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, <http://tools.ietf.org/html/
draft-ietf-marf-dkim-reporting>.
[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]