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 described in the Simplified BSD License.

Table of Contents

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:

2. Definitions

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 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

  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:

  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    |
  |             |                 |             |
  +-------------+                 +-------------+

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
  3. The server shall process the content of message elements and take appropriate action including one of the following:

  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

 
 
   +-------------+                 +-------------+
   |             |   Request       |             |
   |             |---------------->|             |
   |   Client    |   Response      |   Server    |
   |             |<----------------|             |
   +-------------+                 +-------------+


   +-------------+   Request       +-------------+
   |             |---------------->|             |
   |             |   Response      |             |
   |   Client    |<----------------|   Client    |
   |             |                 |             |
   +-------------+                 +-------------+

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.



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
  3. The server shall process the content of message elements and take appropriate action depending on whether the query mechanism is synchronous or asynchronous

  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:

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
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
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
}

* 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.

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:

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.

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
{
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
* 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.

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.

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:

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:

5.19. Action Information

Action information is of type Enumerated and followings:

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.

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

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

10. Acknowledgements

The authors thank Igor Faynberg for his invaluable help with preparing this document.

11. 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
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