Network Working Group A. Vesely Internet-Draft October 4, 2011 Intended status: Standards Track Expires: April 6, 2012 IODEF Extension to Support Mail Abuse Reporting draft-vesely-mile-mail-abuse-00 Abstract This document extends the Incident Object Description Exchange Format (IODEF) to allow mail-abuse reports to be shared as Incidents in the IODEF framework. 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 April 6, 2012. Copyright Notice Copyright (c) 2011 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. Vesely Expires April 6, 2012 [Page 1] Internet-Draft iodef-arf extension October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Conversion to IODEF . . . . . . . . . . . . . . . . . . . 4 3.2. Conversion from IODEF . . . . . . . . . . . . . . . . . . 4 4. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4 4.1. AbuseReport . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Text . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. ArfHeader . . . . . . . . . . . . . . . . . . . . . . 6 4.1.3. EmailMessage . . . . . . . . . . . . . . . . . . . . . 7 4.2. Note on Newline Representation . . . . . . . . . . . . . . 7 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. ARF Extension Schema . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Vesely Expires April 6, 2012 [Page 2] Internet-Draft iodef-arf extension October 2011 1. Introduction Spam victims may tag some received messages as abusive. The Abuse Reporting Format [ARF] was developed for reporting those messages to where they can be taken care of. For example, [ARF] is used by Mailbox Providers to forward abuse reports to senders who had established a Feedback Loop [FBL]. Mail-abuse can be reported to a Network Provider related to the IP address that relayed an abusive email message, whether using ARF or simply attaching the abusive message to a complaint, depending on the tools at hand. Both the "abuse@domain" role address specified by [MAILBOX-NAMES] and the abuse-mailbox contacts as found in whois databases are possible targets of unsolicited abuse reports. In addition, [REPORTING-DISCOVERY] defines ways to discover or publish contacts for FBL subscriptions. When received by a party held responsible for the abusive message, an abuse report may highlight the need for corrective actions that can be carried out more conveniently if the report is converted in the Incident Object Description Exchange Format [IODEF]. For example, the original message may turn out to be a phishing attempt and needs to be further converted to the format defined by [FRAUD-EXT], it may call for trace-back, mitigation, or further reporting, or it may reveal that the emitting machine is infected. This [IODEF] extension defines a representation of an abuse-report, whereby a IODEF Incident may contain one or more complaints, either ARF or plain text with a message attachment. It is beyond the scope of this memo to outline possible use cases, albeit they are mentioned above as examples. 2. Terminology The terminology used in this document follows the one defined in [IODEF] and [TEMPLATE]. Network provider is defined in [RID]. Mailbox Provider is defined in [FBL]. It includes email facilities in corporations, universities, and similar organizations. 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 RFC 2119 [RFC2119]. Vesely Expires April 6, 2012 [Page 3] Internet-Draft iodef-arf extension October 2011 3. Applicability 3.1. Conversion to IODEF Network providers may want to convert abuse reports received over [SMTP] into EventData instances to deploy IODEF infrastructures. Conversion notes are given along with the definition (Section 4). 3.2. Conversion from IODEF An Incident representing an abuse report may need to be converted back to an email message for transmitting it via SMTP if, for example, the target party does not support IODEF. [ARF] is designed to be readable without specific tools, and machine- readable as well. It is advisable to use ARF, so as to allow automated processing. However, plain text with attachment(s) has to be used when it is necessary to convey information which cannot be formatted in ARF, as its human-readable part is likely to be discarded by automated processes. 4. Extension Definition This extension defines a simple structure to represent an abuse report. The following diagram is reproduced from [IODEF] and modified to show where the AbuseReport class lies. +--------------------+ | Incident | +--------------------+ | ENUM purpose |<>----------[ IncidentID ] | STRING ext-purpose |<>--{0..1}--[ AlternativeID ] | ENUM lang |<>--{0..1}--[ RelatedActivity ] | ENUM restriction |<>--{0..1}--[ DetectTime ] | |<>--{0..1}--[ StartTime ] | |<>--{0..1}--[ EndTime ] | |<>----------[ ReportTime ] | |<>--{0..*}--[ Description ] | |<>--{1..*}--[ Assessment ] | |<>--{0..*}--[ Method ] | |<>--{1..*}--[ Contact ] | |<>--{0..*}--[ EventData ] | | |<>--[ AdditionalData ] | | |<>--[ AbuseReport ] | |<>--{0..1}--[ History ] | |<>--{0..*}--[ AdditionalData ] +--------------------+ Vesely Expires April 6, 2012 [Page 4] Internet-Draft iodef-arf extension October 2011 The AbuseReport position within the Incident Class An incident normally refers to the abusive message, not to the act of reporting it. However, the EventData instance that hosts an AbuseReport SHOULD contain information about the report sender. If the report was sent via [SMTP], its header may contain authentication information such as [DKIM] or [SPF], possibly validated on reception and reported in an Authentication-Result [A-R] header field. The [EMAIL] header of the report will not be part of the AbuseReport. Therefore it is RECOMMENDED that any assessment on authenticity and trust be conveyed using general [IODEF] classes. By contrast, note that the full header of the abusive message being reported MUST be present, as abuse reports don't make sense without it. 4.1. AbuseReport The AbuseReport structure closely resembles either [ARF] or a plain text complaint with an abusive message attached. +--------------------+ | AbuseReport | +--------------------+ | |<>--{0..1}--[ Text ] | |<>--{0..1}--[ ArfHeader ] | |<>----------[ EmailMessage ] +--------------------+ AbuseReport structure At least one of Text or ArfHeader SHOULD be present. The meaning of each element is as follows: Text: Zero or one. ML_STRING. The human-readable part of an [ARF] report or the textual part of a manually submitted report. ArfHeader: Zero or one. The machine-readable part of an [ARF] report. EmailMessage: One. ML_STRING. The abusive message reported. 4.1.1. Text Zero or one. ML_STRING. Meaningful values of header fields MAY be retained from the report's header. In particular, the following fields are often considered meaningful: From, Subject, Date, To, CC, Reply-To. However, if the Subject merely repeats that of the reported message, and the Date as Vesely Expires April 6, 2012 [Page 5] Internet-Draft iodef-arf extension October 2011 well as the relevant contacts are being conveyed in other parts of the EventData, it is not necessary to repeat those values here. The human-readable part of machine generated [ARF] reports usually consists of boilerplate informing what is an ARF message. Such kind of text MAY be omitted, and if no header field is retained, the Text element MAY be omitted altogether. 4.1.2. ArfHeader The presence of this element indicates that this Incident represents an [ARF] report, as opposed to a manually written complaint. +--------------------+ | ArfHeader | +--------------------+ | |<>--{0..*}--[ Field ] +--------------------+ ArfHeader structure An ArfHeader consists of a sequence of fields. Field: Zero or more. A field is a name/value pair. [ARF] defines required and optional fields, appearing once or multiple times. It is an extensible specification, and there are two IANA registries tracking report types and allowed field names respectively. The order of the fields is unimportant. +--------------------+ | Field | +--------------------+ | STRING Name | +--------------------+ ArfHeader Field A Field is a name/value pair. The name is represented as an attribute, while the value is its content. [ARF] header fields are formatted like [EMAIL] header fields; that is, a name followed by a colon (":") and a value. name: One. Restricted STRING. Allowable names are restricted by [EMAIL] to printable US-ASCII characters not including the colon. We further restrict names to lowercase, since they are meant to be case insensitive while the values of XML attributes are not. Vesely Expires April 6, 2012 [Page 6] Internet-Draft iodef-arf extension October 2011 element content: STRING. Leading and trailing whitespace MAY be omitted. Any internal newlines MAY be retained. If an internal newline is retained, some, but not all, of the leading whitespace in the following line MAY be omitted. See also Section 4.2. 4.1.3. EmailMessage An EmailMessage contains one ML_STRING. This is the [EMAIL] message content; that is, the header possibly followed by the body. The header MUST be present, and the body SHOULD be present. 4.2. Note on Newline Representation [EMAIL] states that messages consists of multiple lines, and that the CRLF two-byte sequence is the line termination when messages are transmitted over [SMTP]. The header is a sequence of header fields, where each line starting with a non-whitespace character is the beginning of a field. The line length is limited to 78 characters, excluding the CRLF, hence the limit on valid field names. Field values may span multiple lines, provided that each successive line starts with whitespace. An empty line delimits the end of the header. [XML] end-of-line handling provides for CRLF to be normalized as LF. This poses no problems, as many mail agents handle local storage in the same way. Conversion to/from IODEF has to adapt to local conventions for receiving/sending email messages. 5. Example The "simple report" given in Appendix B.1 of RFC 5965 can be converted as follows: FBL20050308-3 2005-03-08T17:40:36-04:00 example.net abuse@example.net Vesely Expires April 6, 2012 [Page 7] Internet-Draft iodef-arf extension October 2011 2005-03-08T17:40:36-04:00 example.com Feedback Generator abusedesk@example.com fbl-out.example.com
192.0.2.129
abuse SomeGenerator/1.0 1 Received: from mailserver.example.net (mailserver.example.net [192.0.2.1]) by example.com with ESMTP id M63d4137594e46; Thu, 08 Mar 2005 14:00:00 -0400 From: <somespammer@example.net> To: <Undisclosed Recipients> Subject: Earn money MIME-Version: 1.0 Content-type: text/plain Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net Date: Thu, 02 Sep 2004 12:31:03 -0500 Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam
ARF Converted to Incident Vesely Expires April 6, 2012 [Page 8] Internet-Draft iodef-arf extension October 2011 6. IANA Considerations TBD. 7. Security Considerations TBD. 8. References 8.1. Normative References [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010. [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [XML] Yergeau, F., Bray, T., Sperberg-McQueen, C., Maler, E., and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, . 8.2. Informative References [A-R] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [EMAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [FBL] Falk, J., "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", draft-ietf-marf-as-00 (work in progress), September 2011. Vesely Expires April 6, 2012 [Page 9] Internet-Draft iodef-arf extension October 2011 [FRAUD-EXT] Cain, P. and D. Jevans, "Extensions to the IODEF-Document Class for Reporting Phishing", RFC 5901, July 2010. [MAILBOX-NAMES] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997. [REPORTING-DISCOVERY] Falk, J., "A DNS TXT Record for Advertising and Discovering Willingness to Provide or Receive ARF Reports", draft-ietf-marf-reporting-discovery-00 (work in progress), January 2011. [RID] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6045, November 2010. [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. [TEMPLATE] Trammell, B., "Guidelines for Extensions to IODEF for Managed Incident Lightweight Exchange", draft-trammell-mile-template-01 (work in progress), July 2011. Appendix A. ARF Extension Schema Vesely Expires April 6, 2012 [Page 11] Internet-Draft iodef-arf extension October 2011 Author's Address Alessandro Vesely v. L. Anelli 13 Milano, MI 20122 IT Email: vesely@tana.it Vesely Expires April 6, 2012 [Page 12]