"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 messagesVacation 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) bouncesMailman'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