[Mailman-Users] Mailman continues to deliver to deleted list

[Mark Sapiro]

On 11/6/2012 9:38 PM, Stefan Foerster wrote:

> I am aware of how to get rid of shunted messages but I'd like to know
> if there are performance penalites for keeping a moderate amount
> (<1k) of messages around in the shunted queue for about a month.
> 
> As far as I understand, the shunted queue is not directly involved in
> message delivery, so there should be no performance hit, right? This
> way I could "play it safe", keep those messages around for a certain
> time (they might turn out important after all) and then have a cron
> job delete them.


You are correct that the shunt queue is not involved in normal delivery.
The only hit would be when shunting an additional message. If the
physical size of the qfiles/shunt/ directory in the file system is
large, there is additional overhead each time another message is shunted
because the entire physical directory must be searched, even if it is
empty, to ensure the new entry is not a duplicate name.

Regarding a cron job, the following is from Mailman's NEWS file

2.1.11 (30-Jun-2008)

  New Features

    - Added a new cron/cull_bad_shunt script to cull and optionally
      archive old entries from the bad and shunt queues. This is controlled
      by new Defaults.py/mm_cfg.py settings BAD_SHUNT_STALE_AFTER (default
      7 days) and BAD_SHUNT_ARCHIVE_DIRECTORY (default None) which determine
      how long to keep bad and shunt queue entries and optionally, where to
      archive removed entries.

Note that this means that in a default configuration since 2.1.11, shunt
queue entries are deleted after 7 days. Do disable this, set

BAD_SHUNT_STALE_AFTER = 0

in mm_cfg.py. To keep them for a month, set

BAD_SHUNT_STALE_AFTER = days(30)

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan