Close menu

Advanced Settings

DoS filter for Carbonio mobile’s 
A specific DoS Filter component is part of Carbonio Mobile, which boosts security and stability. When a device consistently connects at a rate higher than the selected limit, the filter will engage and “jail” the device for a certain amount of time, blocking any connections from it.
 
By restricting clients who are making too many requests owing to defects or malfunctions, this increases stability and security by preventing Denial of Service attacks and freeing up resources for all other customers.

Warning

The Mobile DoS filter is disabled by default, and can be enabled as needed via CLI.

Configuration
The Carbonio CLI command carbonio config global set|get|clear.may be used to fully configure the Mobile DoS Filter at the global level. The carbonio config info attribute [name], where [name] is one of the following, may be used to access specific information for each property:
 
  • mobileAntiDosServiceEnabled: The Mobile DoS Filter service is now enabled. standard false;
  • mobileAntiDosServiceJailDuration:  The length of the synchronisation “jail” in milliseconds. Standard 600000;
  • Time window used by mobileAntiDosServiceTimeWindow to compute the connection ratio. If a device submits additionalmobileAntiDosServiceMaxRequests requests during this time interval, the prison is activated. Standard 30000 ms;
  • Maximum requests received during mobileAntiDosServiceTimeWindow milliseconds are specified bymobileAntiDosServiceMaxRequests . Standard 150;
Using the Mobile DoS Filter
The system retains the timestamp of the most recent mobileAntiDosMaxRequests in memory while the anti-dos service is active and  mobileAntiDosMaxRequests is higher than 0. All new requests from this device/account are rejected for mobileAntiDosJailDuration milliseconds if the maximum number of request timestamps have been saved and all of the stored requests are within the time window.
 
A warning is added to server alerts and an email is sent to the administrator when the rate has been exceeded.

Note

Issuing the command carbonio mobile doRestartService anti-dos will reset all jails and counters.

Mobile Performance Tuning for Carbonio
To fine-tune Carbonio Mobile in accordance with system performance, Carbonio Mobile offers three helpful choices.

Notifications Latency

ZxMobile_NotificationsLatency represents the seconds of delay between an event on the server and its notification to the mobile device.

Use Instant Notifications

ZxMobile_UseInstantNotficiations enables or disables instant notifications. If true, it also overrides Notifications Latency.

Max Ping Heartbeat

ZxMobile_MaxPingHeartbeat defines the maximum interval between ping commands.

 

The carbonio config command may be used to change any option via the CLI.

When Should Performance Tuning Settings Be Edited?
For most instances, the default settings ought to be ideal. However, if you encounter any of the issues listed below, please use the recommended fix.

Problem

Suggested solution

High system load

Disable instant notifications

High system load after disabling instant notifications

Raise notification latency

Mobile users experience high network usage

Disable instant notifications and tweak notifications latency

Devices can connect but sessions are interrupted frequently

 

Adjust Max Ping Heartbeat according to your network configuration

 

Items are synchronized from server-to-device with an excessive delay

Lower notification latency or enable instant notifications

Filters for EAS
The protocol version used for synchronisation in the EAS protocol is set at the initial handshake and is never altered. The client selects a protocol version from a list of all accessible versions presented by the server.
 
To guarantee that the correct version is utilised, EAS filters can be used to restrict the EAS version that is accessible to a certain group of users or clients.
 
The getAllEASFilters and doMoveEASFilter  commands are described in the section below titled “Managing EAS Filters.” Multiple EAS filters may be configured and will be examined in a sequential manner.
A description of an EAS filter
There are 5 components to an EAS filter:
 
The kind of the filter rule is defined by type.
 
Parameter
the filtering identity, such as an email address or a brand of equipment.
 
Mode
determines whether the programme will present a fixed list or limit the versions that are accessible.
 
field easversions
contains the protocol versions that the filter has enforced.
 
Whether further filters are used after the present one has successfully matched is determined by the blocking Boolean value.
Managing EAS Filters
The four specific commands listed below are used to manage EAS filters using the CLI.

getAllEASFilters

This command lists all existing filters.

Sample Output:

filters

         ID                                                          0
         mode                                                        fixed
         rule                                                        [type = or; rules = [[type = contains; rule = outlook/] OR [type = contains; rule = microsoft.outlook]]
         easversions                                                 14.0
         blocking                                                    true

         ID                                                          1
         mode                                                        limit
         rule                                                        [type = contains; rule = samsung]
         easversions                                                 2.5
         blocking                                                    false

         ID                                                          2
         mode                                                        limit
         rule                                                        [type = always]
         easversions                                                 14.1
         blocking

doAddEASFilter

This command adds a new EAS filter:

Syntax:

carbonio mobile doAddEASFilter {and|or|regex|contains|account} {text|user@example.com|account=otheruser@example.com,contains=android} {add|subtract|fixed|limit} {easversions} [attr1 value1 [attr2 value2...]]

Usage example:

carbonio mobile doAddEASFilter contains android fixed 2.5,12.0,14.1

Adds a protocol filter that will restrict the pool of available EAS versions to 2.5, 12.0 and 14.1 if the user agent name contains the string ‘android’.

carbonio mobile doAddEASFilter and account=user@example.com,contains=android fixed 14.1 blocking true

Adds a protocol filter that will restrict the pool of available EAS versions to 14.1 if the user agent name contains the string ‘android’ only for user@example.com. No more EAS filters will be evaluated after this one due to the ‘blocking’ directive.

doDeleteEASFilter

This command deletes an existing EAS Filter.

Syntax:

carbonio mobile doDeleteEASFilter _id_

Usage example:

carbonio mobile doDeleteEASFilter 2

Removes the filter with id = 2.

doMoveEASFilter

This command is used to move EAS filters to a different position in the filter queue.

Syntax:

carbonio mobile doMoveEASFilter {from} {to}

Usage example:

carbonio mobile doMoveEASFilter 0 5

Moves the filter with id = 0 to the position 5.

Loggers for mobile accounts
A user’s full EAS logs can be produced into a specialised logfile by mobile account loggers, which have a different verbosity than the sync.log file. This makes troubleshooting possible more quickly.
 
The following conditions must be followed while establishing an account logger:
  • The intended customer
  • The verbosity of the log, or log_level
  • The specific log_file
  • While the logger is active, the window_size that will be enforced across all devices synchronising with the account

Warning

Account loggers are removed automatically when the mailboxd is stopped or restarted and do not usually survive a mailboxd crash. Log files won’t be affected.

Account Logger Management

The following commands are the only ones that may be used to manage account loggers through the CLI:

doAddAccountLogger

Syntax:

carbonio mobile doAddAccountLogger {account} {debug|info|warn|err|crit} {log_file} [attr1 value1 [attr2 value2...]]

Usage example:

carbonio mobile doaddaccountlogger john@example.com info /tmp/john_logger

Creates an info account logger for john’s account to file /tmp/john_logger

carbonio mobile doaddaccountlogger john@example.com info /tmp/john_logger window_size 1

Creates an info account logger for john’s account to file /tmp/john_logger with window size set to 1.

doRemoveLogger

Syntax:

carbonio mobile doRemoveLogger {logger_id|"all_loggers"}

Usage example:

carbonio mobile doremovelogger 5

Removes the account logger with ID = 5

getAccountLoggers

Sample output:

carbonio mobile getAccountLoggers

      loggers

              id                                                          7
              level                                                       DEBUG
              name                                                        AccountLogger
              description                                                 Logging account user@example.com using level debug, log file /tmp/user.log
              remove command                                              carbonio mobile doRemoveLogger 7