Documente Academic
Documente Profesional
Documente Cultură
Overview
Course Student Requirements
Mail to Course Students -- Authoring
Mail to Course Students -- Sending
Mail from Course Students -- Receiving
Marketing Mails Requirements
Mail to Marketing Lists -- Authoring [P1]
Mail to Marketing Lists -- Sending [P1]
Mail from Marketing Lists -- Receiving [P1]
Operation Requirements
Non-Requirements
Open Issues
Overview
The high-level feature is enabling professors (and their staff) to send rich email to the students
in their class. Weve found that frequent mails is one of the best ways to keep students
engaged. Other platforms support this, and so profs have come to expect that they can email
everyone.
Class2Go supported this feature, so in many ways this first cut is porting over the feature that
we had implemented there. See screenshot from Class2Go showing that interface, for
reference.
This document covers two distinct use cases. The first one, and most important, is for the
course staff to mail the students directly. Thats the P0. Its also valuable to send a marketing
email to an arbitrary list of students. Thats a P1 feature. It will eventually share much of the
same plumbing, but has differences in authoring, sending, and mail format, so those
requirements are called out separately in this doc. Marketing emails will come in a subsequent
release.
All requirements are P0 unless noted otherwise.
million entries. Creating a list that large should take minutes, not hours.
21. [P1] As course operations I want a UI to initiate sending a mail to a mail list.
(needs more detail)
22. [P1] As a student, if I opt out of one marketing email, I want that to be respected
for subsequent marketing emails. Not course opt-outs though, those are per-course and
non-global.
Operation Requirements
25. There should be a configurable list (per-site) with the list of approved domains
that you can send mail from. Verifying a domain is sufficiently heavyweight (dkim
records, etc.) that this will be done manually. This list is for verification.
26. [P1] As OpenEdX technical operations Id like to be notified if we get failures from
SES due to hitting thresholds, either instantaneous rate limits or daily limits.
27. As OpenEdX technical operations, celery workers cant be clogged up by mail
send failures.
The retry logic has to handle the case where we have other jobs
queued up, but mail cannot be processed (connectivity issues to SES, hitting
thresholds). So failed jobs need to be requeued instead of just blocking the
worker in a retry loop.
An alternate way to satisfy this requirement is to isolate the mail
queue so that only mail failures are handled on that queue. That way, if there is a
blocked queue, it will affect all mails, but only mails. This is OK since we only
need to retry global mail failures (cant send **any** mails) and not per-email
failures. For example, if an individual mail is invalid, that should just fail, not retry
28. [P1] If we treat the mail as a template then we need to take care that theres
nothing the author can do with the templating langugage that would cause security or
availability problems.
Non-Requirements
Difference Between This and Forum Notifications
The forum team is building a notification system that uses mailgun as its MTA. This seems like
duplicated efforts. But as I discussed with Jim it seems like these are two distinct sets of use
cases:
We need to handle scale -- tens of thousands of recipients will be very common,
up to a million for the marketing mail case.
We are sensitive to cost -- Amazons SES is cheaper than the negotiated mailgun
rate Ive heard. At big scale this matters! Amazon retail SES rate is $0.10 per 1000
mails. Our monthly spend last month was $100, mostly driven by the bulk mail to our
800,000 address list, but there were also a normal bunch of course emails.
The open source community doesnt want to go negotiate another vendor
relationship. Theyre already buying something from Amazon. This is a big deal for
adoption.
Forum Notifications can focus on isolation, for example by storing the mail to be
sent in the payload of the celery message itself. At scale we dont want that many big
messages, so we need to store the message body itself in the database.
Open Issues
1. International Content -- Exactly how to handle Unicode in all fields: from name,
from address, to address, subject, and mime multipart body.
Implementation
Student UI