Subject: [imapext] IMAP NOOP Command Query

From: Nigar Sultana <[email-masked]>
Date: Thu, 12 Sep 2013 14:28:29 +0800 (SGT)

Hello All,

Can NOOP be used to Keep the long-lived connection session Alive? In case if 3rd party application prefers to have long-lived connection and when it sends NOOP command to IMAP server can the server just do a tagged acknowledgement. Does this violate the specification, because the specification also describes the response to NOOP will have the status of the mailbox. Here 3rd party application will only store content in end user mailbox, 3rd party application will not have mailbox of its own. 

For example:
C: a002 NOOP

S: a002 OK NOOP completed   

Reference of NOOP in RFC 3501: The NOOP command always succeeds. It does nothing. Since any command can return a status update as untagged data, the
NOOP command can be used as a periodic poll for new messages or message status updates during a period of inactivity (this is the
preferred method to do this). The NOOP command can also be used to reset any inactivity autologout timer on the server.

Regards
Nigar S

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 12 Sep 2013 09:32:06 +0200

On Thu, Sep 12, 2013 at 02:28:29PM +0800, Nigar Sultana wrote:
> Can NOOP be used to Keep the long-lived connection session Alive?

Yes.

What you want is to not issue any SELECT command. NOOP (and IDLE) work
without SELECT.

Arnt

---

From: Nigar Sultana <[email-masked]>
Date: Thu, 12 Sep 2013 15:53:18 +0800 (SGT)

Thanks Arnt

RFC 3501 specifies the response of NOOP will have the message status updates of mailbox. If we use this only for Keep alive of long lived connection, for example:
C: 000A NOOP
S: 000A OK NOOP completed

even when there are new messages on mailbox, the response will not have those details displayed. Does it mean we are violating the specification?

Regards

Nigar Sultana

________________________________
 From: Arnt Gulbrandsen <[email-masked]>
To: Nigar Sultana <[email-masked]> 
Cc: [email-masked] 
Sent: Thursday, 12 September 2013 1:02 PM
Subject: Re: [imapext] IMAP NOOP Command Query

Yes.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 12 Sep 2013 10:20:20 +0200

If you issue SELECT first, then the server is required to give you
starus updates for the selected mailbox when you issue NOOP. If you do
not issue SELECT, there is no selected mailbox, so a NOOP command only
keeps the connection alive, it has no other effect.

Arnt

---

From: Brandon Long <[email-masked]>
Date: Thu, 12 Sep 2013 10:25:53 -0700

What's the point of IDLE without select?  I thought it wasn't allowed
though looking at rfc 2177 again I see there is no explicit statement of
what state its allowed in.  I know at least one client issues it in the
authenticated non-selected state, and had assumed it was a bug.

I don't have the code in front of me, but I'm willing to bet gmail returns
an invalid state response.  Easy enough to change, though again don't
really see the point.

Brandob
On Sep 12, 2013 1:19 AM, "Arnt Gulbrandsen" <[email-masked]>
wrote:

> _______________________________________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/imapext
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 12 Sep 2013 20:39:34 +0200

On Thu, Sep 12, 2013 at 10:25:53AM -0700, Brandon Long wrote:
> What's the point of IDLE without select?

It's not terribly useful. AIUI, it's permitted in authenticated state
because there didn't seem to be any problems with that and it might
come in useful later, perhaps combined with some other extension.

> I thought it wasn't allowed
> what state its allowed in.

Section four.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Sep 2013 23:12:33 +0100

On 12/09/2013 18:25, Brandon Long wrote:
> though looking at rfc 2177 again I see there is no explicit statement 
> of what state its allowed in.  I know at least one client issues it in 
> the authenticated non-selected state, and had assumed it was a bug.
>
> I don't have the code in front of me, but I'm willing to bet gmail 
> returns an invalid state response.  Easy enough to change, though 
> again don't really see the point.
>
Maybe unsolicited LIST responses? But yes, without another 
[not-yet-defined] extension, there is not much point.
>
> Brandob
>
> On Sep 12, 2013 1:19 AM, "Arnt Gulbrandsen" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

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

