|operations/puppet||production||+4 -4||mailman: increase per IP and per email rate limits from 1 to 5/hour|
Which specific mailing lists was this tested with? Which web browsers was this tested with?
(Likely unrelated, but I fail to see CSS applied and encoding errors for e.g. https://lists.wikimedia.org/mailman/listinfo/wikics-l in Firefox 60 and Chromium 65, due to Blocked loading mixed active content “http://cs.wikipedia.org/skins-1.5/common/*.css“)
- Tested lists: wikimedia-l, wikimediafr and wlm-announce.
- This was tested with Firefox 60 on Ubuntu 17.10 (on two computers), but I don't see how it is relevant for a server-side error. I tested again with Chromium 66, same error.
IP received by email. Thanks!
Unfortunately it appears this address is listed on a few spam blocklists. Details about which lists and links to more information can be found by looking up the IP address with a tool like http://multirbl.valli.org
This is affecting list subscription because RBL checks at subscription time were implemented in https://gerrit.wikimedia.org/r/#/c/433671/ as a countermeasure against an increasing volume of list subscription spam.
My suggestion would be to coordinate submission of delisting requests for this IP and in the mean time subscribe to lists using a different IP address. If that isn't possible I'd be happy to help subscribe addresses as needed.
While this ticket is reopened, I might as well update: it turns out that the IP has been on these blacklists since 2012, years before it was ours. I cannot remove it from all the lists because they are for IPs of email servers and it is not an one (so I cannot do the required DNS changes...)
Hi, I ran into this problem over the last few days trying to subscribe to wikidata-tech while on the eduroam network (my public IP address of 18.104.22.168).
I then tried using my mobile phone (on the Vodafone network), and it responded "You're trying that too often. Please try again later."
Since the 429 "too often" error is thrown after multiple subscription attempts from the same IP maybe the phone was also connected to wifi at the time?
In any event I think we can tune the rate limit to a less aggressive setting now that the flood of spam subscription requests has slowed. Let's start by increasing it from 1 to 5 per hour and see how that goes.
The RBL check that was causing 403s for subscription attempts from IPs listed on spam blacklists was reverted today with https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/464819/ so I'll transition this to resolved.