Subject: [apps-discuss] Extentions of IMAP4

From: [email-masked]
Date: Thu, 21 Jul 2011 17:40:25 +0800

Dear All,

We (ZTE, AT&T and China Unicom) are currently working on the 
standardization of the Enhanced Visual Voice-Mail (EVVM) service for the 
Open Mobile Alliance (OMA). Similar to Email services, EVVM is also based 
on the IMAP protocol. According to our research, some requirements (e.g., 
server-initiated service deactivation, multi-account authentication and 
management) proposed for EVVM can be fulfilled easily if we're able to 
make some extensions for the IMAP protocol correspondingly. Thus, we 
prepared 3 internet-drafts and have submitted them to IETF lately. Those 
drafts are expected to serve as the IMAP extensions, and can be accessed 
at:

https://datatracker.ietf.org/doc/draft-jia-imap-multiaccount-authentication/
https://datatracker.ietf.org/doc/draft-lu-imap-multi-account/
https://datatracker.ietf.org/doc/draft-shih-imap-server-logout/

We hope these drafts can be discussed as soon as possible to meet the 
timeline of OMA-EVVM. 

Please feel free to let us know if you have any comments or questions 
regarding those drafts.

Thank you,

Yan LU

--------------------------------------------------------
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.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 21 Jul 2011 11:19:41 +0100

> https://datatracker.ietf.org/doc/draft-jia-imap-multiaccount-authentication/

This one is distinctly hand-wavey, to the extent I have no clear idea  
what it means.

I *think* it means to say that multiple authzids may be associated  
with a single authentication identifier, and these may be active  
concurrently - what this in turn means in terms of, for example, what  
"INBOX" now means is beyond me, though.

> https://datatracker.ietf.org/doc/draft-lu-imap-multi-account/

This one appears to build on the above, except it, too, confuses  
authentication and authorization.

I'm reasonably convinced that the first draft is entirely redundant,  
and this one's utility is limited. In particular, it's not clear to  
me why you'd want this instead of just using multiple authentication  
identifers and multiple connections, and no rationale is given in the  
document.

> https://datatracker.ietf.org/doc/draft-shih-imap-server-logout/

IMAP4rev1 already allows servers to unilaterally terminate the  
session with a * BYE. Introducing server-initiated commands is far,  
far beyond a simple draft like this.

A sensible alternative would be to have servers issue a different  
untagged response (* TERMINATE, perhaps?) in order to encourage  
clients into logging out quickly, if we want to have a more graceful  
termination of client sessions. This would need to be signalled with  
an ENABLE, though.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: [email-masked]
Date: Fri, 22 Jul 2011 16:12:35 +0800

Dear Dave Cridland,

Thank you for your comments. Please see our reply in-line.

Regards,

Yan LU

> "INBOX" now means is beyond me, though.

[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.

User--+--Identity1---+---INBOX
      |         | 
      |         +--- SENTBOX
      |                |
      |         +--- OTHER FOLDERS
      | 
      | 
      +--Identity2---+---INBOX
                       | 
                       +--- SENTBOX
                       |
                       +--- OTHER FOLDERS

> identifers and multiple connections, and no rationale is given in the 

[Yan LU] The reason why we submitted these two drafts separately is that 
the first one can take effect even without implementing the second one. As 
you mentioned, for the second one, the issue can be implemented with 
multiple connections. But from the perspective of the user, it will 
improve the user experience if the user does not have to log in for 
several times.

Let us focus on the multiple-connection solution. First of all, it will 
increase the burden of the network. Secondly, without the first draft, the 
user has to log in for multiple times to establish all the connections, 
which I don't think is a good idea. With the first draft, why not just 
establish one connection for all associated identities?

> termination of client sessions. This would need to be signalled with 

[Yan LU] I agree with you that server-initiated commands can be 
complicated. The intention of this draft is to try to find a way for the 
server to terminate session actively. I am wondering if the BYE response 
can be sent out without corresponding to any previous command from a 
client. Could you provide more details?

---

From: Dave Cridland <[email-masked]>
Date: Fri, 22 Jul 2011 11:16:10 +0100

> 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.

> establish one connection for all associated identities?
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.

> client. Could you provide more details?

Technically, you are able to send almost any response at any time.

Use of BYE in this way is discussed in RFC 3501 §7.1.5, and RFC 3501  
§3.4 discusses servers unilaterally closing connections.

Dave.

---

From: John C Klensin <[email-masked]>
Date: Fri, 22 Jul 2011 08:35:04 -0400

--On Friday, July 22, 2011 11:16 +0100 Dave Cridland
<[email-masked]> wrote:

> OK. In the SASL model, an authentication identifier can have
> access to many authorization identifiers already; so no change
> is needed here.

Let me add one much more general observation to Dave's specific
ones:

IMO, IMAP is arguably already much too big and too complicated,
at least partially due to the addition of features that provide
different ways to do the same thing.  In principle, adding more
optional features should not be a problem, but they make it very
hard for a user to predict what will be available from different
combinations of clients and servers.  That situation, in turn,
makes easy movement among clients on multiple devices less
likely and more difficult.

The LEMOMADE effort was supposed to improve on that situation.
As far as I can call, it did not succeed in that particular
goal; some would claim it made things worse.

To me, the best evidence for "much too big and too complicated"
is the very small number of available, well-designed, IMAP
clients that are fully-conformant to the protocol and up-to-date
on the majority of current features and extensions.  Some years
ago, an important contributor and developer of IMAP and other
email protocols observed that "all IMAP clients suck, <xxx>
sucks less than the others" (name omitted to avoid a distracting
side discussion).   If one adds the criterion that they be
tracking the efforts in the EAI WG that will require
modifications for, e.g.,  non-ASCII addresses, the number goes
down even further.

