[Mailman-Developers] Re: [Mailman-Users] [RELEASED] Mailman 2.1 alpha 3

[Barry A. Warsaw]

>>>>> "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