[IceWarp 爱思华宝] 论坛

[IceWarp]

IceWarp V9 support PUSH Email via IDLE

The Internet Engineering Task Force (IETF) Open Standard

The concept of "push email" has been widely marketed as a desirable feature of mobile email services, to enable users to get immediate notification of and access to new messages.

This paper looks at various approaches to meeting user requirements, and concludes that the Internet Standard IMAP (Internet Message Access Protocol) IDLE command is the best way to achieve this service.


User Requirements

"Push Email" is an unfortunate choice of terminology, as it implies a specific technical solution to a more generic user requirement. The primary user requirement described by "push email" is:

"Whenever a new message is delivered to my mailbox, I want to be notified 'immediately' that the message has arrived."

'Immediately' in the context of store and forward messaging would typically be interpreted as "a few seconds", rather than hours and minutes. There are some associated secondary requirements that would be addressed by a good solution

The user should have control over message download to the mobile device. A typical choice would be to automatically download small messages, and to download larger messages under user control.

The user should be able to turn off notifications when desired.
The user should have control over which messages lead to notifications (e.g., only for messages from the boss).
Polling

The basic approach used by many email devices is to connect to the server to access new messages. This is a good model for many uses of mobile email, where access to email is under user control ? the user checks email when the user wants to.

In order achieve automatic notification of new messages, a simple approach is to use 'polling' where the mobile client automatically connects to the server at intervals to check for new messages. However, there are two main problems with this approach:

Frequent polling is an inefficient use of network and mobile device resource. It is not a good choice for this reason.
New mail notification is only as frequent at the polling, and not 'immediate'.
Polling is a poor solution for a user needing immediate notification.

IMAP IDLE
IMAP (Internet Message Access Protocol) is the best open standard for accessing mobile email. It handles immediate notification as part of general operations and by the IDLE command, which is a widely implemented standard extension to the core IMAP protocol.

How IDLE Works

IMAP works by the software on the mobile device (the client) issuing commands to the server. An IMAP server provides two things in response to a client command:

An answer to the request.

Information on any new messages.
This means that where a client is actively doing things with an IMAP server, it will be told immediately about new messages. The client can then get summary information on the message to present to the user, and can (automatically) download the message when appropriate.

This means that an active client will always be kept up to date. The IDLE command deals with the situation where the client has no more requests to make. The server responds to the idle command when there is a new message (or messages) which indicates to the client that there are new messages.

When the user is inactive, and does not wish to receive notifications, the client simply stops using IDLE, which is very efficient.

Performance

The basic network use of the IDLE command is very small, and so it makes very efficient use of bandwidth. In practice things are made more complex by the problem of timeouts occuring when there is no activity keeping the connection open. The main timeouts that will occur are:

IMAP server timeout: Typically occurs after 30 minutes with no activity.
NAT Gateway timeout: Most mobile devices access the Internet through a device operated by the mobile service provider called a NAT (Network Address Translation) gateway. These will typically time out an idle connection after 15 minutes.
The solution to this is for the IMAP client to issue a NOOP (No Operation) command at intervals, typically every 15 minutes. This will exchange a few bytes of data, and keep everything active. The impact of holding an IMAP connection open on the client, server and intermediate components should be considered:

IMAP Server. A good IMAP server will have minimal overhead for an Idle connection, and should be able to support 10?s or 100?s of thousands of connections.
IP Routers and other network components. Negligible impact.
Phone. For older phones there could be an issue of increased battery usage due to holding the connection open. This is unlikely to be a problem on a modern phone.
Another practical problem is that current phone networking technology will lose IP network connectivity from time to time, and this will need to be automatically re-established, and the IMAP connection re-established if this is lost due to a long network failure.

In summary, the overall IMAP IDLE architecture has good performance.

'True' Push

An alternative to the IMAP IDLE approach is for a mechanism whereby the server pushes something to the client when a new message arrives, without there being an open connection from the client to the server. This section looks at this approach.

Alert vs Message Send
There are two variants of the 'true' push approach:

Push the new message.
Push a short generic message alert, prompting the client to connect to the server in order to retrieve the message.
Using approach 1 leads to three problems:

The mechanism will need to deal with security and data confidentiality, which leads to a lot of additional complexity.
The data being pushed becomes larger, which reduces the options for sending the data (e.g., SMS could not be used).
There is no client control on the choice to download.
For these reasons, the second approach is generally better, and this is the one considered here.

5.2 Implementation Options