So, for whatever it is worth, I think the community should be
looking only at additional IMAP changes and extensions for which
there is a compelling need for a large number of users -- a need
that is compelling enough that we can assume that a large
fraction of client and server implementers will actually support
the proposed feature.   I believe the EAI i18n changes meet that
criterion.  These two proposals do not, not just for the reasons
Dave mentions, but because we haven't seen much evidence a huge
number of such users, because there are other ways around the
issue in IMAP (as Dave notes), and because a slightly different
organization of mailboxes and folders on the server (and a
competent client) can accomplish almost exactly the same thing
without any protocol changes at all.   I have some evidence for
the latter: I've been doing things that way, with standard IMAP
(and without a requirement for any of the very recent
extensions), for 15 years or so now.

    john

---

From: [email-masked]
Date: Tue, 26 Jul 2011 16:36:35 +0800

> to many authorization identifiers already; so no change is needed 

[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?

> I've a strong feeling that this opens up possibilities for TOCTOU 
 
[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.

> §3.4 discusses servers unilaterally closing connections.
[Yan LU] I have to admit I neglected these descriptions. I believe BYE can 
meet our requirement. Thanks for the information.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 26 Jul 2011 10:44:08 +0100

On Tue Jul 26 09:36:35 2011, [email-masked] wrote:
> > > belonging to one user. Thus, after logging in, the user may  
> choose
> > > one of
> access
All modern SASL mechanisms allow users to supply an optional  
authorization identifier.

> 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  
identifiers.

Dave.

---

From: [email-masked]
Date: Tue, 26 Jul 2011 17:58:26 +0800

> >> choose   one of

[Yan LU]Well, as the members of OMA, we are focusing on services provided 
for the normal users. Market needs are driving us to propose these drafts. 
Furthermore, we have encountered issues since this feature has not been 
supported by IETF yet. I can provide some examples.
1)According to OMA CPM (Converged IP Messaging) specifications, a CPM 
client consists of a SIP client and a IMAP4 client, and a CPM user will 
use SIP client to realize communications of various forms, e.g. instant 
message, multimedia call or file transfer; a CPM user will also use IMAP4 
client to manage conversation history recorded during the communications. 
The CPM Group introduced 3GPP implicit registration into CPM,that is to 
say, when a user is registered, he/she only has to be registered once for 
his multiple identifiers. After registration, he can choose and use any of 
these identifiers freely. Unfortunately, the user has to log in for 
several times when he/she accesses his storage server. To make it even 
worse, although a user can switch his multiple identifiers when he/she 
communicates with others (using SIP ), he can only use one identifier to 
manage the stored conversation history (using IMAP4). We hope we can 
provide the same user experience in these two procedures.
2)Now we meet the same problem in OMA EVVM. 
3)This feature can be used in some kind of converged email services.It is 
quite possible that one user can have multiple internet email addresses. 
As far as I know, China Telecom has already released their enterprise 
standard in which a mobile user with a IMAP4 client can connect with a 
IMAP4 proxy to access multiple email accounts.