I discovered yesterday evening that Lemmy.ml is blocking all inbound ActivityPub requests from /kbin instances. Specifically, a 403 'access denied' is returned when the user agent contains "kbinBot" anywhere in the string. This has been causing a cascade of failures with federation for many server owners, flooding the message queue with transport errors.
This doesn't appear to be a mistake; it has been done very deliberately, only on Lemmy.ml. Lemmy.world and other large instances do not exhibit the same behavior. It also isn't a side effect of the bug introduced in Lemmy 0.18. You can observe by sending the following in a terminal
> curl -I --user-agent "kbinBot v0.1" https://lemmy.world/u/test
HTTP/2 200
[...]
> curl -I --user-agent "kbinBot v0.1" https://lemmy.ml/u/test
HTTP/2 403
[...]
> curl -I --user-agent "notKbinBot v0.1" https://lemmy.ml/u/test
HTTP/2 403
[...]
> curl -I --user-agent "placeholder-user-agent" https://lemmy.ml/u/test
HTTP/2 200
[...]
Additional evidence of this not being a Lemmy 0.18 bug:
-
This occurs when making web requests to any location on the Lemmy.ml webserver, not just ActivityPub endpoints.
-
Go to https://fedidb.org/software/lemmy and pick an instance running 0.18.0. Perform the above commands, replacing the URL for Lemmy.ml with that particular instance's address.
If this continues, my instance may need to defederate from Lemmy.ml. This is especially problematic because Lemmy.ml continues to federate information outbound to other kbin instances while refusing to allow inbound communication from them.
Spoofing the user agent is less than ideal, and doesn't respect Lemmy.ml's potential wish to not be contacted by /kbin instances. I don't post this to create division between communities, but I do hope that I can draw awareness to what's going on here. Defederating /kbin instances entirely would even be better than arbitrarily denying access one-way. This said, we should all attempt to maintain a good-faith interpretation until otherwise indicated by the Lemmy developers. It's possibel that this is a firewall misconfiguration or some other webserver-related bug.
Relevant comment from me (#354 - [BUG] Critical errors/failed messages during messenger:consume)
Edits:
-
Yes, people have already tried reaching out to the Lemmy instance admins in their Matrix room with no answer.
-
Someone has posed a question on Lemmy.ml about the block here: https://lemmy.ml/post/1563840
You're making one hell of an assumption here.
Most likely it is a misconfiguration or bug. Or misunderstanding.
People are indeed getting ghosted from Lemmy's Matrix channel, when they report this issue.
I don't think it's assuming anything to say that they deliberately blocked user agents containing the text "kbinbot" (case insensitive). I think it's fairly clear that's exactly what has happened here. Instructions to test as many variations as you want yourself are right in the main post in the thread.
Now, what we cannot say is whether it was done with malicious intent. There's some plausible reasons they might do it that are not malicious.
I think it's assuming a lot to say the things I replied to.
I was more replying to the second paragraph. It's a pretty deliberate configuration choice on the web server.
Ideally it's a config error at the firewall. I saw an interesting idea posed on the lemmy post suggesting that it may have been targeted by a DDoS that used kbinbot in the user-agent string.
Ultimately, it's not happening at a code level, it's absolutely happening at a firewall level (nginx, which, for those who don't understand, is kind of acting like the door lock on your apartment building, where you need to go through the main security before you can get to your own place. Sort of the same idea here). I just spent a bunch of time testing a bunch of various user-agent strings, and it very specifically is matching "kbinbot". No wildcarding within the word, but it a string like "blahbinbotblah" will 403, whereas "blahkbbinbotblah" won't (and various other forms, like k.bin.bot, or kasdfbinasdfbot.)
It's pretty specific. Anyone who deals with firewalls in any capacity understands how nginx works, and specifically why they and others are raising an alarm.
So yeah, ideally it's a misconfiguration, otherwise it's a fairly clear message.