Email lists are required for (e.g.) YourConstituencyMailingList; email alerts are desirable for all services. In all cases we accept submissions only from trusted senders -- our application sending an alert, or an MP sending a mail to a secret submission address.
Technical questions:
Do we need to support email to people who are not in the user database (assuming that there is a shared database -- see LogIn)?
Each site needs to manage its own sub-lists of recipients (e.g. recipients in a given constituency for YourConstituencyMailingList; recipients near a particular location for GiveItAway); should this be done by the applications, or should we build infrastructure into EvEl for this purpose?
In any case we need standard mailing list features: reliable deliveries, VERP-style bounce detection, etc.
Existing mailing list management software (e.g. MailMan or ezmlm) has lots of features for managing subscriber lists, which won't be very useful for us. Is it worth reusing such a program or writing our own? I suspect that, given the fairly simple feature-list, we may as well roll our own.
We also have a little bit of incoming email to process. The important cases are:
bounce processing for mailing lists and alerts;
submission of mail to YourConstituencyMailingList;
(possibly) some kind of ticketing system for general incoming query mail (on the basis that with a big enough audience there will be a lot of this, and mail can easily get lost if it's just being dumped into people's inboxes).
There's actually not much common between these.
Outline of EvEl from the client's perspective
EvEl supports the concept of lists, which refer to sets of recipients for some kind of email. A list is a lightweight object (unlike in a conventional MLM): it's just there to tie together people interested in one particular kind of email. For instance, a discussion forum could create a list for each topic in the discussion, to be used for notifying interested readers when a new comment is posted.
(Comment: in this design we would create a list even for cases where only one person is likely to be notified, such as searches for items near a postcode in GiveItAway. This is slightly wasteful, but not too bad.)
We implement a very simple interface with the following methods:
- create DESCRIPTION
Create a new list, with the given DESCRIPTION (an HTML fragment describing what the list is for). Returns an opaque integer ID identifying the list on success.
- destroy LIST
Destroy an existing LIST.
- subscribe LIST ADDRESS
Add ADDRESS to LIST.
- unsubscribe ID ADDRESS
Remove ADDRESS from LIST.
- send LIST SUBJECT CONTENT
Send a simple (plain text) email. SUBJECT and CONTENT are assumed to be in "text/plain; charset=utf-8".
- forward LIST EMAIL
Pass EMAIL on to the list. We add our own footer stuff to the bottom, but otherwise leave it unaltered. EMAIL should be a valid MIME email in on-the-wire format.
- is_mail_bouncing ADDRESS
Has mail to ADDRESS been bouncing?
- ui_address ADDRESS
Return a URL to which the user can be sent to unsubscribe, change address, etc. XXX need to add some way to theme this, in due course.
Assumptions
All the methods follow the XMLRPC model, so there is a distinction between an error return ("fault") and a successful return. Only "create" has a return code.
We make life easy for sending a plain text email; this is presumably what we'll want to do for alerts etc. It's also easy to pass on an email which has been received (basically this is for YourConstituencyMailingList). Constructing more complex emails has to be done "by hand" using MIME-tools or whatever.
Bounce detection and automatic deletion of bouncing addresses from lists is done by the EvEl software itself. is_mail_bouncing is a utility method which exists so that an application can warn the user that there are problems with their email address. ui_address lets an application direct a user to a page where they can configure their mail preferences etc. (E.g.: stop receiving particular alerts, change their email address, etc.)