+#### culprit was an Atomicorp ModSecurity rule
+
+Further followup: my provider is using [ModSecurity](https://www.modsecurity.org/)
+with a ruleset commercially supplied by [Atomicorp](https://www.atomicorp.com/products/modsecurity.html),
+which seems to be where this rule came from. They've turned the rule off for _my account_.
+I followed up on my ticket with them, suggesting they at least think about turning it off
+more systemwide (without waiting for other customers to have bizarre problems that are
+hard to troubleshoot), or opening a conversation with Atomicorp about whether such a rule
+is really a good idea. Of course, while they were very responsive about turning it off
+_for me_, it's much iffier whether they'll take my advice any farther than that.
+
+So, this may crop up for anybody with a provider that uses Atomicorp ModSecurity rules.
+
+The ruleset produces a log message saying "turn this rule off if you use libwww-perl", which
+just goes to show whoever wrote that message wasn't thinking about what breaks what. It would
+have to be "turn this rule off if any of _your_ customers might ever need to use or depend on
+an app or service _hosted anywhere else_ that _could_ have been implemented using libwww-perl,
+over which you and your customer have no knowledge or control."
+
+Sigh. -- Chap
+
+> Thanks for the pointer. It seems the open-source ruleset blacklists libwww-perl by default
+> too... this seems very misguided but whatever. I've changed our default User-Agent to
+> `ikiwiki/3.20141012` (or whatever the version is). If we get further UA-blacklisting
+> problems I'm very tempted to go for `Mozilla/5.0 (but not really)` as the
+> next try. --[[smcv]]