A clean way to send data from the server to the mobile device would be for the server to open a TCP connection. This would give a lot of flexibility in protocol choice and deployment. Unfortunately, this is impractical because most mobile devices do not have registered IP addresses to which a server can connect. They are also generally connected through a NAT gateway that will prevent connections being made to the phone. This means that use of a TCP connection is not generally a viable option.

This means that another mechanism needs to be used to do the 'push'. There are various options to do this. SMS is a good candidate, as it is widely supported as a data listening mechanism on most mobile devices. SMS is used as an example interconnect mechanism in this paper. The use of SMS as the mechanism to carry messaging alerts leads to two integration problems:

Phone. SMS is a general purpose service, not specific to email. There are two integration approaches:
Use a "you?ve got mail" message to the human user, who will then connect with the email application. This crude approach would only be suitable for very basic use.
Standardize how SMS is used, so that phones can detect email notifications and pass them to the email client for automatic processing.
Messaging server. There are two deployment scenarios:
Messaging server deployed by a mobile operator. In this scenario integration with SMS is straightforward.
Messaging server deployed by the end organization or independent service provider. Typically such a deployment will rely on Internet access. Integration with SMS would provide both technical problems (how to make it happen) and commercial problems (who pays for the SMS message, and how to prevent abuse).
These problems are not insurmountable, but will be a barrier to widespread adoption.

Performance
The response time and data use of this push approach are contrasted to IMAP IDLE,
A messaging server offering both approaches would be able to send the push notification and IDLE response at the same time. The IDLE response is immediate, and it will initiate the client to deal with the new messages. The push notification will have two delays:

Time for the SMS message to reach the phone. This may be a few seconds, but could take longer.
Time for the client to connect to the server. This will typically be a few seconds.
True push will be somewhat slower than IMAP IDLE, but in practice this is not likely to be a big problem.
Data usage for IMAP IDLE is essentially the 15 minute NOOP to keep the connection alive, plus a small amount of data to do the notification. The true push will have the cost of the SMS notification. The data for connection establishment is more significant, typically including TCP Connection; TLS (for data confidentiality); client authentication; client (re) synchronization.

It can be seen that for frequent message arrival, that IMAP IDLE is more efficient and that for longer intervals between notifications that true push has better data efficiency. The details will depend on many parameters. A rough calculation suggests that a typical break-even point would be around two days. This suggests that for a typical user receiving and getting notifications for 10 messages per day, that IMAP IDLE has significantly better data performance.

When the user does not want to receive notifications, there is a need to change server configuration (which causes extra complexity and network activity).


Conclusions

IMAP + IMAP IDLE is a good approach for providing the immediate email notification and delivery service of "push email".

It has substantial implementation, deployment and performance advantages over a "true push" approach.

[peter]

what IDLE ?

PLease talk about IDLE .

[IceWarp]

Network Working Group B. Leiba
Request for Comments: 2177 IBM T.J. Watson Research Center
Category: Standards Track June 1997


IMAP4 IDLE command

Status of this Memo

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.

1. Abstract

The Internet Message Access Protocol [IMAP4] requires a client to
poll the server for changes to the selected mailbox (new mail,
deletions). It's often more desirable to have the server transmit
updates to the client in real time. This allows a user to see new
mail immediately. It also helps some real-time applications based on
IMAP, which might otherwise need to poll extremely often (such as
every few seconds). (While the spec actually does allow a server to
push EXISTS responses aysynchronously, a client can't expect this
behaviour and must poll.)

This document specifies the syntax of an IDLE command, which will
allow a client to tell the server that it's ready to accept such
real-time updates.

2. Conventions Used in this Document

In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as described in RFC 2060
[IMAP4].

3. Specification

IDLE Command

Arguments: none

Responses: continuation data will be requested; the client sends
the continuation data "DONE" to end the command



Leiba Standards Track [Page 1]

RFC 2177 IMAP4 IDLE command June 1997



Result: OK - IDLE completed after client sent "DONE"
NO - failure: the server will not allow the IDLE
command at this time
BAD - command unknown or arguments invalid

The IDLE command may be used with any IMAP4 server implementation
that returns "IDLE" as one of the supported capabilities to the
CAPABILITY command. If the server does not advertise the IDLE
capability, the client MUST NOT use the IDLE command and must poll
for mailbox updates. In particular, the client MUST continue to be
able to accept unsolicited untagged responses to ANY command, as
specified in the base IMAP specification.

