Karl Berry writes: I'm surprised Mark hasn't chimed in, maybe he's out on a boat catching salmon. Don't know when he'll be back, so here's what little I can say.
> 1) The above mailman-users thread refers to using fail2ban. The set in https://github.com/fail2ban/fail2ban/tree/master/config/filters.d looks quite comprehensive but there's nothing there that looks like it's to protect mailing lists. I hope somebody already has one, but I don't, and can't really suggest what might be similar that's already in the fail2ban distribution. > 2) At least in my cases, the floods try to subscribe the same address > over and over (and over and ...). It occurs to me that mailman could > silently discard a request to subscribe an address f...@bar.com if > f...@bar.com already has a pending subscription -- that is, not sending > out the confirmation request. Would this be doable? Mark, anyone? I'm pretty sure Mailman 3 has this although it may be recent. I doubt Mark would be willing to add it if it's not already in Mailman 2, although it's the kind of think I would think he would have back ported. Do you have the most recent version of Mailman? If it's not in the most recent version of Mailman 2, or you don't want to upgrade for some reason, it's certainly doable as a patch, but how to implement will depend on how fast the requests are coming. I'm pretty sure that Mailman does not have a database of pending subscriptions that's efficient for this purpose. Your sources of information would be the log files (which presumably get rotated, may not have successful subscriptions, and so can't be 100% depended on) and the pickled subscription objects (.pck files) in the queue. The .pcks have a name that matches the one-time key so can easily be identified from a confirmation request, but the information needed to identify that this is a duplicated subscription is inside the object, which would need to be unpickled. This is not a terribly time-intensive operation, but could take a while if the evil requests come in frequently enough to build up a long queue, and in this design you'd be repeating this for every request. If you don't mind missing one occasionally (ie, across log rotations) and the log files aren't humongous, you could just read the whole log every time, which would be much faster than working with the pickles, and look for matches on the subscription address. The main issue I could see with either method is that this will slow down subscription processing substantially if the queue is long, which could happen with a "shotgun" of subscription attempts with different addresses. Keeping the database of pending subscriptions in memory would help with that, but you'd need to reread the .pcks on restarts. I'm not really sure where this code would go. Probably in Mailman/ListAdmin.py, although it might be called from MailingList.py. Steve ------------------------------------------------------ Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/
