[Mailman-Users] Automatically Deleting Held Messages

[Jon Carnes]

Description:
  On some of my mailman lists, I don't want to look at the held messages - I
just want them deleted. Also, I'm never going to approve any subscribe
requests for those lists - I just want them deleted as well!

  In the example below Mailman was installed in /home/mailman.  I will use a
list named "hr". This particular list gets between 8 and 40 select pieces of
spam every day.  These are all caught by the Privacy Option:
    "Must posts have list named in destination (to, cc) field" = yes

===
Doing it:
  - Delete all current requests using the web Admin. This will make the file
request.db empty (for that list).
  - Change directory to your lists configuration directory:
      /home/mailman/lists/hr/
  - Copy the file request.db to orig.request.db
  - su as mailman
  -  Create the script /home/mailman/bin/rm_held_msgs
######
#!/bin/bash
# This script removes the UCE that has accumulated for a list.
# First clear out the heldmessages in ~mailman/data
# Then replace the request.db in ~mailman/lists/<listname>/ with the
original
#
# HR list:
rm /home/mailman/data/heldmsg-hr-* 2> /dev/null
cp /home/mailman/lists/hr/orig.request.db /home/mailman/lists/hr/request.db

# other lists...
######

  - Make the script executable (chmod a+x  /home/mailman/bin/rm_held_msgs)
  - Edit crontab to have the script run hourly (crontab -e)
######
# Automatically remove held spam messages from lists like HR
59 * * * *      /home/mailman/bin/rm_held_msgs
######

===
The Details:
  Held messages are stored in ~mailman/data.  You can easily read, edit, or
delete them.  The messages are stored in files with the name:
      heldmsg- <list-name> - <number> .txt.

As an example held messages for hr would have names like this:
      heldmsg-hr-97.txt
      heldmsg-hr-98.txt
      heldmsg-hr-99.txt
      heldmsg-hr-100.txt

These files contain individual emails that were sent to your lists.  Mailman
stores these files here (as a sort of queue) and sends out either an
immediate message or a daily message alerting the admin of the waiting
messages.  Mailman will also use these held messages to load information
into a database for your list.  The name of this database is request.db.

The amount of information Mailman loads into request.db for every message is
determined by various settings in either ~mailman/Mailman/mm_cfg.py or
Defaults.py

When you browse via the web-admin and look at the waiting requests, you are
accessing the request.db database and not the actual files in
~mailman/data/..  For our purposes, we just want to blank out request.db.
We can probably just delete it, but I err on the side of caution and simply
replace it with an empty version.

I have my lists set to NOT alert me so that I only get the daily alert from
Mailman (in the web-admin under General Options):
      Should administrator get immediate notice of new requests,
      as well as daily notices about collected ones"       = no

The Mailman alert script then runs at exactly 5:00pm every day, so I could
set the script to kick off once a day at 4:59pm and I would never get bugged
about held messages (for lists in my script).  Instead I run the script
hourly at 59 minutes past the hour.  The effect is the same, I just don't
like letting spam hang out on my server longer than an hour.

The first active line in the script uses a redirect to get rid of warnings -
should there currently be no held messages for the list.  A redirect with a
2 in front of it specifically catches console warning messages:
      .... 2> /dev/null   # sends warnings into the bit bucket

===
Disclaimer:
  The solution above is elegant only in its simplicity.  I started out on
Thanksgiving holiday with every intention of making an elegant hack in the
Python code so that I could simply send held messages into the bit bucket,
rather than have the buggers bother me with emails I darn-well *knew* I
wanted deleted.  However, after about 10 minutes of tracing things, the
above solution occurred to me.

So I wrote the script and added it to cron and was done in less than 30
minutes... It's been tested for 4 days here, and works great for me.

There are a lot of solutions to the problem of dumping held-messages in
Mailman.  This one is mine.  As with anything you get for free, use at your
own risk.  If you play with it and break it (even if you follow my
directions), it's your own fault.

Jon Carnes