Cloud & Web Security. Parla Quick Installation Guide

Transcription

1 Parla Quick Installation Guide

2 Index 1. PARLA Introduction 2. Licensing model 3. Initial PARLA account configuration. 3.1 PARLA Inbound and Outbound configuration Domain configuration Mailbox Configuration Mailbox manual configuration Importing mailboxes from lists Automatic user provisioning using SMTP Automatic user provisioning using LDAP (Active Directory). Platform customization Configuring the MX records in the DNS Checking the type of mailbox assigned to users Outlook Integration. 4. Aditional Information. 5. Contact Information.

3 Parla Quick Installation Guide 1. PARLA Introduction PARLA works on any computer or mobile device with data connection and also allow you to continue working even when offline. Whether in the office, in a meeting or traveling, your is always available. You can access your with the local clients such as Outlook, as well as ios and Android devices. In addition, employees can log in to our complete Webmail platform where they can manage your s, collaboration, document management, task management, and many more features. The latest version of Parla enables the option to share accounts between users in the same domain. PARLA uses Spamina Cloud Firewall technology to help identify patterns and real-time spam blocking its entrance, leaving any malware stored in the cloud at Spamina by releasing your mail server The companies receive clean only while spam is kept in our data center for 28 days. filtering is designed to detect spam, phishing, malware and viruses, using advanced patterns and classifications that are processed in data centers Spamina detect attacks in real time. Cloud Firewall incorporates a new outgoing filter based on signatures (Simile Fingerprint Filter ) to detect mails mailings. The Spamina Cloud Service guarantees the confidentiality of customer information. The traffic is sent only to data centers where the privacy of our customers is fully protected from laws like the American Patriot Act, CISPA or Prism Data Collection NSA. Spamina has never transferred data and provide a level of data confidentiality that no American company can match. Some of the PARLA features are: - Centralized configuration Easy Administration Multilayer Antispam Backup Users Registration: Manual Importing from a file LDAP callout with Alias discovery SMTP callout Cluster active-active avoiding any information lost in case of incidence Administrators per domain

4 logs with the possibility of open s (if you chose this option when you Purchase), add senders / IP's to white list / blacklist, classify mails as Valid / Spam Trusted lists by User Customized filters Notification software MDM (Mobile Device Management) Instant Messaging (PARLAMi)

5 2. Licensing Mode PARLA is subscribed as a service and every mailbox will require a license from the license pool available on the service. The administrator can review the number of licenses being used and available under Administration -> Status -> State of Subscription:

6 In order to obtain the total number of licenses needed for your organization, the following points need to be considered Alias Domains In case you have created a domain (example 'spaminatesting.com') with already created users (consuming licenses in the system) and have a domain that is an alias to this domain (ex 'spaminatesting.es') this domain can be configured as an alias and therefore all users present in the main domain will be implicitly set to the alias domain and these users will not consume an additional license. Alias Accounts Each license of the solution will protect 1 main mailbox and up to 5 aliases addresses associated to the main mailbox consuming the license. In order to associate the alias accounts covered by a single license in the system, it is required that alias addresses are properly configured in the system. Alias accounts can be configured manually (section ) or using LDAP Automatic Sign-up mode when enabling Alias search in the LDAP configuration. Bear in mind that alias discovery is not an available option when using SMTP automatic Sign-up mode and therefore LDAP provisioning is advised in organizations with alias addresses. In case your organization has alias mailboxes protected by the solution and in case those alias accounts are not properly configured as alias in PARLA configuration, the platform will consume a license for those alias mailboxes. 3. Initial PARLA configuration This guide covers the initial configuration steps required to configure your domains and all users. All configuration detailed in this guide is done from the enterprise management console. Access to the enterprise management console was provided with this quick setup manual. (Access URL: < with a username and password) and you will have a unique access credentials for management interface. Please review the access URL for your account as provided to you in the welcome sent to the address of the administrator. Your access URL may vary. The initial configuration is required to indicate to Parla the domains that will be added in the solution, as well as end users' mailboxes to be created. Please note that configuration covered in section 3.1 is mandatory and, in case the steps detailed in this guide are not fully completed before forwarding inbound s to the PARLA solution, both inbound and outbound s will be bounced back with a permanent error code. This will have the final effect of s never being delivered to the destination users, so we advise to read through this guide and perform all the configuration steps for domains and users to be protected.