The IDLE command is sent from the client to the server when the
client is ready to accept unsolicited mailbox update messages. The
server requests a response to the IDLE command using the continuation
("+") response. The IDLE command remains active until the client
responds to the continuation, and as long as an IDLE command is
active, the server is now free to send untagged EXISTS, EXPUNGE, and
other messages at any time.

The IDLE command is terminated by the receipt of a "DONE"
continuation from the client; such response satisfies the server's
continuation request. At that point, the server MAY send any
remaining queued untagged responses and then MUST immediately send
the tagged response to the IDLE command and prepare to process other
commands. As in the base specification, the processing of any new
command may cause the sending of unsolicited untagged responses,
subject to the ambiguity limitations. The client MUST NOT send a
command while the server is waiting for the DONE, since the server
will not be able to distinguish a command from a continuation.

The server MAY consider a client inactive if it has an IDLE command
running, and if such a server has an inactivity timeout it MAY log
the client off implicitly at the end of its timeout period. Because
of that, clients using IDLE are advised to terminate the IDLE and
re-issue it at least every 29 minutes to avoid being logged off.
This still allows a client to receive immediate mailbox updates even
though it need only "poll" at half hour intervals.











Leiba Standards Track [Page 2]

RFC 2177 IMAP4 IDLE command June 1997


Example: C: A001 SELECT INBOX
S: * FLAGS (Deleted Seen)
S: * 3 EXISTS
S: * 0 RECENT
S: * OK [UIDVALIDITY 1]
S: A001 OK SELECT completed
C: A002 IDLE
S: + idling
...time passes; new mail arrives...
S: * 4 EXISTS
C: DONE
S: A002 OK IDLE terminated
...another client expunges message 2 now...
C: A003 FETCH 4 ALL
S: * 4 FETCH (...)
S: A003 OK FETCH completed
C: A004 IDLE
S: * 2 EXPUNGE
S: * 3 EXISTS
S: + idling
...time passes; another client expunges message 3...
S: * 3 EXPUNGE
S: * 2 EXISTS
...time passes; new mail arrives...
S: * 3 EXISTS
C: DONE
S: A004 OK IDLE terminated
C: A005 FETCH 3 ALL
S: * 3 FETCH (...)
S: A005 OK FETCH completed
C: A006 IDLE

4. Formal Syntax

The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
Non-terminals referenced but not defined below are as defined by
[IMAP4].

command_auth ::= append / create / delete / examine / list / lsub /
rename / select / status / subscribe / unsubscribe
/ idle
;; Valid only in Authenticated or Selected state

idle ::= "IDLE" CRLF "DONE"






Leiba Standards Track [Page 3]

RFC 2177 IMAP4 IDLE command June 1997


5. References

[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.

6. Security Considerations

There are no known security issues with this extension.

7. Author's Address

Barry Leiba
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY 10532

Email: leiba@watson.ibm.com

Leiba Standards Track [Page 4]

[IceWarp]

Definition: IMAP IDLE is an optional expansion of the IMAP email accessing protocol that allows the server to send new message updates to the client in real time.

Instead of having your email program check for new mail every few minutes, IMAP IDLE allows the server to notify your email program when new messages have arrived. You can see incoming mail immediately.

[milan]

'Push' Email (via IMAP-IDLE) is the Internet Engineering Task Force (IETF) Open Standard for email on mobile phones.


When there is ongoing activity between the Mobile Phone and the IceWarp Merak Mail server V9, IMAP-IDLE will automatically inform the Mobile Phone of the presence of new email messages.

The IMAP-IDLE command, which is a widely implemented standard extension to the core IMAP protocol and contained within the IceWarp Merak Mail Server V9, ensures that the server will inform the Mobile of new email messages even when there is no other activity taking place between Mobile Phone and Mail server.

IMAP-IDLE maintains the connection by issuing a 'NOOP' command, usually every 15 minutes, to ensure that the connection isn't disrupted by a timeout. The main types of timeouts that usually occur are:



IMAP server timeout: Typically occurs after 30 minutes with no activity.

Underlying TCP connection timeout: Usually after a few hours.
NAT Gateway timeout: Most mobile devices access the Internet through a device operated by the mobile service provider called a NAT (Network Address Translation) gateway. These will typically time out an idle connection after 15 minutes.[/img]

[milan]

NOOP (No Operation) performs no action other than having the server send an 'OK' reply and exchanges a bandwidth efficient few bytes of data.

[mycatboys]

好贴啊 不错啊 谢谢楼主分享 拉 顶一下先







------------------------------------------------------------------------------
世界会向那些有目标和远见的人让路。（上班虚拟主机做网站租用客服时清闲时候的顿悟）