"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
>> http://sourceforge.net/project/shownotes.php?release_id=58074
CVR> (clap clap clap clap)Thanks!
>> and admins can change members' Real Names on the membership
>> pages. Mass subscribing accepts "email@dom.ain (Real Name)"
CVR> You should also accept
CVR> Real Name <email@dom.ain>Yup, sorry, it already does. I've updated the NEWS file (for the next release at least).
>> o The list admin can send an immediate urgent message to the
>> entire list membership, bypassing digest delivery. This is
>> done by adding an Urgent: header with the list password.
>> Urgent messages with an invalid password are rejected.
CVR> Is the Urgent: header stripped as it passes through Mailman?
CVR> What happens when a regular user tries to put an Urgent:
CVR> header on a message as a non-admin?Just like an Approved: header, it's always stripped because it contains a password.
Regardless of who sends it, if the Urgent: header's value doesn't match the list admin or list moderator's password, the message is bounced back to the sender.
>> o There is now a `site list' which is a mailing list that must
>> be created first, and from which all password reminders appear
>> to come from. It is recommended that this list be called
>> "mailman@your.site".
CVR> Is there a plan to set up a bounce returned to
CVR> mailman@your.site to be considered a global bounce and that
CVR> user is unsubbed from all lists? Right now, mailman
CVR> effectively throws away bounces from the password reminders,
CVR> which can be used very effectively to keep stuff clean.Yes, there are plans ;). Whether I actually get to it or not we'll see.
>> - Membership Adaptors o Internally, mailing list memberships
>> are accessed through a MemberAdaptor interface. This would
>> allow for integrating membership databases with external
>> sources (e.g. Zope or LDAP),
CVR> Given that, if someone wants to write a fully external
CVR> authenticator, is it possible to completely disable mailman's
CVR> interface for a given list (or all lists?) Including things
CVR> like monthly password reminders?
CVR> I guess what I'm suggesting is Mailman as a slave to a
CVR> non-attached membership system -- can we really detach it
CVR> cleanly so it's just a delivery system without rough edges or
CVR> hacking? Down to the external membership system in headers
CVR> and footers?Hmm, let me try to untangle a couple of issues.
First, this adaptor API is only for membership-related information. It doesn't cover other list-related data, such as "what's the subscription policy for this list?". I want to do that eventually, but not for 2.1.
But the membership API is complete, in that you can ask for a member's real name, their password, their case-preserved email address, their option flags (do they get MIME digests?), their preferred language, etc. It covers adding new members and removing old members.
This means that if you supply a different backend implementation for the API, it's all or nothing: you're responsible for the entire API and managing all the member-related data.
So, when Mailman has to authenticate a user for access to their options page, it uses the API, passing in the email address and the response and it should receive a boolean specifying whether the username/passwords matched.
One other thing that Control.com sponsored, but which I forgot to add to the NEWS file, was an API for an external process to post messages to a list, and to specify the explicit list of recipients in the posting interaction. What this means is that you could create a list, say "employees@dom.ain". Then when you want to post a message to this list, you simply create the message, and determine what the explicit list of recipients is, then send both to the posting code. With the list-extension mechanism, you could also completely defeat the U/I (I think) so that Mailman would indeed act as a posting slave.
>> This work was sponsored by Control.com
CVR> (clap clap clap clap)Indeed!
-Barry