MARF WG Y. Cai Internet-Draft G. Shanker Intended status: Standards Track S. Singh Expires: August 27, 2011 M. Torabi Z. Zeltsan Alcatel-Lucent February 23, 2011 Anti-Spam Policy Instruction/Distribution Operation draft-cai-marf-policy-instruction-operation-00 Abstract This document defines an anti-spam policy instruction and distribution operation from Spam Reporting Server or Spam Reporting Client to Spam Reporting Client or Clients. 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 August 27, 2011. 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 Cai, et al. Expires August 27, 2011 [Page 1] Internet-Draft Anti-Spam Operation February 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Notational Conventions . . . . . . . . . . . . . . . . . . 5 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3. Anti-spam Policy Instruction/Distribution Procedures . . . . . 5 3.1. Operation Procedure for Unsolicited Policy Instruction/Distribution . . . . . . . . . . . . . . . . . 6 3.1.1. Server Procedure . . . . . . . . . . . . . . . . . . . 6 3.1.2. Client Procedure . . . . . . . . . . . . . . . . . . . 7 3.2. Operation Procedure for Notification to Subscribe/Unsubscribe Anti-Spam Policy Instruction/Distribution . . . . . . . . . . . . . . . . . 8 3.2.1. Client Procedure . . . . . . . . . . . . . . . . . . . 9 3.2.2. Server Procedure . . . . . . . . . . . . . . . . . . . 9 3.3. Operation Procedure for On-Demand of Anti-Spam Policy Instruction . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Client Procedure . . . . . . . . . . . . . . . . . . . 11 3.3.2. Server Procedure . . . . . . . . . . . . . . . . . . . 11 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Anti-Spam Policy Instruction/Distribution Messages . . . . 12 4.1.1. Request Message . . . . . . . . . . . . . . . . . . . 12 4.1.2. Response Message . . . . . . . . . . . . . . . . . . . 14 4.2. Notification to Subscribe/Unsubscribe Anti-Spam Policy Instruction/Distribution . . . . . . . . . . . . . . . . . 15 4.2.1. Request Message . . . . . . . . . . . . . . . . . . . 15 4.2.2. Response Message . . . . . . . . . . . . . . . . . . . 15 4.3. On-Demand Query of Anti-Spam Policy Instruction . . . . . 16 4.3.1. Request Message . . . . . . . . . . . . . . . . . . . 16 4.3.2. Response Message . . . . . . . . . . . . . . . . . . . 17 5. Message Element Descriptions . . . . . . . . . . . . . . . . . 19 5.1. Request ID . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Request Timestamp . . . . . . . . . . . . . . . . . . . . 19 5.3. Request Received Timestamp . . . . . . . . . . . . . . . . 19 5.4. Response Timestamp . . . . . . . . . . . . . . . . . . . . 19 5.5. Originating Node Address . . . . . . . . . . . . . . . . . 19 5.6. Termination Node Address . . . . . . . . . . . . . . . . . 19 5.7. Policy Body . . . . . . . . . . . . . . . . . . . . . . . 19 5.8. Policy ID . . . . . . . . . . . . . . . . . . . . . . . . 20 5.9. Network Type . . . . . . . . . . . . . . . . . . . . . . . 20 5.10. Protocol ID . . . . . . . . . . . . . . . . . . . . . . . 20 5.11. Message Type . . . . . . . . . . . . . . . . . . . . . . . 20 5.12. Message Attributes . . . . . . . . . . . . . . . . . . . . 20 5.13. Suspicious Network Domain . . . . . . . . . . . . . . . . 20 Cai, et al. Expires August 27, 2011 [Page 2] Internet-Draft Anti-Spam Operation February 2011 5.14. Suspicious Address . . . . . . . . . . . . . . . . . . . . 20 5.15. Suspicious Address Type . . . . . . . . . . . . . . . . . 20 5.16. Spam Type . . . . . . . . . . . . . . . . . . . . . . . . 20 5.17. Language Indicator . . . . . . . . . . . . . . . . . . . . 21 5.18. Detection Information . . . . . . . . . . . . . . . . . . 21 5.19. Action Information . . . . . . . . . . . . . . . . . . . . 22 5.20. Privacy Shield Information . . . . . . . . . . . . . . . . 22 5.21. Affective Filtering Start Timestamp . . . . . . . . . . . 22 5.22. Affective Filtering Stop Timestamp . . . . . . . . . . . . 22 5.23. Result Code . . . . . . . . . . . . . . . . . . . . . . . 22 5.24. Anti-Spam Policy Instruction Control . . . . . . . . . . . 22 5.25. InstructionAction . . . . . . . . . . . . . . . . . . . . 23 5.26. Existing Policy IDs . . . . . . . . . . . . . . . . . . . 23 6. Result Codes . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Normal Return Codes . . . . . . . . . . . . . . . . . . . 23 6.2. Error Return Codes . . . . . . . . . . . . . . . . . . . . 23 7. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 11. Normative References . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Cai, et al. Expires August 27, 2011 [Page 3] Internet-Draft Anti-Spam Operation February 2011 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. Open Mobile Alliance (OMA) developed OMA Mobile Spam Reporting Technical Specification [OMA TS SpamRep], which addresses the Spam Reporting Server and Clients requirements for SMS/MMS and other spam reporting. This OMA SpamRep specification is to be adopted by IETF MARF group. However, there is no centralized message spam analysis system which receives reports from individual message centers, and in return, instructs the message centers with filtering criteria and policy rules which are developed based on spam reporting as well as spam analysis at the spam reporting server. This document introduces a new operation of anti-spam policy instruction and distribution between a centralized spam reporting server and distributed spam reporting clients. Optionally, a spam reporting client could also act as an agent to distribute the received anti-spam policy instruction to other spam reporting clients in the network. This document, thus, creates a framework for anti- spam policy instruction and distribution among the distributed spam reporting nodes in the network. The spam policy instruction operation from the centralized spam reporting server will allow one or multiple spam reporting clients, which actually conduct spam filtering and detection, to: o have latest spam filtering criteria and policies instructed by the networks o receive spam filtering and detection algorithms and rules from other spam reporting clients via the centralized spam reporting server o update and enhance existing local filtering algorithms and rule o prevent in advance from upcoming spam with new abuse contents and/or from new sources o optionally, further distribute the received policies to other spam reporting clients in its network 2. Definitions Cai, et al. Expires August 27, 2011 [Page 4] Internet-Draft Anti-Spam Operation February 2011 2.1. 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 RFC 2119 [RFC 2119]. 2.2. Definitions Spam Reporting Server - The functionalities of a spam reporting server includes receiving spam reports from spam reporting clients, conducting spam analysis, summarizing anti-spam criteria/policies/ rules, and distribution of anti-spam criteria/policies/rules to the distributed spam reporting clients. Spam Reporting Client - It is message center (SMSC, MMSC, email server, IM server, etc.) The functionalities of a spam reporting client includes detecting spam messages using local spam filtering criteria/rules, reporting spam messages to Spam Reporting Server, receiving the instruction of anti-spam policies/rules from Spam Reporting Server, and optionally receiving/forwarding the anti-spam policies/rules from/to other Spam Reporting Clients. 3. Anti-spam Policy Instruction/Distribution Procedures The procedures support both of unsolicited and solicited models of anti-spam policy instruction/distribution. In unsolicited model, the spam reporting server shall initiate a request for spam policy instruction/distribution operation to one or more spam reporting clients which conduct spam message filtering and detection in the network. A spam reporting client may initiate a request for spam policy instruction/distribution operation to one or multiple other spam reporting clients in the network. In solicited or on-demand model, a spam reporting client shall initiate a on-demand request for spam policy instruction/distribution operation to the spam reporting server. The spam reporting client shall indicate what filtering criteria/policy rules it current has, and what new policy rules it may expect and subscription time window. The spam reporting server or spam report client that received the on- demand query request shall respond to the requesting entity with anti-spam policy instruction and/or appropriate result code. Optionally, asynchronous mechanism can be implemented where the anti- spam policy instruction is sent as a separate request after acknowledging the receipt of the query request from the client. In both solicited and unsolicited models, the spam reporting clients Cai, et al. Expires August 27, 2011 [Page 5] Internet-Draft Anti-Spam Operation February 2011 who received the request of spam policy instruction/distribution operation shall respond to the requesting entity with corresponding result codes. 3.1. Operation Procedure for Unsolicited Policy Instruction/ Distribution This procedure enables the push model for anti-spam policy instruction/distribution. Related procedures, described in section 3.2, provide control to subscriber/unsubscribe this push mechanism for specific spam reporting client(s) in the network. The spam reporting server shall initiate a request for spam policy instruction/distribution operation to one or more spam reporting clients which conduct spam message filtering and detection in the network. A spam reporting client shall initiate a request for spam policy instruction/distribution operation to one or multiple other spam reporting clients in the network. The spam reporting clients who received the request of spam policy instruction/distribution operation shall respond to the requesting entity with corresponding result codes. +-------------+ +-------------+ | | Request | | | |<----------------| | | Client | Response | Server | | |---------------->| | +-------------+ +-------------+ +-------------+ Request +-------------+ | |<----------------| | | | Response | | | Client |---------------->| Client | | | | | +-------------+ +-------------+ 3.1.1. Server Procedure The procedures described below are performed by Spam Reporting Server. 1. Before sending the request to the clients, the server shall determine Cai, et al. Expires August 27, 2011 [Page 6] Internet-Draft Anti-Spam Operation February 2011 * which spam filtering criteria/policies/rules should be included in the operation * which clients should receive these spam filtering criteria/ policies/rules * schedule (day and time) to send the request to client(s). The schedule can be provisioned statically or determined during run time. 2. The server shall assemble the request message, for anti-spam policy instruction/distribution, with message elements described in Section 4.1.1. 3. The server shall send the assembled request to identified spam reporting client(s) as per the selected schedule 4. The server shall receive the response from the client(s). The server shall determine whether to resend the request to the client(s) in case of an error result code received from client(s) 5. Re-attempt of distribution to a client shall be determined based on error code, client ID, and spam filtering criteria/policies/ rules 6. Times and interval for re-attempt of distribution can be statically configured at the server or determined automatically 3.1.2. Client Procedure The procedures described below are performed by Spam Reporting Client when receiving a request message for spam policy instruction/ distribution operation from Spam Reporting Server or other Spam Reporting Clients. 1. The client shall parse the request and extract the message elements enclosed in the request 2. The client shall process the content of message elements and take appropriate action including one or more of the following: * Accept a part or all of the filtering criteria/policies/rules included in the request * Ignore a part or all of the filtering criteria/policies/rules included in the request Cai, et al. Expires August 27, 2011 [Page 7] Internet-Draft Anti-Spam Operation February 2011 * Update existing filtering criteria/policies/rules with the accepted ones from the request * Activate new filtering criteria/policies/rules immediately or at a later time as determined by the client 3. The client shall send a response to the requesting entity with appropriate result codes (see Section 4.1.2) When there is a need for the spam reporting client to forward the request for spam policy instruction/distribution operation to other spam reporting client(s) in the network, the spam reporting client shall follow the procedure outlined for the server in section 3.1 above. 3.2. Operation Procedure for Notification to Subscribe/Unsubscribe Anti-Spam Policy Instruction/Distribution This procedure enables control to enable/disable the push mechanism, described in section 3.1, selectively by specific spam reporting client(s) in the network. The spam reporting client(s) may initiate a request to subscribe/ unsubscribe receiving spam policy instruction/distribution requests from a spam analysis server or another spam reporting client. The spam analysis server or spam reporting client that received the request to subscribe/unsubscribe anti-spam policy instruction shall respond to the requesting entity with corresponding result code. +-------------+ +-------------+ | | Request | | | |---------------->| | | Client | Response | Server | | |<----------------| | +-------------+ +-------------+ +-------------+ Request +-------------+ | |---------------->| | | | Response | | | Client |<----------------| Client | | | | | +-------------+ +-------------+ Cai, et al. Expires August 27, 2011 [Page 8] Internet-Draft Anti-Spam Operation February 2011 3.2.1. Client Procedure The procedures described below are performed by a spam reporting client. 1. The client shall assemble the request message, to subscribe/ unsubscribe anti-spam policy instruction/distribution, with message elements described in Section 4.2.1 2. The client shall send the assembled request to identified entities, i.e., the spam reporting server and/or other spam reporting client(s) 3. The client shall receive the response from the entities to which the request was sent. The client shall determine whether to resend the request in case of an error result code received. 4. Times and interval for re-attempt of notification to subscribe/ unsubscribe anti-spam policy instruction/distribution can be statically configured at the client or determined automatically When the spam reporting client is also capable of spam policy instruction/distribution to other spam reporting clients, the spam reporting client shall support the server procedure described in section 3.2.2 below. 3.2.2. Server Procedure The procedures described below are performed by the spam reporting server when receiving a request message to subscribe/unsubscribe anti-spam policy instruction/distribution to the client. This procedure is also executed by a spam reporting client if it is capable of spam reporting policy instruction/distribution in which case the spam reporting client is fulfilling the server role for this operation. 1. The server shall parse the request and extract the message elements enclosed in the request 2. The server may extract existing policy IDs from the request as a base of appropriate actions. For example, if there is no new policy rule to be sent to the spam reporting client, the spam reporting server should send an appropriate result code (Section 6) to the spam reporting client; the spam reporting server may not send a policy instruction/distribution request to the spam reporting client in the period while no new policy rules applied, even the policy instruction/distribution status of the spam reporting client is recorded as subscribed Cai, et al. Expires August 27, 2011 [Page 9] Internet-Draft Anti-Spam Operation February 2011 3. The server shall process the content of message elements and take appropriate action including one of the following: * Start anti-spam policy instruction/distribution to the client, which sent the request, at the next scheduled event for anti- spam policy instruction/distribution * Stop subsequent anti-spam policy instruction/distribution to the client that sent the request 4. The server shall send a response to the requesting entity with appropriate result codes (see Section 6) 3.3. Operation Procedure for On-Demand of Anti-Spam Policy Instruction This procedure enables the on-demand pull model for anti-spam policy instruction/distribution. The spam reporting client(s) may initiate a request to query spam policy instruction/distribution on-demand from a spam reporting server or another spam reporting client. The spam reporting server or spam report client that received the on- demand query request shall respond to the requesting entity with anti-spam policy instruction and/or appropriate result code. Optionally, asynchronous mechanism can be implemented where the anti- spam policy instruction is sent as a separate request after acknowledging the receipt of the query request from the client. The flow for the synchronous mechanism is depicted here. +-------------+ +-------------+ | | Request | | | |---------------->| | | Client | Response | Server | | |<----------------| | +-------------+ +-------------+ +-------------+ Request +-------------+ | |---------------->| | | | Response | | | Client |<----------------| Client | | | | | +-------------+ +-------------+ Cai, et al. Expires August 27, 2011 [Page 10] Internet-Draft Anti-Spam Operation February 2011 The flow for the asynchronous mechanism includes the flow depicted above, except that the response is an acknowledgement of the query instead of policy instruction, followed by the anti-spam policy instruction/distribution flow depicted in section 3.1 above. 3.3.1. Client Procedure The procedures described below are performed by a spam reporting client. 1. The client shall assemble the request message, to query anti-spam policy instruction, with message elements described in section 4.3.1. 2. The client shall send the request to identified entities, i.e., the spam reporting server and/or other spam reporting client(s) 3. The client shall receive the response from the entities to which the request was sent. The client shall determine whether to resend the request in case of an error result code received 4. Times and interval for re-attempt of the query request for anti- spam policy instruction can be statically configured at the client or determined automatically When the spam reporting client is also capable of spam policy instruction/distribution to other spam reporting clients, the spam reporting client shall support the server procedure described in section 3.3.2 below 3.3.2. Server Procedure The procedures described below are performed by the spam reporting server when receiving a request message for query of anti-spam policy instruction from a client. This procedure is also executed by a spam reporting client if it is capable of spam reporting policy instruction/distribution in which case the spam reporting client is fulfilling the server role for this operation. 1. The server shall parse the request and extract the message elements enclosed in the request 2. The server may extract existing policy IDs from the request as a base of appropriate actions. For example, if there is no new policy rule to be sent to the spam reporting client, the spam reporting server should send a response with an appropriate result code (Section 6) but without policy body to the spam reporting client Cai, et al. Expires August 27, 2011 [Page 11] Internet-Draft Anti-Spam Operation February 2011 3. The server shall process the content of message elements and take appropriate action depending on whether the query mechanism is synchronous or asynchronous * If the query mechanism is synchronous, the server shall assemble a response message enclosing the spam policy instruction and/or result code (see section 6) as specified in section 4.3.2. * If the query mechanism is asynchronous, the server shall assemble a response message containing the result code (see section 6) to acknowledge the query request 4. The server shall send the assembled response to the requesting entity 4. Messages This section specifies the format of the request and response messages to support the operation procedures described in section 3 above. 4.1. Anti-Spam Policy Instruction/Distribution Messages There are two types of messages of anti-spam policy instruction/ distribution operation: o Request message (sent by either Spam Reporting Server or Spam Reporting Clients) o Response message (sent by Spam Reporting Clients) 4.1.1. Request Message The request message of anti-spam policy instruction/distribution operation should contain following message elements: Request: Request ID Request timestamp Originating node address Cai, et al. Expires August 27, 2011 [Page 12] Internet-Draft Anti-Spam Operation February 2011 Terminating node address * Policy Body { Policy ID Network types * Protocol ID * Message Types Message attributes * Suspicious network domain * Suspicious address * Suspicious address type Spam type Language indicator Detection information { * Algorithm ID * Rule ID * Spam Keyword * Spam Pattern } Action information { Block with notification Cai, et al. Expires August 27, 2011 [Page 13] Internet-Draft Anti-Spam Operation February 2011 Block without notification Unblock and deliver Hold and quarantine } Privacy shield information Affective filtering start timestamp Affective filtering stop timestamp } * sign indicates the message element should be multiple occurrences. 4.1.2. Response Message The response message of anti-spam policy instruction/distribution operation should contain following message elements: Response: Request ID Request received timestamp Response timestamp Originating node address Terminating node address Result Code * Policy Specific Result Code { Policy ID Result Code Cai, et al. Expires August 27, 2011 [Page 14] Internet-Draft Anti-Spam Operation February 2011 } * sign indicates the message element should be multiple occurrences. 4.2. Notification to Subscribe/Unsubscribe Anti-Spam Policy Instruction/Distribution There are two types of messages for operation for the notification to subscribe/unsubscribe anti-spam policy instruction/distribution. o Request message (sent by spam reporting clients) o Response message (sent by spam analysis server or spam reporting client) 4.2.1. Request Message The request message for notification to subscribe/unsubscribe anti- spam policy instruction/distribution operation shall contain following message elements: Request: Request ID Request timestamp Originating node address Terminating node address Anti-Spam Policy Instruction Control { InstructionAction *Existing Policy IDs } * sign indicates the message element should be multiple occurrences. 4.2.2. Response Message The response message for the notification operation to start/stop anti-spam policy instruction/distribution should contain following message elements: Cai, et al. Expires August 27, 2011 [Page 15] Internet-Draft Anti-Spam Operation February 2011 Response: Request ID Request received timestamp Response timestamp Originating node address Terminating node address Result Code 4.3. On-Demand Query of Anti-Spam Policy Instruction There are two types of messages for operation to query anti-spam policy instruction/distribution. o Request message (sent by spam reporting clients) o Response message (sent by spam analysis server or spam reporting client) In addition when the asynchronous query mechanism is used, the request and response messages specified in section 4.1 shall be used for the asynchronous anti-spam policy instruction/distribution. 4.3.1. Request Message The request message for the operation to query of anti-spam policy instruction should contain following message elements: Request: Request ID Request timestamp Originating node address Terminating node address Anti-Spam Policy Instruction Control Cai, et al. Expires August 27, 2011 [Page 16] Internet-Draft Anti-Spam Operation February 2011 { InstructionAction *Existing Policy IDs } * sign indicates the message element should be multiple occurrences. 4.3.2. Response Message The response message for the notification operation to start/stop anti-spam policy instruction/distribution should contain following message elements: Response: Request ID Request received timestamp Response timestamp Originating node address Terminating node address Result Code * Policy Body { Policy ID Network types * Protocol ID * Message Types Message attributes * Suspicious network domain Cai, et al. Expires August 27, 2011 [Page 17] Internet-Draft Anti-Spam Operation February 2011 * Suspicious address * Suspicious address type Spam type Language indicator Detection information { * Algorithm ID * Rule ID * Spam Keyword * Spam Pattern } Action information { Block with notification Block without notification Unblock and deliver Hold and quarantine } Privacy shield information Affective filtering start timestamp Affective filtering stop timestamp } * sign indicates the message element should be multiple occurrences. Cai, et al. Expires August 27, 2011 [Page 18] Internet-Draft Anti-Spam Operation February 2011 5. Message Element Descriptions Message elements included in the request and response messages of anti-spam policy instruction/distribution operation are described in this sub-section. All message elements are optional except those that are indicated as mandatory. 5.1. Request ID Request ID is a mandatory element of type string and is the unique identifier for the request message. 5.2. Request Timestamp Request timestamp is a mandatory element of type Time and holds the time the request message was originated by the originating node. 5.3. Request Received Timestamp Request received timestamp is a mandatory element of type Time and holds the time the request was received by the terminating node. 5.4. Response Timestamp Response timestamp is a mandatory element and of type Time and holds the time the response was sent by the terminating node. 5.5. Originating Node Address Originating node address is a mandatory element of type String and includes the originator address. It should be the address of Spam Reporting Server or Spam Reporting Client. 5.6. Termination Node Address Terminating node address is a mandatory element of type String and includes the recipient address. It should be the address of Spam Reporting Server or Spam Reporting Client. 5.7. Policy Body Policy body is a mandatory element of type Group and includes the policy elements. 0 or more policies can be included in the policy body. At least one policy must be present in the anti-spam instruction/distribution request message. Cai, et al. Expires August 27, 2011 [Page 19] Internet-Draft Anti-Spam Operation February 2011 5.8. Policy ID Policy ID is a mandatory element of type Integer and is the unique identifier for this policy. 5.9. Network Type Network type is of type Enumerated and is the indicator for the network types: GSM, UMTS, LTE, 3GPP, CDMA, other, unknown, etc. 5.10. Protocol ID Protocol ID is of type Enumerated and is the indicator for the message protocol applicable for the policy: SMTP, SMPP, 3GPP MAP, 3GPP SIP, 3GPP2 SIP, ANSI SMDPP, etc. 5.11. Message Type Message type is of type Enumerated and is the indicator for the message types: email, SMS, MMS, IM, etc. 5.12. Message Attributes Message attribute is of type Data Structure and contains additional information about message applicable to the policy. The attributes depend on message types. Each message type has its own set of attributes. 5.13. Suspicious Network Domain Suspicious network domain is of type String. It includes the domain name of the network which is considered suspicious or bad. 5.14. Suspicious Address Suspicious address is of type String and includes the address which is considered suspicious or bad. 5.15. Suspicious Address Type Suspicious address type is of type String and is an indicator of type of suspicious address, IP address, mobile number (MSISDN, IMSI), email address, etc. 5.16. Spam Type Spam type optional field is of type Enumerated and includes the spam types: Cai, et al. Expires August 27, 2011 [Page 20] Internet-Draft Anti-Spam Operation February 2011 o Spam o Phishing o Spoofing o Malware (e.g., virus/spyware) o Fake sender address o Miscategorized 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 Invalid message format o Not Spam 5.17. Language Indicator Message language indicator is of type Integer and is the indicator of the message language. 5.18. Detection Information Detection information is of type Structure and contains the information on the algorithms or method used to screening/filter the spam messages: o Algorithm ID o Rule ID o Spam Keyword o White/black list Cai, et al. Expires August 27, 2011 [Page 21] Internet-Draft Anti-Spam Operation February 2011 o Spam Pattern Match o Volume threshold per sender match o Volume threshold per sending network/domain match o Others 5.19. Action Information Action information is of type Enumerated and followings: o Block with notification o Block without notification o Unblock and delivering o Hold and quarantine o Others 5.20. Privacy Shield Information Privacy shield information is of type Structure and contains privacy shield and sharing instruction. 5.21. Affective Filtering Start Timestamp Affective filtering start timestamp is of type Time and holds the time the policies included in the request should start to affect. 5.22. Affective Filtering Stop Timestamp Affective filtering start timestamp is of type Time and holds the time the policies included in the request should stop to affect. 5.23. Result Code Result Code is a mandatory element of type Integer and holds processing return result from the receiving node (see details in Section 6). 5.24. Anti-Spam Policy Instruction Control Anti-Spam Policy Instruction Control is of type Grouped. It includes information on the action requested by the client and information on any existing policy IDs that the client already has. Cai, et al. Expires August 27, 2011 [Page 22] Internet-Draft Anti-Spam Operation February 2011 5.25. InstructionAction ActionInstruction is of type enumerated and can have any of these values: SubscribeInstruction, UnsubscribeInstruction, ImmediateInstruction. 5.26. Existing Policy IDs Existing Policy IDs is list of policy IDs that the client already has. This is useful for SubscriberInstruction and ImmediateInstruction option. 6. Result Codes The receiving node shall include appropriate return code in the response message to the sending node for policy instruction/ distribution operation. This section provides unexhausted result codes. 6.1. Normal Return Codes 200 OK Receiving node accepted the request and there was no new policy to apply 202 Accepted Receiving node accepted the request and there was no problem parsing the request 212 Applied Received policies have been applied in the Spam Reporting Client for scheduled spam filtering and detection 6.2. Error Return Codes 400 Bad request The request format and content could not be understood 401 Unauthorized The sending node is not authorized to send policy instruction/distribution request to the receiving node 406 Not Acceptable The policies received in the request are not acceptable 409 Conflict The request is conflict with existing policy rules 420 Unsupported Network Type Network type is not supported at receiving node Cai, et al. Expires August 27, 2011 [Page 23] Internet-Draft Anti-Spam Operation February 2011 421 Unsupported Spam Type Spam type is not supported at receiving node 422 Unsupported Message Type Message type is not supported at receiving node 480 Temporarily Unavailable The receiving node is temporarily unavailable 500 Internal System Error The receiving node has internal system error 503 Service Unavailable The receiving node is unavailable for the requested service 7. Protocols The request and response messages specified for the anti-spam policy instruction/distribution framework operations specified in this document shall be communicated via a transaction protocol. A sending node should initiate each transaction by sending an RFC 2616 [RFC 2616] HTTP POST message to the URI of receiving node. The body of this HTTP request shall contain the request message content specified in section 4. After receiving and processing the HTTP POST request, the receiving node shall respond with an RFC 2616 [RFC 2616] HTTP response. The body of this HTTP response shall contain the response message content specified in section 4. The XML schema for the request and response message content is to be specified following agreement on the message elements proposed in this document. 8. IANA Considerations None. 9. Security Considerations TBD Cai, et al. Expires August 27, 2011 [Page 24] Internet-Draft Anti-Spam Operation February 2011 10. Acknowledgements The authors thank Igor Faynberg for his invaluable help with preparing this document. 11. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC 2616] 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. [RFC 5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010. [OMA TS SpamRep] "Mobile Spam Reporting Technical Specification", October 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 Cai, et al. Expires August 27, 2011 [Page 25] Internet-Draft Anti-Spam Operation February 2011 Sanjeev K. Singh Alcatel-Lucent 6200 E. Broad St Columbus, OH 43213 USA Phone: +1 614 367 5825 Email: Sanjeev.Singh@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 August 27, 2011 [Page 26]