[Standards] Call for Experience: XEP-0203 (Delayed Delivery)

Peter Saint-Andre stpeter at stpeter.im
Mon Aug 24 20:01:07 UTC 2009

Hash: SHA1

On 8/13/09 3:19 AM, Sergei Golovan wrote:
> On Thu, Aug 13, 2009 at 1:51 AM, Peter Saint-Andre<stpeter at stpeter.im> wrote:
>> 1. Who has implemented XEP-0203? Please note that the protocol must be
>> implemented in at least two separate codebases (and preferably more).
> Tkabber uses XEP-0203 timestamps as well as XEP-0091 ones (203 is preferrable).
>> 2. Have developers experienced any problems with the protocol as defined
>> in XEP-0203? If so, please describe the problems and, if possible,
>> suggested solutions.
> There is oen problem with all current methods of delayed delivery
> indication. The problem is that any entity may easily forge message
> timestamp. If I send a message with added   <delay
> xmlns='urn:xmpp:delay' stamp='2002-09-10T23:08:25Z'/> then my adressee
> will believe that this is an offline message which were stored on
> server (for several years).
> I'm not sure if it's a serious issue, but surely it worth at least
> security consideration notice.


> As for the solution, I could suggest that any server which routes the
> stanza should add a delay timestamp indicating when it reseived the
> message (with some additional attribute (e.g. router='jabber.org')
> similar to Received header in email. 

Couldn't the sender include such a delay timestamp and thus try to fake
out the recipient? Without signed stanzas (or even parts of stanzas,
ick!) the recipient won't know which entity included the delay data.

> Stripping any delay element from
> all stanzas isn't a solution because they are used legitimately in MUC
> history.

The router could strip any delay data that includes its own address (or
return an error to the sender), but let any other delay data pass
through untouched.


- --
Peter Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Standards mailing list