Hello,
is there a public document specifying this
No explicit public specification; the closest we have are patches
published against Dovecot (which was part of macOS Server, their
discontinued server product).
Other open-source mail server projects have used that as a specification
to develop their own solutions:
*https://github.com/freswa/dovecot-xaps-plugin
*
https://github.com/cyrusimap/cyrus-imapd/commit/a4470bf0f79de49030b3d66d2b385a1345c1a040
we added exactly one year ago support for IMAP extension
As you saw previously I am already doing this in my proof-of-concept,
however I have a question as to which pattern the storage & APNS long-lived
client should conform to. The IMAP extension & mailbox listeners (which
James has established patterns for) are only *part* of the entire solution.
I am very new to this project (and Java in general) so I would appreciate
if someone with more experience could stub out a general layout of the
classes I should implement and which base classes to inherit from for the
storage & long-lived APNS client. I will check out that Firebase extension
you linked but I'd appreciate any other help/opinions.
all code landing in ASF james needs t be ASFV2
I'm open to licensing this under whatever license - the PoC I linked to
previously is licensed under whatever James is, I've copied the LICENSE
file verbatim.
we can not rely on a proprietary custom external APSN bridge (external
bridge is OK to me though, if FOSS and easy to run...).
T bridge I used in my PoC is FOSS (MIT-licensed), however I am looking to
remove the dependency on it as I find its data storage model inadequate and
unable to support mailbox delegation, therefore this mailing list thread on
how to reimplement the full functionality within James itself.
Regards.
On 7 Dec 2023, at 20:13, Benoit TELLIER<btell...@apache.org> wrote:
Hello Andre.
Thanks for letting me discover about this Apple feature. Out of
curiosity, is there a public document specifying this? If so could you
share this link?
Are you aware of other free and OpenSource mail servers implementing
this?
Second, we added exactly one year ago support for IMAP extension:
implementing support for XAPPLEPUSHSERVICE can thus always be done in an
extension. Here is an example of how to do so:
https://github.com/apache/james-project/tree/master/examples/custom-imap
I speak for myself - this is not something I would contribute by myself
for pleasure
First question would be whether you'd be interested in including this
in James core, or if this should remain a separate extension?
If there is a publicly available specification and other FOSS mail
server implementation for this, I personnally could welcome such a effort
as a third party module that could be embedded into the IMAP stack.
Definitvely not in James core.
If interested in upstreaming, would you be able to outline a
high-level overview of what the code should look like, especially where to
put the APNS client?
https://github.com/apache/james-project/tree/master/third-party/apsn-imap
?
We coukld define core concepts there, apsn driver, storage api, imap
module. Then separate maven modules for token storage?
Like
https://github.com/apache/james-project/tree/master/third-party/apsn-memory
https://github.com/apache/james-project/tree/master/third-party/apsn-cassandra
Somebody willing to enable the extension in James would...
...1 Drop the apsn-imap-xxxx jar on the classpath
...2 Register the guice module into extensions.properties to select his
device store.
...3 Register the APSN IMAP extension.
I want to know whether James has a way for extensions to attach
arbitrary data to a mailbox
James extension can store data. Talk speaking about this [1] and (old)
code example [2]
[1]https://www.youtube.com/watch?v=zr8qpNkL6U4&ab_channel=TheASF
[2]https://github.com/chibenwa/james-blacklist
Also, where to put the long-lived APNS client?
Dedicated storage for the extension
Does James have an existing extension pattern that accounts for
long-lived services like this?
Yes as Tung mentionned with JMAP we did implement WebPush and a Linagora
specific firebase extension.
We also do have websockets and eventsource up and running with JMAP.
https://github.com/Rjevski/apache-james-xapsd-registration-extension
So cool!
Congrats!
Definitly happy to welcome this in James (as third-party), and happy to
see you did succeed to set up an IMAP extension by yourself!
Last question: all code landing in ASF james needs t be ASFV2 and we can
not rely on a proprietary custom external APSN bridge (external bridge is
OK to me though, if FOSS and easy to run...).
Best regards,
Benoit
On 07/12/2023 10:33, Tran Tung wrote:
Hello,
I'm unable to answer all your questions.
As I know, James doesn't have a backend repository to store data
similar to your use case.
At Linagora, we encountered a similar situation when implementing
Firebase. Consequently, we opted to develop a dedicated repository for
storage.
If you want to reference the code, you can visit
https://github.com/linagora/tmail-backend/tree/master/tmail-backend/jmap/extensions/src/main/java/com/linagora/tmail/james/jmap/firebase
Hope that help you a bit
On 07/12/2023 15:36, Andre Borie wrote:
Hello and hope everyone is well. I would like your help as to how best
to implement Apple Push notification support.
For a bit of context, Apple iOS does not use IMAP IDLE - instead it
uses a proprietary IMAP command "XAPPLEPUSHSERVICE" combined with Apple's
hosted push notifications service "APNS".
When an iOS device connects to a supported server advertising the
"XAPPLEPUSHSERVICE" capability, the device issues an XAPPLEPUSHSERVICE IMAP
command with the following contents:
* account-id: opaque blob that must be quoted in subsequent
notifications
* subtopic: APNS subtopic, must be used when sending subsequent
notifications
* device token: the APNS identifier of the device, must be used to
send subsequent notifications
* list of mailboxes: list of IMAP mailbox names (from the perspective
of the iOS IMAP client) to monitor and send notifications upon changes
The IMAP server replies with an APNS topic (mostly static value,
derived from the certificate it uses to talk to APNS). Then, when changes
occur in the aforementioned mailboxes, the server must send a notification
via APNS (a persistent connection to an Apple server authenticated by a
client certificate) towards the aforementioned device token & subtopic,
quoting the account ID & client-facing mailbox name. The notification is
relayed by Apple to the target device which prompts it to wake up and fetch
the new messages via IMAP.
This would require us to:
* store (device_token, account_id, subtopic, client-specific IMAP
mailbox name) tuples against a given Mailbox
* react to mailbox events and enqueue notifications for each of the
above tuples
* maintain a persistent connection to APNS to dequeue & forward those
notifications to
First question would be whether you'd be interested in including this
in James core, or if this should remain a separate extension? If included
in core, it would require James to be able to accept another keystore (with
the APNS certificate, created by a helper program) and be able to reload it
on the fly to enable zero-downtime certificate rotations.
If interested in upstreaming, would you be able to outline a
high-level overview of what the code should look like, especially where to
put the APNS client?
On the other hand, if it's better to keep it as an extension, I want
to know whether James has a way for extensions to attach arbitrary data to
a mailbox (so I can store the device tokens) without changing the storage
backends? Also, where to put the long-lived APNS client? Does James have an
existing extension pattern that accounts for long-lived services like this?
For reference, I currently have a proof of concept extension at
https://github.com/Rjevski/apache-james-xapsd-registration-extension
which is an IMAP extension (implementing the custom command) and mailbox
listener - however, the storage of mailbox to device token mappings and
APNS communication is delegated to an external service called over HTTP.
Regards.
---------------------------------------------------------------------
To unsubscribe, e-mail:server-dev-unsubscr...@james.apache.org
For additional commands, e-mail:server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:server-dev-unsubscr...@james.apache.org
For additional commands, e-mail:server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:server-dev-unsubscr...@james.apache.org
For additional commands, e-mail:server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail:server-dev-unsubscr...@james.apache.org
For additional commands, e-mail:server-dev-h...@james.apache.org
