Subject: [imapext] RFC 3501 - IMAP CREATE

From: Nigar Sultana <[email-masked]>
Date: Tue, 10 Sep 2013 16:58:39 +0800 (SGT)

Hello All,

We have to design IMAP server which allows a third party application to store the messages on behalf of end user. 

If we use "CREATE" command as per spec (RFC 3501) then IMAP server processing becomes heavy because it should parse the path and then store the messages in user's mailbox and we should also have the parsing logic to distinguish whether the connection is from third party or end user.

Is there an "extension CREATE" commands where the third party can indicate the "end user information" and "mail box path" in separate arguments
Example: CREATE [email-masked] INBOX/TemporaryFolder

As an alternate option can we implement IMAP extension commands prefixed with "X"

Regards
Nigar S

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Sep 2013 11:20:03 +0100

> Hello All,
Hi,
> We have to design IMAP server which allows a third party application 
> to store the messages on behalf of end user.
>
> If we use "CREATE" command as per spec (RFC 3501) then IMAP server 
> processing becomes heavy because it should parse the path and then 
> store the messages in user's mailbox and we should also have the 
> parsing logic to distinguish whether the connection is from third 
> party or end user.

I am not entirely sure what you are trying to do, but I think 
http://www.rfc-editor.org/rfc/rfc2342.txt (IMAP NAMESPACE) should solve 
your problem.

> Is there an "extension CREATE" commands where the third party can 
> indicate the "end user information" and "mail box path" in separate 
> arguments

Using a namespace prefix, this can become something like this (you can 
pick a different prefix):
CREATE "Other Users/[email-masked]/INBOX/TemporaryFolder"

> As an alternate option can we implement IMAP extension commands 

Probably not a good idea.

Best Regards,
Alexey

---

From: Dave Cridland <[email-masked]>
Date: Tue, 10 Sep 2013 11:20:04 +0100

On Tue, Sep 10, 2013 at 9:58 AM, Nigar Sultana
<[email-masked]>wrote:

> We have to design IMAP server which allows a third party application to
> store the messages on behalf of end user.
>
>
I'm not sure I understand the problem. Storing messages in IMAP is done by
the APPEND command, not the CREATE command, so I'm assuming your problem
here is that you also need to create empty mailboxes for other users, and
access other users' mailboxes.

> processing becomes heavy because it should parse the path and then store
> the messages in user's mailbox and we should also have the parsing logic to
> distinguish whether the connection is from third party or end user.
>
> Is there an "extension CREATE" commands where the third party can indicate
> the "end user information" and "mail box path" in separate arguments
I think what you're looking for is in part the NAMESPACE extension, and
more generally, accessing other users' mailboxes. Cyrus, for example,
allows this by referring to a user's mailboxes using a prefix to the path.
Given "example-user", their INBOX is visible to anyone with sufficient
rights as "user.example-user", and their "INBOX.personal" as
"user.example-user.personal".

Then everything should "just work" for you.

Dave.

---

From: Nigar Sultana <[email-masked]>
Date: Tue, 10 Sep 2013 21:10:42 +0800 (SGT)

Dear Alexey and Dave,

In my previous mail might be i have not given the complete scenario. thanks for the response.

Following are the elements that connect to IMAP server. "3rd party application" and "end user through mobile" 

The scenarios IMAP server should support is: 
1. 3rd party application can store messages on IMAP server on behalf of end user, in end user mailbox (it should be in user's default folder). 
example: end user has done messaging through mobile and those messages 3rd party application should store in user mailbox. Each message sent in a particular session should be a folder. End user here - User-A and the hierarchy of storage structure should be: 
User-A->defaultFolder->session1->Msg1......Msgn
User-A->defaultFolder->session2->Msg1.......Msgn
Here session1 and session2 is folder. Msg1 to Msgn are messages

2. End user through mobile can access to mailbox and sync those message in case of multi-device. Additional functionality can be end users can also create user-folders and copy the messages from default-folders

Now to achieve scenario#1: 3rd party application should first create the folder in end user's mailbox and then do an APPEND to store the messages in users mailbox (example is given above). The IMAP server what we are planning to design will not explicitly create end user folder, instead will have the mapping to link to user's default folder mailbox. So when the 3rd party application will use CREATE command (as per RFC 3501) then IMAP Server should do the parsing, if parsing is introduced then the process becomes heavy, this is what the opinion our team has. So is there any easy step which can be used to simplify the processing on IMAP server???. If we use the NAMESPACE does it simplify???

spec wise if we go then the command will be:
CREATE /User-A/defaultFolder/session1
APPEND mailbox {length} message

Is there any other method where we can split the mailbox path into "UserId + mailbox path" like: so that the process need not do parsing and hence the process will not become heavy:
CREATE User-A /defauleFolder/session1
APPEND User-A mailbox 

So our team were of opinion to introduce IMAP extension to CREATE and APPEND. for this response i got from Alexe is not a good idea

Can we solve this with the use of NAMESPACE? 

Regards
Nigar S 

________________________________
 From: Alexey Melnikov <[email-masked]>
To: Nigar Sultana <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Tuesday, 10 September 2013 3:50 PM
Subject: Re: [imapext] RFC 3501 - IMAP CREATE

Hello All,
Hi,

>If we use "CREATE" command as per spec (RFC 3501) then IMAP server processing becomes heavy because it should parse the path and then store the messages in user's mailbox and we should also have the…
I am not entirely sure what you are trying to do, but I think http://www.rfc-editor.org/rfc/rfc2342.txt (IMAP NAMESPACE) should solve your problem.

>Example: CREATE [email-masked] INBOX/TemporaryFolder
Using a namespace prefix, this can become something like this (you
    can pick a different prefix):
CREATE "Other Users/[email-masked]/INBOX/TemporaryFolder"

Best Regards,
Alexey

---

From: Timo Sirainen <[email-masked]>
Date: Tue, 10 Sep 2013 16:33:09 +0300

On 10.9.2013, at 13.20, Dave Cridland <[email-masked]> wrote:

> I think what you're looking for is in part the NAMESPACE extension, and more generally, accessing other users' mailboxes. Cyrus, for example, allows this by referring to a user's mailboxes using a prefix to the path. Given "example-user", their INBOX is visible to anyone with sufficient rights as "user.example-user", and their "INBOX.personal" as "user.example-user.personal".

Annoyingly that's not very portable. A human could parse LIST output of a shared namespace's mailboxes, but programmatically it's fuzzy. Especially if you want to access a shared mailbox when none are in LIST output. For example if I want to access [email-masked] user's INBOX, there are quite a lot of possibilities depending on the server:

1) user/ prefix:
 - user/[email-masked]
 - user/[email-masked]/INBOX
 - user/iki.fi/timo.sirainen
 - user/iki.fi/timo.sirainen/INBOX

2) user. prefix:
 - [email-masked] (practically unusable)
 - user.timo_sirainen@iki_fi (or some other variant of escaping the dot)
 - and the /INBOX suffix variants of them

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Sep 2013 18:36:48 +0100

On 10/09/2013 14:33, Timo Sirainen wrote:
> Annoyingly that's not very portable. A human could parse LIST output of a shared namespace's mailboxes, but programmatically it's fuzzy. Especially if you want to access a shared mailbox when none are in LIST output.
IMHO, non listable mailboxes are evil. NAMESPACE should provide all 
necessary information for other (normal) cases.
> For example if I want to access [email-masked] user's INBOX, there are quite a lot of possibilities depending on the server:
>
> 1) user/ prefix:
Right, there is no standard encoding rules for hierarchy delimiter. But 
maybe use Modified-UTF-7?