Rutgers Automated Mass-mailing System
List operator's guide
The Rutgers Automated Mass-mailing system (RAMS), is really a conglomeration of databases, web-based applications, and automated processes designed to deliver mass-mailings via e-mail to portions of the Rutgers population based on demographic information. The web-based applications allow you to (in some cases) create mailing lists, manage your mailing lists, and to view the archives and statistical information about your lists. As someone who operates a list, these are the parts of RAMS that most concern you, and thus more detailed documentation has been provided on them. However, it's still probably a good idea to have some idea of what makes the whole thing tick.
The databases are really the guts of the system, and if they don't work, nothing else in the system will. There are two databases used by RAMS. One gathers information from a various other university databases and condenses it to one local database. This is done primarily to avoid issues with maintenance hours on other systems conflicting with the hours that are best for sending out bulk mailings. This database is updated daily. The other database contains all the information for the mailing lists. When a message goes out for a list, RAMS looks up the rules for the list in this database, and uses the rules to compose the address list from the first database.
The web-based applications provide 99% of the user interface for RAMS. They basically update information in the list database, and trigger actions or automated processes. The important thing to remember is that they interact with the database in real time. If it looks changed, it is changed.
The automated processes do all the grunt work that keeps RAMS functioning. The daily database dumps keep the demographic information fresh. The daily backup preserves the list information. The RAMS daemon fields incoming postings. And the prime-time process runs every hour to kick off mailings that are pending prime-time.
Life-cycle of an e-mail
The following is an illustrative example of what happens in RAMS when a message is posted to a list.
If the list is an open list (i.e. anyone can post to it). You send the message which is received by the mail server on the host system. The mail server hands it over to the RAMS daemon. The daemon parses it and checks if the list actually exists. If the list exists, it checks if it has a prime-time restriction on it. If there is no prime-time restriction or the mail arrives at a time when it is allowed to be broadcast, it posts the message, and the process is complete. If there is a prime-time restriction, the mail is put in the prime-time queue to be processed when it is within the lists scheduled prime-time.
If the list is a closed list, the process is the same except that the RAMS daemon also checks to see if the sender of the message is a member of the list in question. If they are it proceeds as described for an open list. If they are not, it sends them an error message, and the process is complete.
If the list is a moderated list, then the process is a fair amount different. First the mail is received by the mail server. Then it hands the message off to the RAMS daemon. The rams daemon queues a copy of the message in the moderation queue, and then appends another copy to a confirmation request sent to all the moderators. A moderator may reply via e-mail to approve the message for posting or they may approve it via the list editor. If they approve it by e-mail, the reply is sent to the mail server, handed off to the RAMS daemon, the moderation queue is checked for the message, and if it is there, it either sends it out or pushes it to the prime-time queue as appropriate for the list. If approved via the web application, the application checks the prime-time restrictions, and either sends the message out or pushes it to the prime-time queue to be sent out later. Once the message is sent, the process is complete. Once one moderator approves a message, it will no longer appear available for moderation in the web application, and any further attempts to confirm by e-mail will generate error messages.
What do I need to do to operate my list?
Your responsibilities depend on the type of list you have. The types of lists and common tasks associated with running a list of that type are presented below.
OPEN LIST: Open lists will only have owners. They do not require much oversight, so the only real tasks you will perform as owner are adding members not selected by demographic criteria, removing any added members or any members included by demographic criteria that you feel should be removed, and prohibiting postings from specified addresses. Anyone can post to an open list unless they have been specifically prohibited.
CLOSED LIST: Closed lists will only have owners. They do not require much oversight, so the only real tasks you will perform as owner are adding members not selected by demographic criteria, removing any added members or any members included by demographic criteria that you feel should be removed, and prohibiting postings from specified addresses. Only members of a closed list may post to the list.
MODERATED LIST:Moderated lists may have both moderators and owners. Moderators can approve messages via the mail interface, or via the web interface. Owners can approve messages through the web interface only since they will not get the confirmation message in e-mail if theya re not also moderators for the list. Owners will also carry out the tasks described for open and closed lists above. Anyone can submit a message for approval to a moderated list, but only approved messages are posted. All messages require approval before posting, including those submitted by moderators or owners.
Tips, hints, warnings and other useful facts.