[Standards] MUC Spam and MUC invites

Dave Cridland dave at cridland.net
Thu Sep 6 09:44:51 UTC 2007


On Thu Sep  6 00:27:33 2007, Peter Saint-Andre wrote:
> One benefit of Dave's way is that it meshes with the original  
> reason for
> invites to go through the room (e.g., permissions check to determine
> that the invitor is allowed to send invitations, room adds invitee  
> to
> the member list if the room is members-only).

Actually, the room doesn't need to add the invitee to a member's  
list, yet - it can wait until the ticket is presented.

>  So I'd prefer Dave's
> approach. But I haven't had a chance to look at RFC 4467 yet...

The short version of RFC 4467 is:

The email client (MUA) constructs an IMAP URL to the content it  
wishes to pass on. (IMAP URLs can point to a specific message part).  
It then appends an extra portion describing the actor allowed to use  
it, and an optional expiry timestamp. This actor can be "anyone", or  
"an authorized user of the IMAP store", or "the submission server  
when it claims I'm using it", etc.

It then requests that this be signed by the IMAP server in some  
opaque manner. Typically, this is done by using a secret key known  
only to the server, and constructing an HMAC. The signature is then  
appended to the URL, forming a signed URL. This "authorized URL" is  
then handed back to the MUA.

The MUA typically uses this when submitting a message using BURL (RFC  
4468), where it sends the authorized URL instead of the message  
content, and the submission server can then obtain the content by  
requesting the URL resolution from the IMAP server, and insert it  
into the message.

Just as with what I've proposed, the entity which normally enforces  
authorization continues to do so, and the pawn ticket, if snooped on  
the wire or passed on, won't be of (much) use.

So what you'd end up with is that the initial invitation is sent to  
the room for signing, something like:

(Adapted from) Example 46. Occupant Sends an Invitation for signing  
to Room

<iq id='invite_1' type='get'
    from='crone1 at shakespeare.lit/desktop'
    to='darkcave at macbeth.shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <invite to='hecate at shakespeare.lit'/>
  </x>
</iq>

(New) Example 46.5. Room returns signed invitation to invitor:

<iq id='invite_1' type='result'
    to='crone1 at shakespeare.lit/desktop'
    from='darkcave at macbeth.shakespeare.lit'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <!-- Identical invitation -->
    <invite to='hecate at shakespeare.lit'/>
    <!-- Opaque implementation-specific ticket,
    probably HMAC of from, to, and the room. -->
    <ticket xmlns='urn:some:namespace'>ajkscnduusvnsd</token>
  </x>
</iq>

(Adapted from) Example 47. Invitor sends signed Invitation to Inviter

<message
    to='hecate at shakespeare.lit'
    from='crone1 at shakespeare.lit/desktop'>
  <body>You have been invited to darkcave at macbeth</body>
  <x xmlns='urn:some:namespace'>
    <invite xmlns='http://jabber.org/protocol/muc#user'       
room='darkcave at macbeth.shakespeare.lit'>
      <reason>
        Hey Hecate, this is the place for all good witches!
      </reason>
    </invite>
    <ticket xmlns='urn:some:namespace'>ajkscnduusvnsd</token>
  </x>
</message>

Expiry timestamps would be nice, too.

There's probably neater ways of expressing this in XML.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list