Hello All,

we have to design an IMAP server that can be deployed at multi site. there are certain design challenges like: Mail box management for end user. 

If we go with Active Site -Standby Site mode of IMAP server deployment, then the traffic / mailbox management will be on Active site servers however the design overloads the servers.

If we go with Active Site -Active Site mode of IMAP server-deployment, then the traffic gets distributed across multi site IMAP server. So in that case the mail box management for end user is distributed across site. Can mail box management be distributed across site? Is their any IMAP specification which talks about distributed mail box management?

Regards
Nigar Sultana

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Sep 2013 13:54:45 +0100

Nigar Sultana <[email-masked]> wrote:
>
> Can mail box management be distributed across site? Is their any IMAP
> specification which talks about distributed mail box management?

We use Cyrus as our IMAP server software. We use a proxy in front to split
the mailstore into shards: when a user logs in the proxy looks up which
IMAP server holds their mail and proxies the connection to that server. We
can add more shards for more capacity. Our proxy was written by my
colleague David Carter, but you can use perdition or nginx to do this kind
of job. This setup restricts shared mailboxes because they don't work for
users on different shards - we just don't use them at all.

We also have master/slave replication. This is just to keep backup copies
of mail across multiple sites - it isn't for extra capacity.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 17 Sep 2013 14:00:52 +0100

> of mail across multiple sites - it isn't for extra capacity.

Right; but Cyrus also does "murder" - a method for making this a little
more seamless - and there's also RFC 2193 which, if supported by the
client, lets the client do the heavy lifting of switching between servers
as needed.

Finally, if we're mentioning specific implementations, I know that Isode
M-Box will operate off NFS stores, and also do mailbox replication, too, I
think. Isode is my ex-employer, though I didn't work on M-Box for the last
few years I was there. I'm sure there are similarly capable products
available.

Dave.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 17 Sep 2013 09:13:45 -0400

> specification which talks about distributed mail box management?

Here at CMU, we use our Cyrus server software in a "murder" (cluster) 
configuration where we have mailboxes split across anywhere from 7 to 10 
backend servers (depending on maintenance, etc).  A couple of those 
backend servers are on our campus in Qatar.  Obviously, all of the users 
in Qatar have their personal mailboxes on the local servers, but they 
also have access to any shared mailboxes on the Pittsburgh servers due 
to our use of the MUPDATE protocol and the intelligence of our proxys.

We also replicate the mailboxes to an off-site DR facility.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Sep 2013 14:13:55 +0100

Dave Cridland <[email-masked]> wrote:
> more seamless ...

... which is an implementation of the MUPDATE protocol, RFC 3656. The
advantage is you can have cross-shard shared mailboxes; the reason we
don't use it is it is much more complicated, and if the MUPDATE server
fails your users can't create / rename / delete mailboxes.

Tony.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 17 Sep 2013 09:24:50 -0400

I'd really like to ask that this and similar threads be moved off this
mailing list, where it doesn't belong, to the <[email-masked]>
list, where it does.  This list is for discussing the development of
IMAP and extensions to it.  <[email-masked]> is for
discussing how the protocol is supposed to work.  The imap-use list is for
discussing how to deploy and use IMAP, and specific use cases.

We have active protocol development on this list; let's please not detract
from that with discussions that are better done on other lists.

Thanks,
Barry, Applications AD

On Tuesday, September 17, 2013, Nigar Sultana wrote:

>
> Hello All,
>
> we have to design an IMAP server that can be deployed at multi site. there
> are certain design challenges like: Mail box management for end user.
>
> If we go with Active Site -Standby Site mode of IMAP server deployment,
> then the traffic / mailbox management will be on Active site servers
> however the design overloads the servers.
>
> If we go with Active Site -Active Site mode of IMAP server-deployment,
> then the traffic gets distributed across multi site IMAP server. So in that
> case the mail box management for end user is distributed across site. Can
> mail box management be distributed across site? Is their any IMAP