XMPP Service Operators - 2021-10-11

How do you, as a user and/or an operator, deal with incoming subscription requests that look like activity probes, particularly with Prosody? Simply rejecting would let them know that the account is active, but keeping them leads to a growing list of spammers/requests on each login. The options I'm considering are manual editing of Prosody's roster/<user>.dat and blacklisting outgoing packets to servers in question before rejecting them, but both seem quite awkward (and not usable by non-administrators). I do report those, but even if/when new requests cease to arrive after that, there's no way to be sure that rejecting old requests won't notify the spammers.

defanor: I think adding the sender to the blocklist (XEP-0191 iirc) and then rejecting should no cause a notification to them

jonas’, oh, neat, didn't know it blocks outbound stanzas too. The XEP doesn't mention that though, does it?

Ah, it does. "If the user attempts to send an outbound stanza to the JID, the user's server MUST NOT route the stanza to the JID but instead MUST return a <not-acceptable/> error containing an application-specific error condition of <blocked/> qualified by the 'urn:xmpp:blocking:errors' namespace"

(That's a blocked JID it talks about, AIUI.)

okay so prosody even removes the pending request from its storage, no need for the user to reject

afaict it will not send a stanza to the blocked user for that

https://hg.prosody.im/trunk/file/tip/plugins/mod_blocklist.lua#l133

and: https://hg.prosody.im/trunk/file/tip/plugins/mod_blocklist.lua#l202

(the original reason being that the outbound routing block code was too strict and even prevented to rejection from being effective locally; hence the auto-removal of the pending request)

FWIW rejecting an incoming subscription request should not notify the sender, even without blocking

The stuff in Prosody's blocking was added because after blocking someone it became impossible to reject the subscription request

And it makes no sense to keep a pending request for a JID you block

MattJ: "should not" as in "it does in XMPP, but it's not how it should be"?

defanor: the XMPP specification says the sender should not be notified

MattJ: oh, I was looking for that specifically before, and didn't find that. And with Prosody they are notified.

defanor: https://datatracker.ietf.org/doc/html/rfc6121#page-40

> If the user's bare JID is not yet in the contact's roster or is > in the contact's roster with a state of "None", "None + Pending > Out", or "To", the contact's server SHOULD NOT route or deliver > the presence stanza of type "unsubscribed" to the user and MUST > NOT send presence notifications of type "unavailable" to the user > as described below.

Indeed, thanks. I was quite sure that Prosody does it though, will check again.

defanor: if you find that to be the case please report it

Hmm, a quick glance at the code doesn't look promising

I've checked again, it still looks like it does route those. Will report, then.

I think this may be because at the time this code was written, the latest XMPP spec was RFC 3921, which does not have this text (it actually says you MUST notify the sender)

Things like this were why I frowned on other servers that claimed to support both RFCs :)