Spam System Requirements

I. Introduction

This document outlines the requirements for the spam system as it will be implemented in ACS version 4.0. Previous version of ACS included a spam feature, and the spam system in ACS 4.0 will support the same functionality as ACS 3.4 with the following enhancements:

• Administrators will send spam to groups of users using the same code and pages as non-administrators sending spam to other group members. (In ACS 3.4, these two usage scenarios are carried out by different sets of pages.)

II. Vision Statement

The ACS Spam system provides a mechanism for sending mass e-mail to groups of users and viewing the history of these messages sent. It will be built using the existing ACS Messaging system, which stores message content in the Content Repository.

System Overview

• An API for selecting groups of users as spam recipients
• Pages for entering spam text
• A mail-merge feature, for filling in each recipient's name or e-mail address in the message text
• Administration pages for viewing previously-sent spam

IV. Use-cases and User-scenarios

1. Site-wide or subsite administrators use the spam system to send e-mail to groups of users
2. Package administrators use the spam system to send e-mail to groups of users based on some criteria within their package; for example, a bboard administrator might send spam to all people who've posted more than 30 messages within the last week, or an event administrator might send e-mail to all users who registered for the event.
3. Site users might use the spam system to send e-mail to other users within their group, only if the subsite administration allows non-administrators to initiate spam.

An administrator uses the spam system to send e-mail to a group of users, following these steps:

1. Pick a group of users to receive a mass e-mailing
2. Draft the e-mail
3. View the text as it will appear to the recipient
4. Confirm it
5. The message is queued for delivery.

This scenario is identical for site-wide, subsite, and and package administrators, with the exception that package admins will only be able to select groups of users based on criteria related to their package, and not from the site/subsite at large.

Spam sent by users

Users who are not administrators can also use the spam system, but they can only send spam to other members of their group(s), and only if the group administrator allows non-administrators to send spam. The group administrator may set a spam moderation policy, so that spam sent by a user will not be sent until an administrator confirms or approves it.

Viewing spam history An administrator can view the history of spam messages sent by other administrators or users. This will also show the status of messages that have already been sent, but were not sent successfully (e.g., because of network problems or addresses that bounce).

V. Related Links

• ACS Messaging

VI. Requirements

• 10.0 Pick a group of users as spam recipients

  Picking a group of recipients is always the first step in sending a spam.

  10.10 There must be an API for selecting a group of users programmatically, so that an application that uses the spam system can present the option to spam a pre-chosen list of users.

  10.20 Subsite administrators should be able to spam any user group in the GROUPS table for their subsite.

  10.25 Site-wide administrators may spam any user group in the GROUPS table for any subsite, or supply an arbitrary SQL query for selecting a group of users from the USERS or PARTIES tables directly.

  10.30 Users who are not administrators may send spam to a user group in the GROUPS table, but only if they are members of that group and the group administrator specifies that non-administrators may send spam.

  10.30.10 Group and subsite administrators should be able to specify that, when a regular (non-admin) user sends spam to his group members, the spam is not sent immediately, but delayed until confirmed by an administrator.

• 20.0 Sending the e-mail

  20.10 The spam system shall provide a standard mechanism for drafting mass e-mail.

  20.20 The spam system shall allow the sender to specify a time in the future to send the e-mail, so that spam may be sent on a delay

  20.30 The spam system shall provide a "mail-merge" feature, with which the sender may specify fields to be filled in appropriately for each recipient.

  20.30.10 These fields shall include, but are not limited to the recipients'

  • e-mail address
  • name

• 30.0 Viewing spam history

  30.10 Site-wide and subsite administrators should be able to view a history of spam messages sent, and view/confirm those that are pending.

  30.20 Administrators may view a history of previously-sent spam messages, along with any error conditions that were recorded during the send.