[Mailman-Developers] mailman and the web

[Barry A. Warsaw]

>>>>> "JA" == Jerry Asher <jerry@hollyjerry.org> writes:

    JA> Currently the ACS system is such that visitors can request
    JA> that follow up answers be sent to them, which the ACS
    JA> implements by creating hundreds of individual emails and
    JA> mailing them out.

How would you organize it otherwise?  A new mailing list for each
page, with the membership being those people who want followups for
that particular page?  Some of the ideas I have for Mailman 3.0
include the ability to create lighter weight lists that could be
created and deleted much easier than current mailing list objects.

OTOH, something that might happen post-2.1 is added a `topics' feature
where a mailing list can have a small vocabulary of keywords added by
the list admin, and the recipients could select which messages from
the whole list they'd filter out or receive based on these keywords.
This would be quite handy for some of our high volume lists like
python-dev and python-list.
    
    JA> I would like to "unify" the ACS bulletin board code with
    JA> "some" mailing list manager.  The benefits to the ACS toolkit
    JA> I perceive would include:

    |   1  detecting/catching vacation messages

Vacation messages are never supposed to be sent to messages with
"Precedence: bulk" headers.  I think this is a rather ad-hoc
`standard' and a lot of vacation programs just don't conform.  For
those buggy programs, knowing who they actually send the vacation
messages to is impossible.  Maybe it's Reply-to:/From: but sometimes
it's Sender: or even Errors-To:.  Mailman sets the latter to the
-admin address, so at least there's a hope that even for broken
vacation progs, the original sender won't get completely spammed.

OTOH, I'm not sure there's much Mailman can do.  Few even broken
vacation progs will send their responses to the list (thank goodness),
and if it doesn't go through Mailman, it obviously can't detect or
catch it.

    |   2  detecting/catching/(and maybe unsubscribing) bounces

Mailman's quite good at detecting and catching bounces.  Mailman 2.1
should be better (I've added quite a few new detectors, but due to a
pre-CVS snafu, I lost most of my bounce samples from my test suite).
Currently, Mailman will disable an address after some bounce criteria
has been met, but the actual disposition of permanently fatal
addresses have long been talked about (e.g. some distinction b/w
disabled by the user and disabled by Mailman, auto-resends for some
period of time to see if the address comes back, auto-unsubscribing).

    |   3  ability to post directly to the bulletin from email
    |      (and have the posts end up in the right threads)

Do you mean email->bbs?  That can theoretically be possible using the
same mechanism that email->news or email->archive works: you write a
Handlers/ module to inject the message into the bbs.  Your handler
module will contain a process() function that takes a mailing list, a
message, and a Python dictionary containing message metadata.  Then it
Does Whatever It Wants with this information and returns None.  With
an appropriate API for injection into the bbs, the DWIW part shouldn't
be hard.

In MM2.1, you might instead create a separate queue for shuttling
messages into the bbs.

    JA>   4 but I am worried about mail loops.

Mailman kills loops by adding an X-BeenThere: header with the list
address as the value.  If it detects such a header on an incoming
message, it throws a LoopError, which is currently defined to discard
the message.  Not all mail loops will preserve X-BeenThere, but I
think in practice it works pretty well.

-Barry