Tom NewChao via Mailman-Developers writes: > +1 to the original report.
Nothing has been done for years; "+1" is unlikely to affect the urgency felt by the core developers. 3rd party patche submissions might help, but the ones I've seen in the past are not high quality. > First, the cost is not only ours. Stipulated. > Second, the usability objection is real but narrow: it applies to > account creation, which a given user does once. It does not touch > subscribing by mail, posting, or reading archives. I don't understand what you mean by "it does not touch subscribing by mail". Email confirmations can be (and are by default) required for all anonymous subscription requests, including email, and this attack has been used for decades against individual users by varying the list (and site) rather than the address to subscribe. And it is not true that a given user "does it only once". Many users subscribe anonymously to multiple lists because they lack sufficient energy to deal with password management, especially now that we have a one-click confirmation process. In general, I'm not sure what you mean by "narrow". For most people joining (or leaving) a list is a big decision compared to everything else they do with it. And here we're concerned with the set of operations that might generate a confirmation email, which is mostly the same set. > Now the concrete part. I want to push back on the reflex -- which > was my own first reflex -- that this is a rate-limiting problem. I've never heard that before. On its face, it's at best a palliative. > That same shape is missing from registration, and I think it is > half the answer for everyone: It was missing from Mailman 2, but as far as I know it is implemented in current Mailman 3. That is, there is a check before sending a second verification email. I don't know offhand if it is suitable for this purpose though (it might just be to deal with "keyboard bounce"). > - refuse to originate a confirmation to an address that already > has an unconfirmed registration pending; It is quite common for people to request a second confirmation email in other contexts. I know people who regularly inadvertantly delete confirmation emails. I don't have data on that behavior with mailing lists, but I suspect that prohibition needs to be time-limited. > - a per-installation ceiling on confirmation mails per hour, so the > blast radius is bounded even when the front door is defeated. That seems useful. Any estimates on what that ceiling should be for your installation? (It would help to know how many lists and how many unique email addresses across all lists, but I understand you may not want to disclose those.) > - off by default and switchable by the site admin, so installations > without this problem pay nothing; It would definitely need to be an optional feature, possibly at the list level (if so, the site admin would need to be able to force it on similar to emergency moderation but sitewide). > - pluggable rather than wired to one vendor, so a site can pick Definitely it needs to be pluggable because we don't want to be responsible to users to support all the variations. > Handing every visitor's IP to Google is not something every > installation is able to do; a proof-of-work challenge costs the > honest user an invisible second and costs a bulk attacker > linearly. Not sure what you mean by "proof of work". > Agreed, and I would not argue for it if the goal were to stop a > determined attacker. What we see is an unauthenticated loop over > one endpoint, run because it is free. I thought it wasn't a loop, it used a large number of IPs? That's hardly free, as well. > > Another possibility would be to push the responsibility on to the > > big providers by requiring a social auth login. > > I would like that available, It's already available, it just requires a certain amount of sophistication (maybe even a dozen lines of plugin code?) of the responsible site admin. > So the machinery exists; what is missing is that it is an > all-or-nothing switch. I don't understand what you mean by all-or-nothing. > But making social login the only door would exclude precisely the > users who are on mailing lists in order not to depend on those > providers. I don't think there's an easy way to do this, but we could allow subscriptions only by an existing logged in user. Creating a user with a password would be more work than the current anonymous subscription process (but this is *known* to deter elderly and some disabled users). And attackers would find it trivial to automate, I think. The advantage to social auth is that we don't need to send confirmation messages to them for the authorized mailbox (although probably we currently do). > Happy to run patches against an installation that is receiving this > traffic daily. My pro bono dance card is full up for many months. The full suite of features you request will take quite a bit of effort, and much of it should be done, not in Mailman, but at the django-allauth level which means negotiation with that community (with no guarantee of quick success, and more package management annoyance for Mailman admins in the interim). And as we've both pointed out, there are *many* *non-trivial* tradeoffs for all of the restrictive features. It's not easy work. You do make a good case for the various features. You might have more luck with the django-allauth community, and they might have better data or sense of the problem space. Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
