OX EMail Push Introduction: Difference between revisions

From Open-Xchange
No edit summary
Line 3: Line 3:
== Abstract ==
== Abstract ==


In combination with [[OXtender_for_Business_Mobility]] (EAS) and
In combination with [[OXtender_for_Business_Mobility]] (EAS), the [[AppSuite:OX_Mail_v2_0 | Mail App]] and [[AppSuite:PushToUI | websockets based push]] to the webinterface a working mail push is very
[[OXtender_2_for_Microsoft_Outlook]] (OLOX2) a working mail push is very
important. It is important to know, that this is a combined
important. It is important to know, that this is a combined
requirement to the mail server and the Open-Xchange server to make
requirement to the mail server and the Open-Xchange server to make
that happen.
that happen.


Both of the listed OXtenders are accessing Open-Xchange via the USM
The listed OXtenders are accessing Open-Xchange via the USM
interface (Universal Synchronization Module, which is the package
interface (Universal Synchronization Module, which is the package
open-xchange-usm).
open-xchange-usm).
Line 16: Line 15:


* '''EAS uses an internal mail poll if no push available'''
* '''EAS uses an internal mail poll if no push available'''
* '''OLOX2 is depending on an external mail push trigger'''


== Mail Push with [[OXtender_for_Business_Mobility]] ==
== Mail Push with [[OXtender_for_Business_Mobility]] ==
Line 141: Line 139:
  60 s <= X <= 120 s -> internal poll after 60 s
  60 s <= X <= 120 s -> internal poll after 60 s
  120 s < X          -> internal poll after X/2 s
  120 s < X          -> internal poll after X/2 s
== Mail Push with [[OXtender_2_for_Microsoft_Outlook]] ==
In OLOX2 USM does NO internal mail poll at all. There are no long
running waiting requests (like with Ping in EAS). Instead, the client
(Outlook OXtender) does http requests in short intervals asking for
changes. This is the reason why USM does no internal mail poll but is
depending on messages from the Open-Xchange server (using OSGi
Events).
The only exception is, when the client changes from one email folder to
another one. This will initiate a sync.


== Open-Xchange Mail Push implementations ==
== Open-Xchange Mail Push implementations ==


There are currently two publicly available implementations of mail push.
There are currently the following available implementations of mail push.


=== The [[Dovecot_Mailpush]] ===
=== The [[Dovecot_Mailpush]] ===


Is the recommended push mechanism in an Open-Xchange / Dovecot setup supporting also permanent push registrations for [[AppSuite:OX_Mail|OX Mail]] and [https://documentation.open-xchange.com/7.8.3/middleware/components/websockets.html Web notifications].
Is the recommended push mechanism in an Open-Xchange / Dovecot setup supporting also permanent push registrations for [[AppSuite:OX_Mail_v_2_0 | OX Mail App]] and [[AppSuite:PushToUI | websockets]].


=== The [[MailNotify_Bundle]] ===
=== The [[MailNotify_Bundle]] ===

Revision as of 09:50, 3 April 2019

Introduction to EMail Push in Open-Xchange

Abstract

In combination with OXtender_for_Business_Mobility (EAS), the Mail App and websockets based push to the webinterface a working mail push is very important. It is important to know, that this is a combined requirement to the mail server and the Open-Xchange server to make that happen.

The listed OXtenders are accessing Open-Xchange via the USM interface (Universal Synchronization Module, which is the package open-xchange-usm).

In summary:

  • EAS uses an internal mail poll if no push available

Mail Push with OXtender_for_Business_Mobility

In addition to an externally triggered mail push, in internal mail poll initiated by the usm module is executed.

This is, how this polling can be influenced via /opt/open-xchange/etc/groupware/usm.properties:

  1. com.openexchange.usm.session.sync.email_pull_delay=50%
  2. com.openexchange.usm.session.sync.email_pull_min_delay=60000


These values are the default values.

1. defines, when an internal poll should be triggered while waiting for the client. This can be done as an absolute value (in milliseconds) or as a percentage value based on the waiting time as been specified by by the client per Active Sync Protocol (EAS). In the EAS protocol, the client specifies this time dynamically, usually between 30 seconds and 30 minutes. If an absolute time is specified here and the time set by the client is smaller, a mail poll is initiated at the end of the waiting time if not prevented by the setting of 2.


2. defines an additional minimum waiting time, which is enforced to be followed, before an internal poll is executed. Is the value as specified by the EAS client/protocol smaller than this value, no poll will be executed. If 2. is set to a negative value, the internal mail polling of USM will be completely disabled.


Examples

A

com.openexchange.usm.session.sync.email_pull_delay=50%
com.openexchange.usm.session.sync.email_pull_min_delay=-1

Internal mail poll is disabled.

B

com.openexchange.usm.session.sync.email_pull_delay=50%
com.openexchange.usm.session.sync.email_pull_min_delay=60000


Client waiting time Mail polling interval
30 seconds no polling
90 seconds poll after 60 seconds (!)
180 seconds poll after 90 seconds
1800 seconds poll after 900 seconds

C

com.openexchange.usm.session.sync.email_pull_delay=120000
com.openexchange.usm.session.sync.email_pull_min_delay=60000
Client waiting time Mail polling interval
30 seconds no polling
90 seconds poll after 90 seconds (!)
180 seconds poll after 120 seconds
1800 seconds poll after 120 seconds


D

com.openexchange.usm.session.sync.email_pull_delay=60000
com.openexchange.usm.session.sync.email_pull_min_delay=120000
Client waiting time Mail polling interval
30 seconds no polling
90 seconds no polling (!)
180 seconds poll after 120 seconds
1800 seconds poll after 120 seconds


This example is not usefull, it should show, that property 2. has a higher priority than property 1.


The default behaviour can be described like shown below:

client waiting time X (EAS Ping):
        X < 60 s   -> no internal mail poll
60 s <= X <= 120 s -> internal poll after 60 s
120 s < X          -> internal poll after X/2 s

Open-Xchange Mail Push implementations

There are currently the following available implementations of mail push.

The Dovecot_Mailpush

Is the recommended push mechanism in an Open-Xchange / Dovecot setup supporting also permanent push registrations for OX Mail App and websockets.

The MailNotify_Bundle

This package only integrates with cyrus-imapd using its notification protocol.

The MALPoll Bundle

The package open-xchange-push-malpoll simulates mail push in polling the IMAP server on a regular basis. This can only be recommended on small installations as it might stress the IMAP server.

The MailPushIMAPIDLE Bundle‎

Mail push via IMAP IDLE. Works with all IMAP servers being able to do IMAP IDLE. Too many IMAP IDLE sessions can hurt huge installations as well as Open-Xchange due to number of open sessions and connections. Please use with care.