The mailing list for listmasters using Sympa

[Olivier Salaün - CRU <address@concealed>]

Hi Bill,

Your desired feature is of interest because it goes one step beyond what 
Sympa currently provides ; therefore it's an interesting expression of 
needs for possible future developments. But anyway the current release 
of Sympa will do a bit more than what listproc provides, as explained below.

* external definition of list members *
Sympa provides 2 ways (that you can mix within a single list) of 
defining list members : the traditional subscribe/add way and the 
'inclusion' way. Inclusion make it possible to dynamically import list 
members email addresses from any of the following data sources (you can 
have multiple sources) : SQL DB, LDAP directory, flat file, another 
local mailing list, a remote mailing list. This should save you the job 
that previously consisted in building listproc subscriber files. More 
information about inclusions can be found here : 
http://www.sympa.org/doc/html/node19.html#SECTION001920000000000000000

* list families *
List families represent a dynamical model for a set of mailing lists 
sharing common caracteristics. More information can be found here : 
http://www.sympa.org/doc/html/node18.html
Currently a family list can only be "instanciated" via the command-line, 
but we plan to provide it on the web interface as a replacement for 
current list creation templates. To instantiate a list in a family 
context, the autorized user would first select the family and then 
provide a set of parameters required to instantiate the list. These 
could include SQL or LDAP parameters.

* one-time lists *
Sympa does not natively provide such kind of lists. Here is how we 
imagine they could be implemented :
A one-time list is created to send a single message and is then removed, 
no archives are required. Sympa would need some input data to create 
such a list, just like a standard list and the web interface would 
probably be well adapted for that. Once it has been created (and tagged 
as one-time) we need to trigger its removal. It could be removed after 
the first and only message was distributed or we could consider that the 
message must be submitted via the web interface, which makes it easier 
to trigger the removal after the message has been sent.
A main issue with the one-time mailing list definition is to find the 
proper User Interface to define SQL queries, without too much complexity.

Coming back to your present needs, you can probably keep the same script 
you had for Listproc, except that you don't have to run the SQL or LDAP 
queries yourself. There's just one thing you might be missing : you 
can't trigger the update of mailing list members (with SQL or LDAP data 
source) from the command line yet (we plan to add this feature).

address@concealed 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.
> So far Sympa is far and away my leading candidate.
>
> I was hoping somebody could describe, in broad terms, how Sympa 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 a
>    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.)
>
>    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 in
>    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 subscribe 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 imagine that I could probably do more or less the same with sympa.  
> I've been lurking here long enough to know that Sympa
> still supports it's original flat-file subscriber list format, so I 
> figure I could use the same trick as I'm doing with ListProc.
> But I'm wondering what other, smarter methods, could be used given 
> Sympa's many features and interfaces (SOAP, LDAP, SQL,
> etc. etc.).

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature