[Standards] XEP-0203 (Delayed Delivery): Rules for servers to discard <delay/> with from matching their domain

Jonas Wielicki jonas at wielicki.name
Sun Dec 10 16:38:18 UTC 2017

Dear list,

While working on the MUC join history support in aioxmpp, I stumbled across 
the fact that all server implementations I tested (they have been notified) do 
not strip <delay/> elements, even if the @from matches the domain of the MUC 

This is against a SHOULD in XEP-0203:

> Although the recipient's server SHOULD discard a delayed delivery notation 
whose 'from' attribute matches the server's JabberID (or return a <not-
acceptable/> error to the originator) […]

When discussing the issue with the developers, we came to the conclusion that 
the SHOULD is not tremendously useful, since clients can not rely on this. We 
thought that it would be good to have a mechanism like for XEP-0359 (Unique 
and Stable Stanza IDs) <stanza-id/> elements. The wording would be something 
like this:

> If an entity exposes disco#info <feature/> "urn:xmpp:delay", it MUST either 
strip <delay/> elements with a @from matching their address from all stanzas 
they process or reject those stanzas with <not-acceptable/>. It MUST NOT 
forward stanzas with a <delay/> with a @from matching their address.

This would allow MUC services to expose that feature and clients could know 
that they are safe against clients spoofing history (of course, there’s still 
no certainty that no entity which sits between the MUC service and the client 
didn’t forge the timestamp, but that’s usually only the MUC service’ server 
and the users server, both of which the client has to trust anyways to 
interact with the MUC in a meaningful manner).

(Since XEP-0203 is Final, I wanted to hear the list before proposing a wording 
via a PR.)

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171210/7faa4438/attachment.sig>

More information about the Standards mailing list