Push Mail Support for IOS

[reneploetz]

I'm currently running docker-mailserver with some modifications, one of them being the support for IOS push notifications for emails for that you do not have to use the polling on mobile clients (as IOS does not support IMAP IDLE). This is done without using z-push, but implementing Apples XAPPLEPUSHSERVICE IMAP extension.
I wonder if there would be interest in a pull request to either implement a few bits here or maybe only just the documentation on how to do it.

Note that this support requires an enrollment into the Apple Developer Program to be able to generate the required push certificates which might limit the audience for this feature very notably.

Generally speaking, the push support requires 2 parts:

• a dovecot plugin that converts notifications about new mails / clients and sends them to a daemon process: https://github.com/freswa/dovecot-xaps-plugin
• a daemon process that receives the dovecot notifications and talks to Apples push servers to notify about new mails: https://github.com/freswa/dovecot-xaps-daemon

Integration into this project could be providing the dovecot plugin out-of-the-box (like we do with the FTS plugin right now) and mentioning how to use it using user-patches.sh inside the documentation or even providing the daemon process as an additional service with a specific configuration option.
As the use of this might be rather interest a very small number of people I wonder how to proceed - hence this idea discussion.

[polarathene]

Documentation is a good initial approach to take, along with raising a feature request issue. If there's enough interest expressed from users it'll be easier to get maintainers onboard with it. The docs can link to the feature request issue if it helps garner traction.

• If the plugin doesn't add much to the image weight, you can probably get that approved for the convenience.
• If the required scripts to support the feature is fairly small and not too invasive into the codebase, you can probably get that merged too, since the more isolated the feature is the less maintenance concerns it raises, and it can be more easily deprecated / removed in future if there are issues with no one having time to resolve them.

Anything beyond that probably will be a tough sell, as I think the current maintainers are all strained for time to work on the project right now (beyond responding to queries and light maintenance).