MARF WG Y. Cai Internet-Draft G. Shanker Intended status: Standards Track M. Torabi Expires: January 6, 2011 Z. Zeltsan Alcatel-Lucent July 5, 2010 An Extensible Format for SMSC/MMSC Feedback Reports draft-cai-smsc-mmsc-reporting-marf-00 Abstract This document defines an extensible format and MIME type that may be used by SMSC or MMSC to report feedback about received SMS/MMS with message abuses. 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 January 6, 2011. 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. Cai, et al. Expires January 6, 2011 [Page 1] Internet-Draft Format for SMSC/MMSC Feedback Reports July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 3. SMS/MMS Reporting Required Fields . . . . . . . . . . . . . . 4 4. Description of the SMS/MMS Reporting Required Fields . . . . . 5 4.1. Message ID . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Message Center ID . . . . . . . . . . . . . . . . . . . . 5 4.3. Message Type . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Message Protocol ID . . . . . . . . . . . . . . . . . . . 5 4.5. Message Teleservice ID . . . . . . . . . . . . . . . . . . 6 4.6. Message Language Indicator . . . . . . . . . . . . . . . . 6 4.7. Message Segment Indicator . . . . . . . . . . . . . . . . 6 4.8. Message Data Encoding . . . . . . . . . . . . . . . . . . 6 4.9. Message User Data . . . . . . . . . . . . . . . . . . . . 6 4.10. Originating Domain . . . . . . . . . . . . . . . . . . . . 6 4.11. Originating Address Type . . . . . . . . . . . . . . . . . 6 4.12. Originating Address . . . . . . . . . . . . . . . . . . . 6 4.13. Terminating Domain . . . . . . . . . . . . . . . . . . . . 6 4.14. Termination Address Type . . . . . . . . . . . . . . . . . 7 4.15. Termination Address . . . . . . . . . . . . . . . . . . . 7 4.16. Abuse Type . . . . . . . . . . . . . . . . . . . . . . . . 7 4.17. Abuse Detected Methods . . . . . . . . . . . . . . . . . . 7 4.18. Abuse Keyword . . . . . . . . . . . . . . . . . . . . . . 8 4.19. Abuse Multimedia Element . . . . . . . . . . . . . . . . . 8 4.20. Message Delivery Decision . . . . . . . . . . . . . . . . 8 4.21. Message Received Timestamp . . . . . . . . . . . . . . . . 8 4.22. Message Delivered Timestamp . . . . . . . . . . . . . . . 8 4.23. Message Blocked Timestamp . . . . . . . . . . . . . . . . 9 5. Handling of SMS/MMS Reporting . . . . . . . . . . . . . . . . 9 6. Transport Consideration . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Cai, et al. Expires January 6, 2011 [Page 2] Internet-Draft Format for SMSC/MMSC Feedback Reports July 2010 1. Introduction As the SMS/MMS spam problem continues to expand and potential solutions evolve, mobile operators are developing their own SMS/MMS anti-spam application on SMSC/MMSC or message gateways. There is almost no centralized reporting agent/system to receive a SMS/MMS message abuse reports. There is no centralized message spam analysis system which receives reports from individual message centers and instructs the message centers with filtering criteria and rules which are developed from message abuse reporting. This document introduces a SMS/MMS message abuse report and defines the content and report format; therefore, extends [draft-ietf-marf-base] to add features required for SMSC/MMSC reporting. 1.1. Purpose The reports defined in this document are intended to inform SMS/MMS operators about: o SMS/MMS abuse originating from foreign networks o SMS/MMS abuse originating from their networks o SMS/MMS abuse originating from application entities 1.2. Requirements The following requirements are necessary for feedback reports (the actual specification is defined later in this document): o They must be both human and machine readable o In order to allow the receiver to handle the report properly, one of the following data must be enclosed in the report: * The original message headers and whole message body * The original message headers and a part of the message body which contains spam * The original message headers only o The machine-readable section must provide ability for the report generators to share the message meta-data with receivers Cai, et al. Expires January 6, 2011 [Page 3] Internet-Draft Format for SMSC/MMSC Feedback Reports July 2010 o The format must be extensible 2. Notational Conventions 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 [RFC2119]. 3. SMS/MMS Reporting Required Fields The format of email feedback reports as a MIME message in [draft-ietf-marf-base] should be extended to include SMS/MMS message abuse report. The following is a non-exhaustive list of the specific parameters that SHOULD be included as optional fields in the base reporting MIME feedback reports, but are RECOMMENDED for SMS/MMS message reporting: o Message ID o Message Center ID o Message Type o Message Protocol ID o Message Teleservice ID o Message Language Indicator (M) o Message Segment Indicator o Message Data Encoding o Message User Data o Originating Domain o Originating Address Type o Originating Address o Terminating Domain o Termination Address Type Cai, et al. Expires January 6, 2011 [Page 4] Internet-Draft Format for SMSC/MMSC Feedback Reports July 2010 o Termination Address o Abuse Type (M) o Abuse Detected Methods (M) o Abuse Keyword (M) o Abuse Multimedia Elements (M) o Message Delivery Decision o Message Received Timestamp o Message Delivered Timestamp o Message Blocked Timestamp The above parameters can appear once or many (M) times in the SMS/MMS feedback reporting. 4. Description of the SMS/MMS Reporting Required Fields 4.1. Message ID Message ID optional field is of type Integer and is the unique identifier for this message element. It can be received from the incoming message, or created by the message center for an outgoing message. 4.2. Message Center ID Message Center ID optional field is of type Integer and is the unique identifier for the message center which sends the feedback reporting. 4.3. Message Type Message Type optional field is of type Enumerated and is the indicator for the message types: email, SMS, MMS, IM, etc. 4.4. Message Protocol ID Message protocol ID optional field is of type Enumerated and is the indicator for the message protocol used by the message center: SMTP, SMPP, 3GPP MAP, 3GPP SIP, 3GPP2 SIP, ANSI SMDPP, etc. Cai, et al. Expires January 6, 2011 [Page 5] Internet-Draft Format for SMSC/MMSC Feedback Reports July 2010 4.5. Message Teleservice ID Message teleservice ID optional field is of type String and is the indicator for the message teleservice identifier or service type. 4.6. Message Language Indicator Message language indicator optional field is of type Integer and is the indicator of the message language. 4.7. Message Segment Indicator Message segment indicator optional field is of type Integer and is the indicator for the message segment(s). 4.8. Message Data Encoding Message user data optional field is of type String. It contains the user data coding schemes. 4.9. Message User Data Message user data optional field is of type UTF8String. It contains the user data from the original message. Inclusion of the parts of original data that contain spam is optional. 4.10. Originating Domain Originating domain optional field is of type String. It includes the domain name of the originating network. 4.11. Originating Address Type Originating address type optional field is of type Enumerated and is the indicator of address type, IP address, mobile number (MSISDN, IMSI), email address, etc. 4.12. Originating Address Originating address optional field is of type String and includes the originator address. 4.13. Terminating Domain Terminating domain optional field is of type String. It includes the domain name of the terminating network. Cai, et al. Expires January 6, 2011 [Page 6] Internet-Draft Format for SMSC/MMSC Feedback Reports July 2010 4.14. Termination Address Type Terminating address type optional field is of type Enumerated and is the indicator of address type, IP address, mobile number (MSISDN, IMSI), email address, etc. 4.15. Termination Address Terminating address optional field is of type String and includes the recipient address. 4.16. Abuse Type Abuse type optional field is of type Enumerated and includes the abuse types: o Spam o Phishing o Spoofing o Fake sender address o Unauthorized sender/recipient o Suspicious network/domain o Message flooding o Denial of service attack o Malware (e.g., virus/spyware) o Unauthorized message (violation of a security policy) o Not Spam 4.17. Abuse Detected Methods Abuse detected method optional field is of type Enumerated and includes the abuse detected rules and methods: o White/black list o Forbidden network domain/address screening Cai, et al. Expires January 6, 2011 [Page 7] Internet-Draft Format for SMSC/MMSC Feedback Reports July 2010 o Forbidden application entity screening o Spam keywords match o Spam multimedia match o Spam pattern match o Volume threshold per sender match o Volume threshold per sending network/domain match o Others 4.18. Abuse Keyword Abuse keyword optional field is of type String and includes the abuse keywords detected by message center. The content of this field should be single or multiple words, a phrase, a short sentence, etc. 4.19. Abuse Multimedia Element Abuse multimedia element optional field is of type UTF8String and includes the abuse multimedia element detected by message center. 4.20. Message Delivery Decision Message delivery decision optional field is of type Enumerated and followings: o Delivered o Rejected with notification o Dropped silently o On hold for instruction 4.21. Message Received Timestamp Message received timestamp optional field is of type Time and holds the time the message received or created at the message center. 4.22. Message Delivered Timestamp Message delivered timestamp optional field is of type Time and holds the time the message delivered by the message center. Cai, et al. Expires January 6, 2011 [Page 8] Internet-Draft Format for SMSC/MMSC Feedback Reports July 2010 4.23. Message Blocked Timestamp Message blocked timestamp optional field is of type Time and holds the time the message rejected or dropped silently at the message center. 5. Handling of SMS/MMS Reporting When an agent that accepts and handles SMS/MMS abuse reporting message, besides actions defined in other MARF drafts, the agent may distribute a notification message on the abuse source network, entity, address, protocol, and spam keywords/patterns to other message centers. The format of notification message will be defined in separately. 6. Transport Consideration Besides transport considered in [draft-ietf-marf-base], alternative transports (TBD) should also be considered for SMS/MMS feedback reports. 7. IANA Considerations None. 8. Security Considerations Refer to [draft-ietf-marf-base]. 9. Acknowledgements The authors thank Igor Faynberg for his invaluable help with preparing this document. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [draft-ietf-marf-base] Melnikov, A., "An Extensible Format for Email Feedback Reports", RFC , May 2010, Cai, et al. Expires January 6, 2011 [Page 9] Internet-Draft Format for SMSC/MMSC Feedback Reports July 2010 . Authors' Addresses Yigang Cai Alcatel-Lucent 2000 Lucent Ln Naperville, IL 60563 USA Phone: +1 630 979 3303 Email: Yigang.Cai@alcatel-lucent.com Gyan Shanker Alcatel-Lucent 2000 Lucent Ln Naperville, IL 60563 USA Phone: +1 630 979 4627 Email: Gyan.Shanker@alcatel-lucent.com Moh Torabi Alcatel-Lucent 23812 Dasya Circle Monarch Beach, CA 92629 USA Phone: +1 949 636 2116 Email: Moh.Torabi@alcatel-lucent.com Zachary Zeltsan Alcatel-Lucent 600 Mountain Avenue Murray Hill, NJ USA Phone: +1 908 582 2359 Email: Zachary.Zeltsan@alcatel-lucent.com Cai, et al. Expires January 6, 2011 [Page 10]