有无可能在非IOS系统上实现苹果为网易/腾讯邮箱做的实时推送

研究了下有无可能在Android上实现识别XAPPLEPUSHSERVICE从而做到Push Mail。
发现虽然Apple公布了push-service的源码：cmd-x-apple-push-service.c,但这不够，
有一些库例如APNS或者PyAPNS使用了gateway.push.apple.com我们无法使用。

这里当做了解，做一下简单地介绍：
苹果为邮箱应用做的推送服务（APNS，Apple Push Notification Service）与IOS系统所有其他的推送通知一样,
移动设备端与苹果的APNS Gateway间维持了一个持久的连接。
为了通过APNS传输一个推送通知，发送者需要一个苹果为接受应用（邮箱客户端）发行的认证。这个认证可以通过
LionServer获得。LionServer使用dovecot（一个Linux/UNIX端的开源的IMAP、POP3服务器）。

整个推送的基本流程为：
1. Dovecot发行了XAPPLEPUSHSERVICE Capability
2. 当移动设备登录进IMAP Server并且发现它支持这个Capability，移动设备端在服务器上注册了推送通知，并且提供了
   它的设备ID和相关邮箱账号的ID。这两个ID被用于服务器定向于这个设备。
3. 服务器记录了某个账号下的所有设备。当这个账号接收到一个新邮件时，它传出一个推送通知。
4. 设备本身并不直接在服务器端注销某个账号，二是通过APNS的反馈机制来完成。它通知ServiceProvider这个设备
   不再需要接受推送了。

注意：真正传送推送通知给APNS Server的并不是dovecot，而是一个单独的程序。这个有兴趣的同学可以继续往下深入地
研究下。

结论：无法在非IOS的系统上实现XAPPLEPUSHSERVICE模式的邮件自动推送。

附

各大主流免费邮箱的IMAP协议的CAPABILITY：

Gmail
["CAPABILITY", "IMAP4rev1", "UNSELECT", "IDLE", "NAMESPACE", "QUOTA", "ID", "XLIST", "CHILDREN", "X-GM-EXT-1", "XYZZY", "SASL-IR", "AUTH=XOAUTH", "AUTH=XOAUTH2", "AUTH=PLAIN", "AUTH=PLAIN-CLIENTTOKEN"]

QQ
["CAPABILITY", "IMAP4", "IMAP4rev1", "IDLE", "XAPPLEPUSHSERVICE", "AUTH=LOGIN", "NAMESPACE", "CHILDREN", "ID", "UIDPLUS"]

163
["CAPABILITY", "IMAP4rev1", "XLIST", "SPECIAL-USE", "ID", "LITERAL+", "STARTTLS", "XAPPLEPUSHSERVICE", "UIDPLUS", "X-CM-EXT-1"]

126
["CAPABILITY", "IMAP4rev1", "XLIST", "SPECIAL-USE", "ID", "LITERAL+", "STARTTLS", "XAPPLEPUSHSERVICE", "UIDPLUS", "X-CM-EXT-1"]

sina
#null# ["CAPABILITY", "IMAP4REV1", "IDLE", "ID", "UIDPLUS"]

yahoo
["CAPABILITY", "IMAP4rev1", "ID", "NAMESPACE", "X-ID-ACLID", "UIDPLUS", "LITERAL+", "CHILDREN", "XAPPLEPUSHSERVICE", "XYMHIGHESTMODSEQ", "AUTH=PLAIN", "AUTH=LOGIN", "AUTH=OAUTH2", "AUTH=XYMCOOKIE", "AUTH=XYMECOOKIE", "AUTH=XYMCOOKIEB64", "AUTH=XYMPKI"]

可以看出Gmail, qq, sina都支持IMAP IDLE

                网易，腾讯和雅虎邮箱都支持XAPPLEPUSHSERVICE模式的苹果推送。

APNS

Apple Push Notification Service

Apple Push Notification service (APNs for short) is the centerpiece of the push notifications feature. It is a robust and highly efficient service for propagating information to iOS and OS X devices. Each device establishes an accredited and encrypted IP connection with the service and receives notifications over this persistent connection. If a notification for an application arrives when that application is not running, the device alerts the user that the application has data waiting for it.

Software developers (“providers”) originate the notifications in their server software. The provider connects with APNs through a persistent and secure channel while monitoring incoming data intended for their client applications. When new data for an application arrives, the provider prepares and sends a notification through the channel to APNs, which pushes the notification to the target device.

In addition to being a simple but efficient and high-capacity transport service, APNs includes a default quality-of-service component that provides store-and-forward capabilities. See “Quality of Service” for more information.

“Provider Communication with Apple Push Notification Service” and “Scheduling, Registering, and Handling Notifications” discuss the specific implementation requirements for providers and iOS applications, respectively.

A Push Notification and Its Path

Apple Push Notification service transports and routes a notification from a given provider to a given device. A notification is a short message consisting of two major pieces of data: the device token and the payload. The device token is analogous to a phone number; it contains information that enables APNs to locate the device on which the client application is installed. APNs also uses it to authenticate the routing of a notification. The payload is a JSON-defined property list that specifies how the user of an application on a device is to be alerted.

Note: For more information about the device token, see “Security Architecture”; for further information about the notification payload, see “The Notification Payload.”

The remote-notification data flows in one direction. The provider composes a notification package that includes the device token for a client application and the payload. The provider sends the notification to APNs which in turn pushes the notification to the device.

When a provider authenticates itself to APNs, it sends its topic to the APNs server, which identifies the application for which it’s providing data. The topic is currently the bundle identifier of the target application.

Figure 3-1  A push notification from a provider to a client application

Figure 3-1 is a greatly simplified depiction of the virtual network APNs makes possible among providers and devices. The device-facing and provider-facing sides of APNs both have multiple points of connection; on the provider-facing side, these are called gateways. There are typically multiple providers, each making one