[Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3
Barry A. Warsaw
Mon, 22 Oct 2001 12:39:31 -0400
>>>>> "CVR" == Chuq Von Rospach <email@example.com> writes:
CVR> (clap clap clap clap)
>> and admins can change members' Real Names on the membership
>> pages. Mass subscribing accepts "firstname.lastname@example.org (Real Name)"
CVR> You should also accept
CVR> Real Name <email@example.com>
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
CVR> Is there a plan to set up a bounce returned to
CVR> firstname.lastname@example.org 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
>> - 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
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@example.com". 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)