Mobile/Projects/PushImapProxy

Tracking

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Goals

To enable push notification for email while reducing the battery eating alarm+poll pattern.

Schedule

• B2G 1.2 / 1.3

Specifications

General

• IMAP proxy server (REST API -> IMAP)
• Email client changes to support enabling Push Notifications

Server

The server receives user credentials (login information, address of IMAP server) and two push endpoints from the email app. It then logs into the IMAP server with the credentials and starts monitoring the user's inbox for new mail.

Inbox monitoring is done using the IDLE extension to the IMAP protocol where available. The server thus sends an IDLE message and waits for EXISTS messages from the IMAP server, which mean new mail has arrived. Following the recommendation in RFC 2177, the server also restarts idling (that is, sends a DONE and then a new IDLE messages) periodically to prevent disconnects.

Upon detecting new mail, the server sends a push notification through one of the endpoints it received from the app. The other endpoint is used to notify the app that the connection with the IMAP server has been lost; the app should then re-send user credentials so another IMAP session can be started.

• Supports 1M users
• Drop credentials immediately after use
• Prototype: https://github.com/dougt/go-push-mail-proxy

Client

The client email app is responsible for sending the user's credentials to the server, and also for choosing the IMAP server that will be used. It also creates the two endpoints (new mail and reconnect) required by the server, and reacts accordingly to push notifications.

• Opt in, with prompt
• Proof-of-concept: https://github.com/guilherme-pg/gaia

User stories

v1

• User wants to receive email messages as soon as they are delivered (<2 minutes). The user wants to also maximize battery life.

Designs

• mockup

Concerns

• Needs to be run by privacy, security and operations.
• Are we enabling a "phishable" behavior by encouraging users to provide credentials to a third party site?
  • Are there ways that we can provide this sort of service without asking for user primary credentials?

• How do we handle if a given 3rd party server doesn't support IDLE as an option?

• There are limits to the number of outbound socket port connections per machine. Can we do rapid polling on servers to reduce our machine cost?
  • asuth: No. That implies you are keeping the credentials around, and per my discussion with dougt, credentials would be dropped immediately. Also, the "accepted" model for costs is that opening folders is expensive. In practice, it may not be quite as real, but modern servers that support IDLE tend to have a fairly optimized implementation that is very likely to be much preferred over pounding the server. (Accepted in this case is probably unreasonably biased towards sucky implementations like UW-IMAP.)
  • Will we need to be whitelisted by major IMAP providers since we may be hitting their machines thousands of times per second from a small number of IPs?
  • Some email providers (e.g. Yahoo) only allow third party IMAP/POP access for pay only accounts. There may not be a lot of incentive for them to increase service costs to handle this feature.
    • asuth: Can you clarify? Yahoo has opened up IMAP to free users, at least for mobile devices, but they don't implement IDLE, so such a service wouldn't work for them anyways.

• How do we end a connection?
• If I issue a REST request, then issue another REST request a few minutes later, are there now two connections to the IMAP server?