I changed "reCAPTCHA" to "CAPTCHA" in the task title because we've typically avoided reCAPTCHA specifically, in favor of using our own CAPTCHA on the wikis.

Although the idea sounds nice I believe it would not prevent all bot-generated subscription requests since sending a <listname>-request@lists.wikimedia.org mail as well causes a subscription request.

Sorry, I meant <listname>-join@… as per http://www.list.org/mailman-member/node13.html.

I support reCAPTCHA. Our CAPTCHA is broken (cf. the ammount of spambots we lock everyday) in adition to other measures such as blocking subscription requests sent to $listname-join or rather make the ban list apply to those. Thanks.

In T194558#4202205, @Vogone wrote:

Although the idea sounds nice I believe it would not prevent all bot-generated subscription requests since sending a <listname>-request@lists.wikimedia.org mail as well causes a subscription request.

Excellent comment. I think with some email providers you can verify if an email was actually sent by the address it appears to come from (e.g. using DomainKeys Identified Mail with GMail), so we should make sure Mailman checks that.

I also think we need a sysadmin to investigate the recent abuse to determine the source (is it fake subscription emails, or is it GET/POST requests submitted by a bot)

First: I personally like reCAPTCHA, and think it provides a lot of value from a security/abuse PoV. Yet we need to consider carefully whether we can deploy it on Wikimedia projects as it stands.

The old reCAPTCHA v1 service, shut down since March 2018, allowed for purely server-side integration. We could deploy it without requiring our users run JavaScript, although on the backend, we would still have to interact with a non-free service (Google). This very possibly could have been an acceptable tradeoff for an optional feature.

Unfortunately, reCAPTCHA v2 and v3 both require either the usage of Google's JavaScript, or the deployment of an iframe controlled by Google. From their FAQ:

reCAPTCHA can only provide the optimal experience in terms of security and usability with JavaScript enabled. However, if supporting users who have disabled JavaScript is important for your site, you can enable the alternative challenge with the following steps. Navigate to the admin console and move the security preference slider to "easiest for users". Keep in mind that with this setting reCAPTCHA won't be able to use all of its security features.

In addition, data on the interaction with the site is recorded and sent back to Google to assist in making an access control decision. Thus, usage of pages protected by reCAPTCHA is covered under the Google terms of service. From the reCAPTCHA enrolment page:

You acknowledge and understand that the reCAPTCHA API works by collecting hardware and software information, such as device and application data, and sending these data to Google for analysis. The information collected in connection with your use of the service will be used for improving reCAPTCHA and for general security purposes. It will not be used for personalized advertising by Google. Pursuant to Section 3(d) of the Google APIs Terms of Service, you agree that if you use the APIs that it is your responsibility to provide any necessary notices or consents for the collection and sharing of this data with Google. For users in the European Union, you and your API Client(s) must comply with the EU User Consent Policy currently located at http://www.google.com/about/company/user-consent-policy.html.

It's possible that we decide the "less secure" non-JS approach is sufficient. However, we'd have to run this by WMF Legal, and it would probably require a revision to the ToS, or at the very least an addendum for lists.wikimedia.org.

(I also note that this is covered in WP:Perrenial Proposals, but didn't see that until I had already authored the above…)

It looks like recaptcha was built in recently and is available in buster https://bugs.launchpad.net/mailman/+bug/1774826