7 3.1 Configuring inbound and outbound with PARLA The initial configuration of the Parla solution consists of several steps that must be followed in this order: Configuration of domain(s) to be protected by the platform. Configuration of your organization accounts that will be created (manually or through some process that automatically will create the users). Initial customization of PARLA, in case you want to change the look and feel of the user interface and the communication sent to mailboxes created at the platform. DNS MX redirection to PARLA so will flow through the solution. This next section will provide detailed instructions for each configuration step Domain Configuration First configuration step is to configure in the platform the domain or domains that will be used by PARLA. This configuration is done under Administration -> Domains. For each domain to be procesed by the solution, we need to configure a new domain clicking on New: The information required for each new domain as it follows: Select the checkbox The domain to be registered is an alias' in case the domain you are configuring is an alias domain of another existing domain already configured in the platform. Enter the name of the domain to be protected under Name (ie: spaminatesting.com). A contact address is required. Notifications generated by the platform related to this domain will be sent to the specified address (such as the user synchronization process or in case the domain has reached the maximum allowed number of licenses). We recommend using an external address, as notifications stating that the mail servers are unreachable will be sent to this notification address. You can limit the maximum number of licenses that will be consumed by users provisioned in this domain. You can select the default language that will be used for this domain. All end user notifications as well as the end user management interface for users created under this domain will be available in the specified language as a default.

