Re: [Mailman-Developers] Remediation for fake member creation
----- Original Message -----
From: "Barry Warsaw" <barry@list.org> To: "mailman-developers" <mailman-developers@python.org> Sent: Monday, August 22, 2016 2:43:06 PM Subject: Re: [Mailman-Developers] Remediation for fake member creation
On Aug 22, 2016, at 01:03 PM, Franck Martin wrote:
While mailman does double opt-in, one can still fill a mailbox with account confirmations, what are the methods to stop a bot submitting email addresses for registration across several lists?
Mailman 3 will not pend a registration request more than once for an email/mailing list combination. It's possible to spam every list at least once though, and I'm not sure what you could do about that.
May be a captcha? Or some more modern techniques...
Franck Martin writes:
May be a captcha? Or some more modern techniques...
Captchas aren't applicable to email requests. It will be harder than that.
We could turn off subscription by email after user creation so that users would get only one email per email at most. From Mailman's point of view:
<== subscribe email to list1 === create user for email ==> OTK to email, says "please visit URL, email operation admits abuse" <== subscribe email to list2 === recognize email, queue this request for user <== visitor arrives ==> You have (2) pending subscription requests: [x] confirm all subscriptions [x] subscribe email to list1 [x] subscribe email to list2 [submit confirmation and login to options] [just submit confirmation]
The confirmation page would recommend adding other emails to the user for security and posting convenience.
Of course a bot that knows all of a person's email addresses can do
<== subscribe email1 to list1 <== subscribe email2 to list2 <== subscribe email3 to list3
resulting in three messages in the inbox, but that's probably orders of magnitude improvement over requesting subscription of one email to all the lists on a large server.
For users who can't use/hate the web, I suppose you could allow email reply confirmation, in which case email operations would remain effective until the user explicitly turns them off.
Finally, we could keep the users with no subscriptions in the database (at the person's option), preventing the felon from waiting until the subscription requests expire then bombing the person again.
WDOT?
Steve
participants (2)
-
Franck Martin
-
Stephen J. Turnbull