The latest version of Mailman does implement a Captcha (via reCaptcha). Also, if you set mm_cfg.SUBSCRIBE_FORM_SECRET to a secret value, Mailman will insist that the subscription form be submitted after a slight delay, which defaults to 5 seconds. This features exists in the version currently used by the mailing list (2.1.20).
I have downloaded the source code (version 2.1.20) and am looking into adding code to limit the rate of subscriptions for a given e-mail address to a configurable value. Something like 1 to 2 days should do the trick. -Jeff On Wed, Jun 13, 2018 at 12:15 PM Richard Hipp <d...@sqlite.org> wrote: > On 6/13/18, Brian Curley <bpcur...@gmail.com> wrote: > > Doesn't the Fossil site already have a Capcha interface built into it > that > > could be adopted to enforce additional authentication around > subscriptions? > > There are no captchas built into GNU MailMan. You enter your email > address to subscribe and you get a confirmation email. Click on a > link in the confirmation email. Then your subscription goes to > moderation. After the moderator approves, you are signed up. > > The above system works fine to keep nefarious actors out of the subscriber > list. > > But that is not the problem. The problem is that the bad guys don't > care about getting onto the subscriber list. They just want to > generate as many bogus confirmation emails as they can, to harass the > people who are receiving the confirmation emails. > > The obvious solution in GNU Mailman would be to only allow a single > confirmation email to go out per email address. After that one email, > the corresponding email address is never allowed to sign up again. > > This simple fix is complicated by several factors: > > (1) Nobody seems to want to own the GNU MailMan software. It is not > well maintained as far as I can see. > > (2) MailMan does not seem to use a database other than the filesystem > and perhaps Python Pickle files, at least not that I have found, so > recording extra information such as who has previously requested a > subscription involves major structural changes to the code. > > (3) MailMan itself seems to be a collection of scripts that must be > all installed in multiple well-known directories. It is difficult to > identify what files are part of the MailMan implementation and what > files are not, making maintenance error-prone for people (like me) who > are unfamiliar with where to find all the pieces. > > (4) There is a GNU MailMan mailing list, but in my past interactions, > there was nobody there who was willing to help with spam problems. > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