8 After configuring this section, you need to configure the host or IP address where Spamina Cloud firewall will deliver inbound s after being filtered. This hostname or IP address will be the current PARLA host or IP address Bear in mind that in case you have not yet redirected your DNS MX records to the Spamina filtering solution, you can fetch your current server location into the Recipient Server settings by clicking on Get SMTP The platform allows the configuration of several MX hosts and each of them can be configured with a different priority. Make sure that the Priority field is set to something different than 0 and consider that configured hosts with lower priority will be preferred when delivering inbound to your organization. Once all MX hosts have been properly configured, make sure to run the test SMTP check to ensure that the platform can contact the specified MX hosts. After configuring the Recipient servers, you may now save the configuration for your protected domain or you may define a Domain Administrator at this point. A domain administrator will have the specified access credentials to the administration interface located under ( < and will be able to change configuration settings only for the domain being configured in this section. Please review the access URL for your account as provided to you in the welcome sent to the address of the administrator. Your access URL may vary.

9 Once all fields have been configured, save the domain configuration and proceed to the next step: Mailbox Configuration: to register users (mailboxes) to be included by the solution Mailbox configuration Because of the operating mode of Parla, you must configure all the mailboxes to be included in the platform. Failure to complete the setup of all mailboxes (either manually or automatically) correctly, a permanent rejection of incoming and outgoing mail of organization will happen if Parla is processing mail from your domains. Mailbox (also known as User) configuration can be achieved in different ways: Manual User configuration: The administrator can manually provision the mailboxes (or alias addresses) individually. The administrator can also import a list of users (TXT or CSV format). Automatic Sign-up configuration: Each domain being included by the solution can be configured to automatically add user mailboxes using two different methods: SMTP or LDAP. Both provisioning mechanisms can coexist in the solution. The administrator may configure manually some mailboxes and have, at the same time, the automatic sign-up mode in the domain being protected Manual User configuration Mailboxes that will be protected by the solution can be added manually using the management interface under Administration -> Users. Using this screen, the administrator can create users with a main canonical address (primary delivery address) and alias addresses linked to another main delivery address already existing in the system. In order to create the main address of a user in the system, click on Create User

10 The following minimum information required in order to provision a new user in the system is: Domain: A domain should be selected from the drop down list of already provisioned domains in the system. This will be the domain of the main address of the user to be protected. Language: Default language for this user. This will be the language for all the system generated notifications for the user. By default the system will select the language chosen at the time the domain of the address was configured. Full Name: This information is used for administration purposes in order to list the users by their real name and surname instead of the address being configured. User Login: This will be the address for the user being created. You only need to enter the name of the mailbox, as the domain will be selected from the Domain field Password: The system requires each user to have a password for accessing the End User management interface on the system. Using the previous example we will be provisioning the following mailbox to be protected by the platform: homer.simpson@spaminapresales.com. Once details about the user to be protected are entered in the platform, you need to save the configuration. Back in the User menu, the administrator can create an alias address linked to a main mailbox created previously by clicking on Create user alias:

11 The following minimum information is required in order to create an alias address account bound to a main delivery address: Domain in which Alias will be created: This will be the domain hosting the alias address. It is not necessary that the domain in which the alias account is to be created is the same as the domain hosting the main delivery address. Main Domain: Domain hosting the main delivery address to which we want to link the alias addresses being created. Alias Name of the alias account to be protected by the solution, without and the domain part. Main Account: The main delivery address we will be binding the alias to. The main account must have been created previously on the system. The following example will create the alias address homer@spaminatesting.tv bound to the main address account homer.simpson@spaminatesting.com. Once the alias details have been entered you can save the configuration Importing Mailboxes from lists PARLA platform allows the administrator to manually import a list of users into the system using files. This can be done from Administration -> Users -> Import: Before performing the users import, we need to prepare a file containing the name of the mail (and alias) addresses that will be created in PARLA. The file to import could be a.csv or a.txt having the following format:

12 Full name, address, password Full name, address Full name, address, password, [list of comma separated aliases] The password and the comma separated list of aliases are optional. If no password is given, PARLA will auto generate one at the time the user is imported into the system. Please consider the following tips in case you want to specify the passwords for your users in the file to be imported: Lowercase and uppercase letters "a" to "z", except "ñ" Numbers 0-9 Symbols allowed: _. Minimum length of 8 characters and a maximum of 64 characters The address present in the file to be imported can be specified in any of the following 2 formats: 1. Including the domain the mailbox belongs to: In this scenario, a valid example of the contents of a file to be imported would be: Michael Perk, mperk@example.com, aras249gt Anthony Perkins, aperkins@example.com, 32kios5d Timothy Perkins, tperkins@example.com Anthony, alopes@example.com,,alopes.alias1@example.com,alopes.alias2@example.com Please note that the first and second line will set a predefined password (aras249 and 32kios5d), while the third and fourth line will result in the system auto-generating a password for those users. The fourth line also defines some alias addresses for user alopes@example.com. 2. Not including the domain the mailbox belongs to: In this scenario, a valid example would be: Michael Perk, mperk, aras249gt Anthony Perkins, aperkins, 32kios5d Timothy Perkins, tperkins Anthony, alopes,,alopes.alias1,alopes.alias2 It is important to select the domain under which the users will be imported in case the addresses specified in the file do not specify the domain (case 2 as presented above). If the domain is present in the file to be imported, it is mandatory that you leave the Select a domain field empty in the import menu as the import process will fail otherwise. You cannot import a file which has addresses both with and without a domain. Taking the previous points into consideration when creating the file to import, select the file in using the import menu and click on import. Please bear in mind that the import process is not performed real time and it will take several minutes to complete depending on the number of users to be imported. Cloud Firewall will notify the system administration via , sending a summary detailing the result of the import process.

13 Automatic user provisioning using SMTP PARLA can be configured to automatically sign-up users using the SMTP protocol. Using this automatic provisioning mechanism, users that are not currently present in the system will be automatically provisioned at the time the first inbound is processed for the user present in a domain being protected by the solution. Automatic SMTP provisioning of users can be configured under Administration -> Sign-up mode. SMTP automatic sign-up is configured on a per domain basis as follows: Then we save the settings. When saving the settings the introduction of an existing user in the domain is required. You must enter an existing user in the domain that is being protected Once SMTP activation mode has been selected and the configuration is saved, the system will request the administrator to enter a valid address of a user existing in the domain being configured for automatic sign-up mode. This check verifies whether the server being added is valid for SMTP automatic provisioning. In case you enter a valid address existing in the domain being configured for SMTP sign-up provisioning and if the check fails, the server may not be suitable for SMTP automatic sign-up mode. This verification may fail in case the client server is configured to accept at SMTP level all addresses, even the ones for non-existing users in the organization. In Microsoft Exchange terms this is also known as Recipient Validation and, if disabled, will accept all addresses for a domain. Recipient validation must be enabled in order for PARLA to properly provision users via the SMTP automatic sign up mode. Please double check with your administrator to ensure that your mail server is rejecting s at SMTP level for non-existing addresses at your domain. The system will not allow you to configure SMTP Automatic Sign-up mode in case the previous check fails. Once SMTP automatic sign-up mode has been configured, the system will provision users automatically at the time s are processed by the platform for those users. This means that shortly after the SMTP automatic sign-up mode has been enabled, the administrator will not immediately see the complete set of users provisioned in the management interface (under Administration -> Users). PARLA user database will be built up progressively, as new users keep receiving s from the internet through PARLA. One essential point that must be taken into account when enabling the SMTP automatic sign-up mode is that all mail addresses for your organization, regardless whether they are main mailboxes or alias addresses, will be provisioned as a main mailbox in PARLA, consuming a license from the system. Bear in mind that this is an important consideration when computing the license consumption by the system. In case your organization is making an extensive use of alias mailboxes, we recommend enabling the LDAP automatic sign-up mode instead of the SMTP sign-up mode, as LDAP provisioning is able to discover alias addresses and therefore license consumption will be more accurate.

14 Automatic user provisioning using LDAP (Active Directory) Another auto provisioning mechanism available in the platform is the use of LDAP queries against the directory service present inside the client s network. This is the advised sign-up mechanism to be used for medium to large corporations. The main difference between both automatic sign-up modes, SMTP and LDAP, is that LDAP provisioning is capable of detecting alias addresses and binds them automatically to a main mailbox, both for management and proper license consumption purposes. LDAP sign-up mode can be enabled globally (for all domains) or on a per domain basis. We recommend configuring LDAP provisioning globally across all domains whenever possible, this is, when all domains being protected by the solution are governed by the same domain controller or directory server. You may configure different LDAP servers in case your organization has independent domain controllers or directory servers per domain. The minimum requirements needed to configure the LDAP user sign-up are as follows: Spamina s PARLA cloud servers need access to your directory servers (Active Directory / Lotus / LDAP) using any of the customer s public IP addresses or using a fully qualified domain name that is visible on the internet. Spamina s PARLA cloud servers will query your directory servers using the LDAP or LDAPS protocols. Spamina s PARLA cloud servers can do anonymous LDAP queries, although we recommend using the credentials of a specifically created user for this purpose. The IP address range of Spamina s PARLA cloud servers from which we will be querying the end customer directory server is as follows: / / /24 Please review the latest IP addresses ranges under your administrator management console under the Manuals -> Configuration information section. We require that the customer allow LDAP or LDAPS connections from the IP address ranges specified above. When configuring the LDAP user sign-up mode with Active Directory, it is required that a user is created in the Domain Controller. This user needs to belong to the Domain Users group and the system requires the credentials of that user to be configured. Please perform the following action in the primary domain controller of your organization to create this user: 1. Create a specific user belonging to the Domain Users group. 2. The password assigned to the user must contain alphanumeric characters and the _ and - symbols only. Please do not use any other characters as the password for this user. 3.When creating the user, please specify that the password does not need to be changed by the user and that the password never expires. This is essential, as most of the issues reported by customers using LDAP user sign-up mode are due to the fact that the password as configured in Spamina s Cloud Firewall is no longer valid as it expired on the customer directory service. Once this specific user has been created in your Domain Controller, you need to get the path to the Distinguished Name for that user. Just open a command line window on your Domain Controller (Start -> Run -> cmd) and run the following command: dsquery.exe user name [USER]

15 In case the new user created was named spamina, here is the command that must be run on the domain controller and the output returned: dsquery.exe user name spamina CN=spamina,CN=Computers,DC=dctest,DC=local The user to be configured in the LDAP sign-up mode management interface will be the path as returned by the previous command: CN=spamina,CN=Computers,DC=dctest,DC=local. Please copy that information from the command line tool. Once the user has been configured and the Distinguished name of the user obtained, the LDAP user sign-up mode can be configured under Administration -> Sign-up mode -> LDAP [Setup]. The following section will describe the most common configuration options used when configuring LDAP sign-up mode with Microsoft Active Directory: LDAP Server Please select the correct directory server type used in your organization. In this guide we will be using Active Directory. Connection: Host: Enter the IP address or FQDN of your LDAP server. Please note that this IP/FQDN for your directory service must be reachable from Spamina s IP address ranges. Port: 389 (default) Anonymous Connection: [Unchecked] As Microsoft Active Directory does not allow anonymous connections this option must be left unchecked. Username: A valid CN path must be entered in this box. Using the previous steps, we can enter the CN path as returned by the dsquery.exe command run on the domain controller: CN=spamina,CN=Computers,DC=dctest,DC=local Password: Enter the password chosen for the user created following the previous example Once all data has been properly entered in this configuration section, the administrator can validate the current values by clicking on the Check button. This test will validate that the host and port specified can be reached by Spamina s cloud servers and that the credentials provided are valid. Please double check that connectivity is allowed from Spamina s cloud servers to your infrastructure in case you get connection errors. Search Scope: DN Base: Starting point in the LDAP tree from where Spamina s PARLA look for users in your organization.

16 It is recommended to configure a starting point as close as possible from your organization s tree root, so all users will be found regardless of the organizational unit they are configured on. The DN Base can be obtained from the CN of the user created in our previous example. When configuring Active Directory, the Base DN usually matches the part of the user s CN that starts with DC. In our previous example, it will be: DC=dctest,DC=local A level: Select this option if all the users inside your organization are present in the DN Base. Subtree: Select this option if all the users inside your organization are present at this level and other sublevels starting from the Base DN path. This is the recommended option when a Base DN close to the root tree has been configured. Search for username: These values will be automatically filled in when selecting the correct type of directory server used in your organization (Active Directory / Open LDAP / Lotus Domino). In case you are configuring an Active Directory server, you may need to check The attribute stores the full address option: At this point, you can click on the Check button to validate the configuration entered for your LDAP server. A valid main address present in your organization will be requested (not an alias address) and the system will check whether we can retrieve the information for this user using the current configuration, validating the current settings: If the address provided during the check is not found, please double check the configuration entered in this section with your domain administrator. The schema used at your organization may differ from the examples

17 used here. Alias Search: This option is, by far, the option that makes LDAP automatic provisioning more appealing than SMTP provisioning. It refers to the ability to automatically discover and bound alias addresses to main addresses in your organization, both for computing the correct number of licenses that you will consume and for management purposes. We strongly recommend enabling this option whenever LDAP sign-up is being configured. Enable Alias Discovery: This option will enable the retrieval of alias addresses from your directory server. Attribute containing the alias: proxyaddresses LDAP Filter: (objectclass=*) Please note that you can specify different filter options here in order to retrieve only the desired information. We will be using (objectclass=*) in this example so we will retrieve all alias addresses. Is the field multi-valued?: No This is usually the default setting for Microsoft Active Directory + Exchange. Alias separator: : For Microsoft Active Directory + Exchange you should enter the : sign in this option. This will be the character that will separate different alias addresses inside the configured attribute. Is the Alias the same object as the mailing address? Yes Microsoft Active Directory + Exchange will store alias addresses in the same object as the user. Once this section has been configured, the administrator can validate the settings using the Check button. A valid alias address present in your organization is requested and the system will check that the corresponding main address of the user is correctly retrieved using the current settings: In case the check is not returning the main address of the user with the specified alias address, please double check the values entered in this section with your domain administrator, as your corporate schema may

18 differ from the standard one shipped with Microsoft products. User Information recovery: This section specifies what attributes inside your directory schema contain the full name of the user information being retrieved. This is a convenient configuration section to have configured so the information about a user in PARLA will be displayed using the name and surname of the user. The typical configuration for Microsoft Active Directory is as follows: Attribute that contains the user's surname: displayname Stores the first name and surname together: Checked After filling in all the required information and performing the relevant checks on each section, the configuration must be saved. When filling in all the sections in the LDAP sign-up mode, please perform all the checks available in the interface. The previous checks should be successful in order to consider the LDAP provisioning mode enabled correctly: Spamina s PARLA is able to connect to your directory server. Spamina s PARLA is able to locate users in your directory server (the check under the Search for username performs correctly when providing a valid main address in your organization). Spamina s PARLA is able to locate alias addresses for your users (the check under the Alias Search performs correctly when providing an existing alias address in your system and the check is able to return the associated main address for that user). In case any of the previous checks encounters an error the LDAP sign-up mode will not be correctly configured. Should this happen, please make sure to save the configuration and come back later to the relevant failing section to reconfigure the options after double checking the values with your domain administrator. The examples provided in the sections depicted above are oriented towards a Microsoft Active Directory + Microsoft Exchange deployment. The depicted configurations may vary depending on you re the schema used in your organization or in case the default Microsoft Active Directory schema has been modified Platform customization

19 Once the domain and users setup has been completed, the platform is ready to protect the users under the configured domains. The next configuration step is to customize the default platform behavior. It is recommended to complete the following basic customizations: Welcome message: In case any of the available automatic sign-up modes (SMTP or LDAP) have been configured, the platform can send a welcome message to automatically provisioned mailboxes with credentials that will grant each protected user access to the End User control panel. From this end user control panel, each protected user will have the ability to review their quarantined s and change their filtering preferences. If you want to make your users aware that this control panel exist and provide them with their unique passwords to access this service, you must enable this option (please note that the welcome message is disabled by default and therefore your end users will not be notified and will not be aware that this control panel exist). Blocked report: PARLA can be configured to send a summary to your end users containing information about the quarantined s in the system. Using this digest , your end users can unblock the s classified as

20 spam and add the sender to the user s whitelist in order to avoid blocking further s coming from the same sender. The delivery frequency of the blocked reports can be changed from Personalization -> Blocked report: Logo: The company administrator can upload a personalized logo that will be included in all system notifications to users being protected by the solution (welcome message, blocked reports, etc) as well as in the end user

21 management interface. The logo can be changed under Personalization -> Logo: Note that the customizations can be performed globally (for all domains configured in the platform) or on a per domain basis. The level at which the customization is being applied can be selected using the Settings for scroll down menu at the top of the page Configuring your DNS MX records After all previous steps have been completed the platform is ready to protect inbound s destined to your organization. In order to complete the deployment of PARLA into your organization s delivery flow, you need to change the MX records for the protected domains and point them to the following service hosts: mx01cef.spamina.com mx02cef.spamina.com Please review your current service MX records as shown in the administration interface under the Manuals -> Configuration information section. The MX records as stated here may vary depending on your configuration We recommend setting the MX records of the protected domains to both service hosts with the same priority (for instance 10 ) in order to achieve load balancing inside Spamina s Cloud Firewall platform. Please note that Spamina does not have access to the DNS settings, nor does Spamina have the ability to change the MX records of the domains being protected on behalf of our customers. This is a task that must be performed by the end client, as the DNS register belongs to the end client. Please check this point with your DNS service provider or with your network administrator in order to obtain more information on how to perform modifications to your DNS settings Once the change is made, Parla platform will begin processing incoming and outgoing mail and your organization will be able to work with the normally.

22 3.1.5 Checking the mailbox type assigned to users In the Management -> Mail -> Domains and Users menu must be enabled the PARLA mailbox, either for the entire domain or for specific users that are configured on the platform. Note that once a domain is configured in Parla Spamina solution and when the Parla mailboxes are activated in the management interface for that domain, all mailboxes that exist in that configured domain, must be hosted in the Parla platform. Spamina supports configurations of type split domain where certain mailboxes in one domain can be hosted in the solution of Spamina Parla and other mailboxes on the same domain can be hosted on an external mail server of the end customer. This applies to Split domain mailboxes at the same level in a domain. After creating the domain and users in the system, users can access their mailboxes using any of these mechanisms. When you authenticate, you must enter the address of the user complete (including domain) and password you specified when creating the user. At this point Spamina only authenticates users with passwords set on the platform. Webmail: IMAP: imapcef.spamina.com:143 IMAPS: imapcef.spamina.com:993 POP3: pop3cef.spamina.com:110 POP3S: pop3cef.spamina.com:995 SMTP: smtpparla.spamina.com:25 SMTPS: smtpparla.spamina.com:587 ActiveSync: firewall.spamina.com

23 To set Parla on mobile devices: iphone & ipad: Android OS: Windows Mobile: Sending mail via SMTP (using smtpparla.spamina.com) must be made by presenting authentication credentials. The current service hosts that should be used may vary depending on your account settings. Please validate the service hosts for each service that must be used in your management console under the Manuals -> Configuration information section Outlook Integration Parla offers full compatibility with Microsoft Outlook, Apple Mail, and other clients POP / IMAP / ical / CalDAV. Once PARLA cloud is integrated with Microsoft Outlook, bidirectional s, contacts, tasks and calendars synchronization is active in real time. The employees that enjoy working with Outlook as their client will not notice any difference when checking your , share calendars and managing their tasks. Parla adds to its compatibility with all clients, the ability to integrate directly into the Outlook interface, available for versions 2007, 2010 and For PARLA10 and PARLA30 users, two-way synchronization of mail, contacts, tasks and calendars is active from Webmail to Outlook and vice versa. For PARLA2 users, bidirectional mail synchronization is activated but does not include synchronization of contacts, tasks and calendars. This new version allows configure the CEF filtering settings for all mailbox types (white and black lists, rules, filter mode, alerts,). Unattended / Silent Installation To synchronize these items with an Outlook client as well as being able to search for Archiving, the installation of the following plugin is required. Windows: You can find the complete guide to installing and configuring the plugin here: Please check section Manuals -> Configuration information in your management console to find the most up-to-date guides and information about your service.

24 4. Additional information You can find additional information regarding available configuration and filtering options for Spamina s PARLA in the following online documents: PARLA Administrator's manual: PARLA User's manual:: 5. Contact In case you require additional support, you can reach our technical presales team at: presales@spamina.com