[Mailman-Developers] On allowing any list member to be an email moderator

[Robby Griffin]

On Dec 31, 2005, at 23:22, Brad Knowles wrote:

>  some lists have as many as 100 messages waiting in
> the queue to be moderated, and some of those messages date back to
> May of 2005.  I think that this is a problem that needs to be
> addressed within the Mailman package, and not just something that can
> be observed externally through tools like "mmdsr".

Here's what I've done for somewhat unrelated reasons:

- patch bin/discard to support rejecting held messages
   and providing rejection comments.

- add a cron job that rejects held messages older than 10 days,
   with the following comment:

   "Your message was automatically rejected after being on hold too
    long without moderator action."

The reason I set out to expire held messages was not because of
absentee moderators, but because of overworked moderators who
had trouble with the sheer workload of deleting spam from batches
of lists they run. With expiration in place, they can simply pick
out and approve the few legitimate posts every so often, leaving
the rest to rot.

I mention this because you're on the subject of ridiculously
long-held messages, which my changes eliminate entirely. But also,
for lists with absentee moderators, held message expiration should
have two harmless effects:

1. removing all held spam eventually, by way of removing all old
    held posts.

2. informing legitimate moderated senders that the moderator
    is likely absent, and definitely did not discard their post.
    So if they know of some other way to post without incurring
    moderation or some other way to contact the moderator they
    should use it.

If I had this to do over, I would probably say the timeout and
action (discard, reject with configurable comment, approve) for
expiring held messages ought to be configurable sitewide and/or
per-list rather than hardwired in a cron job. Some people take
longer vacations than others, and for some lists the failure
mode of rejecting all posts is undesirable.

I would also want to consider the relationship of any such
configuration with mm_cfg.PENDING_REQUEST_LIFE. It appears that
some subscription requests and confirmation cookies for held posts
may already expire on their own schedule, and that the rationale
for this might inform the design of held message expiration.

	--Robby