[Mailman-Users] Using mailman for one-time use special demographiclists...

[Mark Sapiro]

Bill.Costa at unh.edu wrote:
>
>We're planning on moving off our our creaky old ListProc MLM and
>moving to something with a web interface and an active community.
>I'm seriously looking at mailman as future MLM for all our
>mailing lists (~600).
>
>I was hoping somebody could describe, in broad arm-waving terms,
>how Mailman could be used as a back-end for doing mailings to
>one-time use distribution lists.  Here's the scenario:
>
>    The sender will identify the desired demographic, say "left
>    handed liberal arts majors with blue eyes", by creating an SQL
>    WHERE clause that selects those folks from our Student
>    Information System.  (We use a commercial product called
>    Banner that sits on an Oracle DB engine.)


SCT reaches far and wide :-)


>    So what I'll have to work with are unique user IDs which I can
>    then turn into a set names and e-mail addresses that exist
>    within our various e-mail and alias systems.  And of course
>    I'll be handed a message to be distributed and the e-mail
>    address of the sender.  After this particular list is built
>    and the message has been sent, that particular demographic may
>    not ever be used again.
>
>    Finally, there is the possibility that I would have the unique
>    ID, name, and e-mail address for all possible users stored in
>    an LDAP.  But the LDAP would contain no other selector
>    information, such as eye color.  :-)   In other words the
>    demographic selection process would always have to be made in
>    Oracle.
>
>Now as a point of comparison, here is how I currently handle the
>above situation with ListProc:
>
>    I have a standing generic list, configured for one-way
>    announcements, let's call it "UNH.Announce".  I use a Perl
>    script to take the IDs and map them to names/e-mail addresses
>    and use that data to build a flat file subscriber list in the
>    exact format that ListProc builds for itself.  I then run a
>    command that causes ListProc to re-cache the list.  I make the
>    sender the temporary owner of the list (to have exclusive
>    posting permission), post the message as that user, and then
>    flip the ownership back and zero out the list to prevent
>    accidental re-use.
>
>I see that Mailman has a mass subscription function, so I could
>do something similar using that facility.  But at this point I
>don't know enough about mailman to know if there would be a more
>proper mailman-ish solution to this problem.

Here's my $.02. Mailman allows a per list customization mechanism that
can be used to establish a custom MemberAdaptor module for one or more
lists. You could set up your one, standing, generic announcement list
to use an LDAP MemberAdaptor to access the LDAP you refer to above.
The other 599 lists would use Mailman's standard MemberAdaptor.

If you had in addition to email address and whatever else you wanted in
the LDAP, a single flag meaning 'mail this one', then you could make
your selection, flag those records in the LDAP, post to the list and
clear out the LDAP flags.

Both LDAP and MySQL MemberAdaptors exist. See
<http://sourceforge.net/tracker/index.php?func=detail&aid=871062&group_id=103&atid=300103>
for LDAP and
<http://sourceforge.net/tracker/index.php?func=detail&aid=839386&group_id=103&atid=300103>
for MySQL, although if you're interested in the MySQL MemberAdaptor,
see the threads:

Mysql MemberAdaptor 1.61 and Mailman 2.1.6
and
MysqlMemberships.py [was: Informal "MEP" process, anyone? [was: PHP
Wrappers?]]
which ultimately became just
MysqlMemberships.py

at
<http://mail.python.org/pipermail/mailman-developers/2005-October/thread.html>
and
<http://mail.python.org/pipermail/mailman-developers/2005-November/thread.html>

Note also that the LDAP MemberAdaptor referenced above is a "read only"
adaptor from Mailman's side, but this would appear to be fine as you
would be writing the LDAP outside of Mailman anyway. You would
probably have to modify the LDAP MemberAdaptor slightly so that the
flag I refer to above would have meaning 'delivery disabled' if not
set and 'delivery enabled' if set.

Or you could make your own custom MemberAdaptor that could read any
files or query any databases you want. It would only have to implement
a few methods - getMemberCPAddress(member), getRegularMemberKeys() and
getDeliveryStatus(member). getDeliveryStatus(member) could always
return ENABLED unless you wanted to use it as a flag. I think you also
need getMemberOption(...) although it could always return 0 since it
is only used to determine if a poster gets her/his own post.

You could possibly get it to read the SQL selection clause and query
the Oracle database to get the data to build the results.
getRegularMemberKeys() could return a list of ID numbers from the
query, and getMemberCPAddress(member) would return an email address
for an ID number.

-- 
Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan