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 :)

Any ideas from the community on why I'm having trouble contacting any servers/JIDs on movim.eu?

I thought it might have been an s2s connection leftover from my old server, but I figured that would have resolved itself by now. Every other server seems fine.

Do you get any error?

@ping movim.eu

Martin: Pong from movim.eu in 0.927 seconds

Haven't checked for any errors, should probably do that. 👍️

That's the first thing you should do. 😃

just started using snikket and am not completely familiar with how everything works yet lol

Outgoing s2s stream pavot.ca->movim.eu closed: error<cancel:not-authorized:certificate has expired>

looks like I was somewhat correct, s2s is to blame.

As reported last week, still cert issues ✏

>As reported last week oh. i must've missed that.

observe.jabber.network says the cert expires in 2022

If you can ping edhelas via other means, pls do...

MattJ: my ejabberd ain't happy...

I'

>edhelas ?

Is the problem with verifying movim.eu's cert, or movim.eu verifying other certs?

sam: the nick of the Movim admin

MattJ: movim.eu

Wait

I sent movim.eu an email

> `[warning] <0.16242.0>@ejabberd_s2s_out:handle_auth_failure/3:233 (tls|<0.16242.0>) Failed outbound s2s EXTERNAL authentication mydomain.tld -> movim.eu (hidden_by_ejabberd): Authentication failed: Peer responded with error: certificate has expired (not-authorized)`

So it blames mine then?

So it doesn't like your cert

Heh

running on ubuntu 16.04? ;)

Probably it needs ca-certificates updating

Bullseye, but cert updated in Aug 21

Licaon_Kter, I meant movim.eu :)

Ah, so there's an issue on movim.eu's end?

(trying hard to follow lol)

looks like it

Looks movim.eu s2s still rely on X3 in provided cert chain: > Certificate chain > 0 s:CN = movim.eu > i:C = US, O = Let's Encrypt, CN = R3 > 1 s:C = US, O = Let's Encrypt, CN = R3 > i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 > 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 > i:O = Digital Signature Trust Co., CN = DST Root CA X3 >