CCC Home --> Meetings --> Minutes --> Meeting Notes: September 9, 1998 11:00 am
Minutes from the Mass Email Architecture meeting
September 9, 1998 11:00 am
Attending:
- Don Worth (AIS)
- Julius Kelly (Academic Senate)
- Pete Nielsen (OAC)
- Jack Ewart (AIS)
- Mike Van Norman (CTS)
- Bonnie Mika (CTS)
- Michael Stone (University Communications)
Don handed out a matrix with four possible quandrants to consider:
- - Informational emails to everyone
- - Informational emails to some people (e.g. faculty, L&S students, etc.)
- - Urgent emails to everyone
- - Urgent emails to some people
Don suggested that we might want a phased approach that takes cover of #1 first (to address
recent complaints from some faculty that the BOL bulletins don't reach them) and supports the rest
in the order presented. It isn't clear whether #4 is needed or not - however, it's possible that
the Faculty Senate may want to reach their members immediately to announce schedule changes in
their meetings or some such. We'll keep it in mind.
Pete provided an overview of what OAC has been offering to date. Two mechanisms are
available:
1 - BOL Bulletin system. Delivers a message to each BOL user who uses POP or Pine. Does not work
for BOL accounts that are forwarded to external email accounts. There is no way to use the bulletin
system to send emails to subsets of accounts on BOL.
2 - For smaller announcements (usually to ad-hoc lists of email addresses) OAC can send out
emails with one to two second intervals - metered or paced. This seems not to overload campus email
gateways. This is more difficult for very large mailings since it can take a very long time to
deliver 50,000 emails with 1 second between each!
The Registrar provides lists of email addresses for students to depts who pay them about $90.
AIS uses the metered method for Billing & Receivables EFT notices as well.
There was some discussion about where the system should go to get "everyone's email address"
Mike noted that the campus directory does not include the email addresses of all staff. The "book
of record" for student email addresses is the Student Records System (SRS) since students can
update it there using Ursa OnLine. A similar setup is expected in the next few months for staff
email addresses. Employee Self Service is being developed by UC Systemwide which will allow
employees to update their email address of record in the Payroll/Personnel system. At that point,
PPS will be the book of record for employee email addresses. It was noted that QDB currently
contains email addresses for students and staff (from the campus directory). It may be appropriate
to use QDB to build lists (at least for now) since changes in the book of record location will not
affect its users. Also, QDB has demographic information that could be useful to constructing
lists.
Mike Van Norman briefly outlined the plans for CTS's rearchtecting BOL. The new system will
offer greater flexibility in storing email. A database will be used instead of UNIX SENDMAIL. It
will be possible to store a single copy of a message for mulitple recipients.
A number of possible options were discussed for addressing the short term problem - that not all
faculty are receiving bulletins sent by the Chancellor, etc. One possible approach would be to
create a list of all forwarded accounts in BOL and, whenever a bulletin was posted, send it also to
that list using the metered method. This forwarded list could be built only once a week at low
priority. Mike offered to construct the necessary script to do it. The list could be as large as
5,000 entries.
Another, simpler, approach would be to construct a LISTSERV, initially empty and allow
self-subscriptions. Anyone who complained of not getting bulletins could subscribe to the LISTSERV.
Whenever a bulletin went out it would also be sent to the LISTSERV. There was some disagreement
over whether the existance of the LISTSERV should be advertised or not. On the one hand, faculty
are annoyed when they find out they've been missing notices that they really wanted to see - so we
may need to warn them in advance. On the other hand, if the LISTSERV is used too widely, it may be
difficult to remove it when we are ready to replace it. And, it provides a way for people to "opt
out" - not receive any broadcasts. Policy may not permit this in a later implementation.
Consensus seemed to be that we should provide the LISTSERV and send one metered email to
everyone in the campus directory suggesting that they subscribe to it if they do not use Bruin
OnLine as their primary email system. The same announcement can say that this is a temporary
measure until we can develop something permanent.
Mike suggested a longer-term architecture based on the concept of providing aliases to entire
departmental email systems. Whenever a broadcast was to go out, it would be sent to the list of all
campus email addresses (from the directory, Student Records, QDB or whereever.) Departments who
have a lot of email recipients could provide an alias such as "all@sscnet.ucla.edu" that would
explode a single copy of an email to every account on their system (using either a LISTSERV or a
bulletin feature.) All other emails (to individual recipients for which there is no departmental
alias to cover them) would be "metered" out so as not to overload mail gateways.
Additional variables might be whether a message was mandatory or optional - ie. could the
recipient choose to "opt out" and not receive it, or will it be delivered not matter what. Another
would be whether the message is urgent or informational. It's possible that "urgent" implies
mandatory, however informational could be either mandatory or optional.
In discussing the issue of "opting out" it was decided that this ought to be referred to the
Policy group. However, it may be inappropriate to provide filtering within the delivery system. A
better approach could be to insert standard keywords in the message header that can be used by
client-side filters to delete unwanted emails.
It was noted that Mike's solution will result in duplicate emails in some cases. For example, if
someone primariliy uses Bruin OnLine for their email, but also has a departmental email account
that forwards to their Bruin OnLine account, they will get two emails unless they can talk their
department into taking them off the "all" list.
The final discussion centered on whether or not it is even necessary to spoon feed (meter)
departmental email gateways anymore. Most seem much more robust, and the ones with very large
numbers of recipients (such as Bruin OnLine) may be able to handle un-metered innundations now. If
this is the case, it may not be necessary to design a different system for urgent delivery than for
informational delivery.
If this is the case, we may simply design a system that sorts the recipient list by email
domain, and then delivers emails to those systems in blocks of 25, metering the delivery according
to preestablished "tuned" intervals. Since the vast majority of addresses are likely to be Bruin
OnLine, and we can count on BOL to take delivery as fast as we can deliver it, the number of
messages that need to be metered could be small. It was agreed that this would be the recommended
approach. Mike noted that such a service could be implemented on a moderately sized Pentium II
Intel server.
Don agreed to draft a strawman proposal along these lines for review by the group. Yet to
decide: costs (staff & equipment), who would be responsible for what parts, implementation
schedule.
Don will call another meeting once the draft is ready.
|
