How DList was implemented in Mailman
The various changes you see below are those that have been included in Mailman version -2.1.10.
1. In mm_cfg.py, we add:
A Dlist Queue (Queue/DlistRunner.py)
In global pipeline we insert Dlist handler before CookHeaders. (Mailman/Handlers/Dlists.py)
For Dlists to work, every new conversation is explicitly started by a user sending mail to listname+new@domainname, or listname+new+subject@domainname if the subscriber wants to explicitly define the subject/thread name.
2. PostgreSQL Database:
To deal with the *new* threads or conversations, Systers have added a database in PostgreSQL. Each list has its own database containing information about: * who is subscribed to what conversation * the other aliases a subscriber can use to send emails and still be allowed to post to a list
See : http://systers.org/systers-dev/doku.php/systers_database_in_postgresql for more details on the database schema.
All the database interactions are handled by the mailman/Mailman/DlistUtils.py file and we have provided Storm ORM support for it.
When the message is handled by the Dlist Handler, we do our thing - parse the subject for “new” or thread name, and then call functions in DlistUtils depending on what the command was.
DlistUtils's newThread() and continueThread() do the database stuff. Now if you are thinking, "why have a whole another Queue for Dlists?" The reason is that the Incoming pipeline is handling *one* message (one set of recipients & one msg text). For Dlists, we actually want to create two slightly different messages and disjoint sets of recipients from the original single message (one set of recipients who have subscribed to new conversations, and one set of the nonrecipients who have either unsubscribed from new conversation or have explicitly unsubscribed from this ongoing conversation). The original message is sent to nobody (except the archives), while two new altered messages are inserted into the Dlist queue.
- The Dlist queue doesn't do anything except put the msgs in the outgoing queue.
Mailman 2.1.10 kept its info in .pck files. Dlists require that we use the database instead. We have to keep the database in sync with new members, and with option changes made via the web. Dlist changes MailList.py to use the DlistMemberships class instead of OldStyleMemberships class to handle member changes. DlistMemberships inherits from OldStyleMemberships, so the changes in DlistMemberships.py are usually a) do something additional we need to do for Dlists, then b) call the parent method to do the non-Dlist-related work.
3. Other Visible changes
Listinfo page
The listinfo page where users can subscribe to a list has a different list email address for dlists, which is given on the page. For dlists as well as for non dlists the creator of the list can chose to activate the essay feature, which is not in the standard Mailman.
Footer of emails
In the emails sent out via a dlist, the footer is changed to give information on different features of the dlist. For instance, users can unsubscribe from a single conversation if they wish to, instead of unsubscribing from the entire list. The footer is (for dlists) stored in the mlist object and included by /usr/local/mailman/Handlers/Decorate.py. All mlist objects have the same footer.
Options Page
To the options page, Systers has added the possibility to add different aliases with whom the subscriber can send emails to the list. This feature is called “other incoming address” and is handled through the PostgreSQL database.