Re: [apps-discuss] Extentions of IMAP4 Tue, 09 August 2011 08:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36C5321F8A30 for <>; Tue, 9 Aug 2011 01:11:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -98.086
X-Spam-Status: No, score=-98.086 tagged_above=-999 required=5 tests=[AWL=-1.651, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_72=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YhW6Rq2rf+8u for <>; Tue, 9 Aug 2011 01:11:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1F67D21F876A for <>; Tue, 9 Aug 2011 01:11:10 -0700 (PDT)
Received: from [] by with surfront esmtp id 152361193944097; Tue, 9 Aug 2011 16:08:54 +0800 (CST)
Received: from [] by [] with StormMail ESMTP id 78343.3634574820; Tue, 9 Aug 2011 16:11:27 +0800 (CST)
Received: from ([]) by with ESMTP id p798BK17038353; Tue, 9 Aug 2011 16:11:20 +0800 (GMT-8) (envelope-from
In-Reply-To: <9031.1311673448.731712@puncture>
To: Dave Cridland <>
MIME-Version: 1.0
X-KeepSent: CA86C160:3B9DB75F-482578E7:00127A9E; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <>
Date: Tue, 9 Aug 2011 16:11:20 +0800
X-MIMETrack: S/MIME Sign by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-09 16:13:50, Serialize by Notes Client on LuYan029354/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-08-09 16:13:50, Serialize complete at 2011-08-09 16:13:50, S/MIME Sign failed at 2011-08-09 16:13:50: ???????, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-08-09 16:11:22, Serialize complete at 2011-08-09 16:11:22
Content-Type: multipart/alternative; boundary="=_alternative 002D3689482578E7_="
X-MAIL: p798BK17038353
Cc: "SHIH, JERRY \(ATTSI\)" <>, "" <>, "" <>, General discussion of application-layer protocols <>
Subject: Re: [apps-discuss] Extentions of IMAP4
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Aug 2011 08:11:13 -0000

Dave Cridland <> 
2011-07-26 17:44

"" <>cn>, General discussion of 
application-layer protocols <>rg>, "" 
<>cn>, "" <>cn>, 

Re: Re: Re: [apps-discuss] Extentions of IMAP4

On Tue Jul 26 09:36:35 2011, wrote:
> > On Fri Jul 22 09:12:35 2011, wrote:
> > > [Yan LU] The intention of this draft is to associate multiple
> > > identities
> > > belonging to one user. Thus, after logging in, the user may 
> choose
> > > one of
> > > these associated identities, under each of which there can be an
> > > INBOX, a
> > > SENTBOX and other folders, as shown in the following figure.
> >
> > OK. In the SASL model, an authentication identifier can have 
> access
> > to many authorization identifiers already; so no change is needed
> > here.
> >
> [Yan LU] As we know, implicit registration has already been 
> supported in
> 3GPP IMS. However,so far, I haven’t found any RFCs where an
> authentication identifier is allowed to be bound with multiple 
> identifiers
> . Could you tell me the specific documents?
All modern SASL mechanisms allow users to supply an optional 
authorization identifier.

> > Mostly because you're not - you're associating authorization
> > identities sequentially, rather than concurrently.
> >
> > You could build on namespaces, incidentally, to achieve much the 
> same
> > goal, by simply defining a standard method for locating other
> > authorization identifiers' INBOXes.
> >
> > But allowing a user to switch authorization identifier mid-flow 
> will
> > almost certainly introduce some complex edge-cases within 
> security -
> > I've a strong feeling that this opens up possibilities for TOCTOU
> > errors.
> >
> [Yan LU] Actually, the idea in the proposed draft is quite similar 
> with
> implicit registration in 3GPP, where it has already been 
> standardized. So,
> we think it is better for the IETF to support the same mechanism.
Just because somebody else has decided to standardize it does not 
mean it's a good idea.

As I say, I think that allowing the authorization identifier bound to 
a session to change will introduce security issues. IMAP, and 
therefore IMAP servers, are built around the notion that the 
authorization identifier is bound at authentication time and 
thereafter invariant.

Breaking that assumption is trivial in theory, but in practise will 
have quite sever impact on server codebases, as well as impact to 
various extensions. For example, it's not at all clear what NOTIFY 
should do when faced with an authorization identifier change.

So at minimum, this draft would need to address every extant 
extensions for IMAP and ensure that it does not introduce security 
issues - but I don't think this is sufficient to eliminate the rather 
more worrying issue that authorization identifiers are considered an 
invariant of a session within the IMAP server codebases.

However, this isn't a problem, as what you can do is standardize the 
NAMESPACE usage and server layout such that it's simple for clients 
to discover the INBOX and personal mailboxes of other authorization 

[Yan LU]Sorry for the late reply for we just came back from an OMA-EVVM 
interim meeting. During the meeting the two proposed drafts were discussed 
by the EVVM Group. The group considered serveral possible solutions, 
including the ones you mentioned in your emails (by the way, thanks very 
much). However, we still think to extend IMAP4 is probably one of the best 

Yes, just as you said, we need to study the influence this extention may 
have on all extensions for IMAP. 

We are waiting for further comments from IETF.

Dave Cridland - -
  - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.