[Mailman-Developers] 1-click unsubscribe

Stephen J. Turnbull stephen at xemacs.org
Thu Mar 6 20:38:27 CET 2008


Aaron Crosman writes:

 > Sounds like what you're describing is a more complete CRM.  Personally,
 > I don't think Mailman should head in that direction, there are perfectly
 > good CRM's for NPO's out there (like CiviCRM).

He is talking about a more complete CRM, but we need that anyway
because of one-stop subscription management for multiple-list
subscribers.

The specific attributes Ian requests leave me cold, too, but I have my
own idiosyncratic attributes I'd like to be able to query from the
subscriber database.  Fortunately, what Barry has proposed is an
architecture that makes it easy to do these things.  (If Barry chooses
to work on Ian's requests in the spirit of a Pizzigati Laureate --
congratulations, Barry! -- that's fine by me; I'm happy to contribute
by taking care of my own needs.)

 > It would be a long time until Mailman could do the other functions
 > of a CRM well-enough for them to be a good idea for anyone to use.

That's not the direction Barry's going AIUI.  What would be nice is a
way for "CRM solutions" to take care of the subscriber db and contact
scheduling while Mailman lives up to its name by taking care of
delivery.  Then Mailman would provide a default "CRM solution" plug-in
which handles *only* the "customer" attributes relevant to
subscriptions, ie, name, email, notmetoo, nodupes, nomail, etc.  This
would provide the same functions that are currently integrated in the
Mailman core.

See also the posts regarding "RESTful interfaces."

In other words, from the CRM point of view there would be a message
injection API into Mailman, an optional bidirectional API for Mailman
to request and update subscriber information from the CRM, and an
optional API for the CRM to handle db updates on behalf of Mailman.

I think this is what Barry has in mind, although he probably can
explain it better.


More information about the Mailman-Developers mailing list