>>>>> "CVR" == Chuq Von Rospach <[EMAIL PROTECTED]> 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 PROTECTED] (Real Name)" CVR> You should also accept CVR> Real Name <[EMAIL PROTECTED]> 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 >> "[EMAIL PROTECTED]". CVR> Is there a plan to set up a bounce returned to CVR> [EMAIL PROTECTED] 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 "[EMAIL PROTECTED]". 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 _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers