In the Collaboration section of the Server configuration panel you can configure how the DME server should manage S/MIME certificates, interact with the IBM Sametime instant messaging system, and send system-generated e-mails.
[ Expand All | Collapse All ]
The S/MIME group of functions contains the following fields:
Secure Multipurpose Internet Mail Extensions (S/MIME) provides a secure method of sending e-mail and is incorporated into many popular e-mail applications. S/MIME provides confidentiality and authentication by using the RSA asymmetric key system, digital signatures, and X.509 digital certificates. S/MIME complies with the Public Key Cryptography Standard (PKCS) #7 format and has been proposed as a standard to the Internet Engineering Task Force (IETF).
In other words, the sender of an e-mail can provide a guarantee to the recipient that the e-mail is in fact sent from the sender, and that the content of the e-mail has not been tampered with on the way to the recipient. S/MIME relies on a system of public/private keys and trust authorities.
If this field is set to Yes, DME will automatically store certificates from "external people". External people (sometimes called "other people") are here defined as people who are not users in the DME system. Say that an external accountant sends a signed e-mail to the CFO of your company. The accountant's certificate will then be stripped from his mail and stored here as an external certificate. Now every user in the DME system will be able to receive signed messages from the accountant, and DME certificate holders will be able to send signed and encrypted messages to the accountant without further setup.
If this field is set to Yes, DME will look up certificate revocation lists (CRL) and certificate status using the Online Certificate Status Protocol (OCSP) to check if external certificates are valid. However, if the server does not have access to the Internet, you should set this option to No to keep the server from attempting something that is not possible anyway.
If this field is set to Yes, DME will accept a public certificate from an external person, even if the certificate's CRL is unavailable at the moment, for instance if the CRL home page is down, or an Internet connection is temporarily down. Note that if the CRL is available, and the external person is found in the CRL, the certificate will naturally still be rejected.
The Instant messaging group of functions contains the following fields:
In this field you can enter the path to your instant messaging (IM) server (currently only IBM Sametime is supported). This enables IM presence in the clients, so users of the DME client can see the status of other users of the instant messaging server entered in this field.
In this field you can enter the user name used for logging in to the Instant Messaging service user. The service user is used for acquiring the IM status of the users shown in client mailboxes.
In this field you can enter the password of the Instant Messaging service user. The service user is used for acquiring the IM status of the users shown in client mailboxes.
The SMTP relay group of functions contains the following fields:
This is the external name of the mail server used by DME for sending system administration messages (see Alert e-mail below). Note that this mail server must allow relays from the DME server IP address.
Note also that using a corresponding field on the Main section of the connectors' setup page you can set up a mail relay server for each connector, which will handle system-generated messages about calendar conflicts and name resolution errors. See Main.
In this field you can enter a name you want to show as sender when a user receives a system-generated message as described above. For instance, you can enter DME Administrator or similar as sender to make it obvious to the user that the message is system-generated. If you leave the field empty, system-generated messages will be sent with root@DME-Server as sender.
Please take steps to ensure that e-mails from this sender are not evaluated as spam by the recipients' e-mail clients, for instance by instructing the DME users to add this sender to the "Safe Senders list" or similar. E-mail in spam mailboxes is rarely read, and almost never synchronized to DME clients, so there is a risk that important information is missed by the users.
The Alert e-mail group of functions contains the following fields:
In this field you enter the sender name of e-mails sent by the server to inform an administrator that a client was created on the server or a new client signing key was generated by the server. The e-mail is sent using the SMTP mail server specified in the field SMTP mail server above. As sender name, you can for instance choose the name of the current server. If you leave it blank, DME uses the name entered in the SMTP mail sender field above.
In this field you enter the recipient of the administrative server e-mails mentioned above.
The Pre-caching sync. data group of functions contains the following field:
If this field is set to Yes, pre-caching is enabled on the server. Please note that if you are using a technical user (DME_Server) for scanning the users' mailboxes, this technical user must have full access to all the users' mailboxes for pre-caching to work correctly. You are using a technical user if the field Store user password (encrypted) in the Authentication panel is No (see Authentication). If this is the case, you must accept a warning about this in order to enable pre-caching.
See below for an explanation of the DME concept of pre-caching.
Pre-caching is a mechanism to reduce the time it takes to synchronize e-mails to the DME client. This mechanism was introduced in DME 3.5 Service Pack 7. Pre-caching does not require any new client.
Whenever the notification scanner detects a change in a user’s mailbox, a request is sent to the connector in charge of synchronizing that user’s e-mail. On receiving the request, the connector immediately begins to build a read-ahead cache where links to the user’s e-mails are stored. When the cache is complete, the notification scanner sends a push using Adaptive Push to the client with information that new e-mail has arrived. When the client connects to the server in order to pick up new e-mail, the synchronization request is routed to the pre-built cache, and the new items are immediately available. Before synchronizing, the connector checks if a new e-mail has arrived in the space between the building of the cache and the actual synchronization by comparing the latest e-mail in the cache with the latest e-mail in the collaboration system.
If the cache exists already, it will be used if it is less than 30 minutes old. This means that any changes such as marking read/unread, moving to folders etc. that have been made in the collaboration system within this period of time will not be reflected in the DME client until the next synchronization.
If the cache is older than 30 minutes, the mailbox content from today and yesterday, including changes due to marking read/unread and moving to folders, is read out from the collaboration system and merged into the cache.
The cache is removed when the client synchronizes. See illustration below.
This applies to push, scheduled, and manual synchronization. In case of an import, the cache is never used.
Benefit
The user will experience significantly faster e-mail synchronization when receiving a push, because the server can compare the contents of the client's mailbox with the cache and does not need to contact the collaboration system for anything other than getting the new e-mails (or information about deleted or read e-mails, or whatever is required by the changes discovered in the mailbox). This speed optimization is especially significant on devices that do not support e-mail synchronization as a background process (as in Apple's iOS).
Security
The cache stored on the connector does not include the e-mails as such, only an MD5 checksum and a reference to the e-mail (a so-called minimal note). The e-mail content is stored securely in the collaboration system mailstores.
S/MIME
Due to the way in which S/MIME e-mails are handled by the collaboration system, enabling pre-caching will not benefit overall system performance if most of your e-mails are S/MIME. In other words, if your users primarily send and receive S/MIME e-mails, you should not enable pre-caching on the server.
Click Save configuration to save the current configuration.
Next topic |