[Mailman-Developers] A few things...

[Chuq Von Rospach]

First, Barry -- there's a message in the admin posting queue you need to
take a look at. It's an unsub request I can't find, but it's probably not
our problem, since we're also being hit really hard right now by both the
latest virus and by people who seem to have been spammed onto some list(s)
that seem tob e run on a mailman server somewhere, and the links to mailman
are probably the only ones that work (again). Sigh -- those links in the
default distribution are a mixed blessing...

And, you know, I was thinking today that the message sent out that says:

homebuoy1@hotmail.com has been removed from south-bay-birds.


Would be a lot more useful if it told me how/why (has he been removed? Or
unsubscribed?). 

One other thing -- this is another possible DoS issue, but I don't really
have any good idea of what (if anything) you can do about it. I was working
on some stuff the other day, and realized that my ~mailman/data directory
had a huge number of files in it.

It was stuffed with a bunch of heldmsg* files. At one point, a subscriber's
mailer misbehaved and the daemon stuffed 400+ corrupted messages down our
throats. We finally had to just blow away the requests.db file, but I didn't
realize until later it left the requests in ~data (somehow, that needs to be
cleaned up, but I don't know how to easily do that, but there seems a need
for some kind of garbage collection here).

But it also made me realize this opens the server to a denial attack.
Someone who's pissed at you can simply start sending messages to be held
into the admin queue, infinitely, until you run out of disk space or inodes.
And with the current admin interface, you can effectively shut down the
admin queeue by building a pending queue so large you can't process it. But
I'm more worried about that disk-based DoS here; at the same time, I don't
know how you could practically implement some kind of quota or protection,
unless you wanted to check disk space, and if it falls below some lowwater
mark, start TEMPFAILing messages back into the queue for later processing.
That, though, simply moves the dos attack into the mail queues, although
most mailers also do disk-space checks, and stop accepting mail if the disk
gets too full,. Not a good situation, but at least it'd keep the system from
shutting down because of a full disk....

Anyway, some stuff to give you headaches over....