Internet DRAFT - draft-vesely-mile-mail-abuse
draft-vesely-mile-mail-abuse
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:
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document lang="en-US"
xmlns:arf="urn:ietf:params:xml:ns:iodef-arf-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<Incident purpose="reporting">
<IncidentID name="example.net">FBL20050308-3</IncidentID>
<ReportTime>2005-03-08T17:40:36-04:00</ReportTime>
<Assessment>
<Impact type="policy" lang="en"/>
</Assessment>
<Contact role="creator" type="organization">
<ContactName>example.net</ContactName>
<Email>abuse@example.net</Email>
Vesely Expires April 6, 2012 [Page 7]
Internet-Draft iodef-arf extension October 2011
</Contact>
<EventData>
<DetectTime>2005-03-08T17:40:36-04:00</DetectTime>
<Contact role="irt" type="organization">
<ContactName>example.com</ContactName>
<Description>Feedback Generator</Description>
<Email>abusedesk@example.com</Email>
</Contact>
<Flow>
<System>
<Node>
<NodeName>fbl-out.example.com</NodeName>
<Address category="ipv4-addr">192.0.2.129</Address>
</Node>
</System>
</Flow>
<AdditionalData dtype="xml">
<arf:AbuseReport>
<arf:ArfHeader>
<arf:Field name="feedback-type">abuse</arf:Field>
<arf:Field name="user-agent">SomeGenerator/1.0</arf:Field>
<arf:Field name="version">1</arf:Field>
</arf:ArfHeader>
<arf:EmailMessage>
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:EmailMessage>
</arf:AbuseReport>
</AdditionalData>
</EventData>
</Incident>
</IODEF-Document>
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,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
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
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:iodef-arf-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:arf="urn:ietf:params:xml:ns:iodef-arf-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<!--
==========================================================
=== Top-Level Class: AbuseReport ===
==========================================================
It is incorporated within an
Vesely Expires April 6, 2012 [Page 10]
Internet-Draft iodef-arf extension October 2011
IODEF.Incident.EventData.AdditionalData element.
-->
<xs:element name="AbuseReport">
<xs:complexType>
<xs:sequence>
<!-- the readable text part (boilerplate may be omitted) -->
<xs:element minOccurs="0" name="Text"
type="iodef:MLStringType"/>
<!-- an ArfHeader is present iff the report was in ARF format -->
<xs:element minOccurs="0" name="ArfHeader">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="Field">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<!-- the name attribute indicates the field-name,
as defined by RFC 5322 (and RFC5335bis) i.e.
printable US-ASCII characters not including ":",
we additionally forbid uppercase letters -->
<xs:attribute name="name" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[!-~-[:A-Z]]{1,77}"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- the original message (header + body) -->
<xs:element name="EmailMessage"
type="iodef:MLStringType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs: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]
