XMPP Service Operators - 2019-05-27

I'm receiving 503-cancel error bounces for typing notifications, which were sent to the bare JID of a 404.city (ejabberd 18.12) user. Is that default ejabberd behavior or some weird misconfiguration?

<message id="7166059f-5b20-450e-bc7d-af127b4b2ed6-25FD6" type="error" from="******@404.city" to="georg@yax.im/poezio-****" xml:lang="en"> <composing xmlns="http://jabber.org/protocol/chatstates"/> <error type="cancel" code="503"> <service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/> <text xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" xml:lang="en">User session not found</text> </error> </message>

holger (lowercase or uppercase), do you have a clue?

Ge0rG: This is probably 0198 timeout, behavior depends on config and on the client supporting MAM.

Shouldn't happen in most™ cases.

Holger: the errors come immediately after the CSN

That would be very atypical for 0198

Ah yes sorry, 0198 would be 'User session terminated'.

Sorry yes depends on config but default is to not write CSN to offline storage, in which case they'll be bounced.

This is weird.

I’ve seen that same behaviour on many spammer JIDs.

So it sounds like a bad default.

Link Mauve: spammers bounce CSNs?

Ge0rG, they are most likely disconnected by the time I send them a CSN, and it’s the host server replying.

Link Mauve: I know you have weird hobbies, but sending CSNs to spammers!?! 😁

By now I remember adding that behavior myself for 0160 compliance.

> Messages with a 'type' attribute whose value is "chat" SHOULD be stored offline, with the exception of messages that contain only Chat State Notifications (XEP-0085) [7] content (such messages SHOULD NOT be stored offline).

So how would the non-weird behavior be then?

TIL

Store offline or drop silently?

Or just check whatever Prosody does :-P

Holger: if you have a special rule for CSN-only messages: drop them silently

But why?

How does an error hurt?

XMPP is generating too few and too bad errors, not too many.

Uh-oh. I'm having some significant lag. Looks like yax.im will go down today

> For a message stanza of type "normal" or "chat", the server SHOULD either (a) add the message to offline storage or (b) return a stanza error to the sender, which SHOULD be <service-unavailable/>.

I should violate another SHOULD because?

Holger: 12:01:53 *****@404.city: 503 - cancel: User session not found 12:02:20 Ge0rG> Hey there! 12:02:28 *****@404.city: 503 - cancel: User session not found 12:02:41 *****@404.city: 503 - cancel: User session not found 12:02:56 *****@404.city: 503 - cancel: User session not found 12:03:07 *****@404.city: 503 - cancel: User session not found 12:03:13 *****@404.city: 503 - cancel: User session not found 12:03:30 *****@404.city: 503 - cancel: User session not found 12:03:33 Ge0rG> [some more text] 12:03:55 *****@404.city: 503 - cancel: User session not found

Looks like weird client error reporting to me.

Holger: so should a client suppress error messages?

XMPP is displaying too few and too bad errors, not too many.

XMPP 2.0 will solve all our problems

Yes I think it should not expose errors that way.

Holger: I'm sure you have an alternative proposal.

Well for <message/> bounces, I think clients should add an indicator to the displayed outgoing message. If the error doesn't map to a displayed message and the client has no other reason to process it, drop it (apart from debug logging).

"My client blindly throws all errors verbatim to the user" doesn't sound like a good reasoning for servers violating SHOULD clauses by adding special-casing to the code, to me.

But yes I don't really like the special-casing of CSN in 0160 in the first place, either.

Holger: just change the special-casing to silently drop CSNs.

Holger: I think there is some value in diplaying errors that don't directly map to a sent message-with-a-body

Yes if it's obvious no client will ever be interested in that error under any circumstances that should be added to 0160. It's not immediately obvious to me, sorry.

Holger: CSNs are ephemeral

so silently dropping them is not damaging IMO

In XMPP 2.0, they will be replaced by directed presence.

> I think there is some value in diplaying errors that don't directly map to a sent message-with-a-body Then clients should inspect the error. I'm aware the original stanza is not always included, for whatever reason. In the case where it isn't there's obviously just so much the client can do.

Holger: can you fight this out with the poezio devs? ;)

:-)

MCabber isn't much better but at least doesn't display those errors inline but in a separate status buffer, so they don't annoy me.

While I'm fixing resource locking in profanity...

Holger: I hope you won't ever not see a _relevant_ error message in that status buffer

No errors that *can* be mapped to outgoing messages actually do produce a proper indication inline (plus the error in the status buffer).

So it's mostly fine; I just meant that I don't really want my status buffer being spammed with CSN errors and similar either.

So what am I supposed to do now to fix it?

I'm not being lazy but really not convinced this should be changed server-side, sorry.

The admin can also configure mod_offline not to store *any* message without body. Should I drop them all in that case? Or still special-case CSNs?

Holger: special-case CSN

:-(