Messaging Gateway

What is SESC and what are the benefits?

The Symantec Email Submission Client (SESC) is an application that will help in a very comfortable way to submit email messages not detected by the AntiSPAM solution.

Everyone knows the current methods of submitting emails available from Symantec or other vendors like the following.

• Additional software that must be installed on all clients, that creates dependencies to for example the mail client. So it’s quite obvious that other devices or access methods were not supported or existing.
• Another possibility of the past was to forward the email properly with all the necessary header and I think every email administrator or spam analyst is thinking of the explanation for the users “how to do that”.

The SESC’s great benefit is that it works close to the Microsoft Exchange and is able to perform the submissions more easy and device independent. Due to the fact that SESC is performing its activity where the Client Access takes place it can handle beside the known mail clients the until now not covered services like ActiveSync, OWA, Blackberry etc.

So Symantec achieved as first one to have a feasible and convenient submission tool that is also able to deal with enterprises.

How it looks like for users?

 Users View

The regular user has a folder Report Spam (default) in his mailbox to report emails based on the submission type either directly to Symantec (Direct Submitter via Direct Submissions or Customized Submission) or the Moderator (Moderated Submitter via Moderated Submissions or Customized Submission).

Moderators View

The Moderator has 2 folders that were defined during the SESC setup. One Folder is Submit Spam (default) to be used by the SESC to put the email items from the users that want to report the email in a moderated submission mode.

The folder Report Spam (default) is having the same functionality as explained for the Users View, but is only used for the direct submission to Symantec.

How SESC is working?

The SESC is using the Exchange Web Services that will come with the Exchange CAS Role. The EWS is providing the access to the items to create/update/delete the folders (Report Spam, Submit Spam) in the mailboxes, and to get the email to submit and report. The authorization for this is done using a service account.

Regarding data protection it needs to be considered that the service account used for this SESC activity has full access to the mailboxes. Therefore it is recommended to separate the user for administrating SESC and EWS/Service use. In addition the user for EWS/Service should be handled really secure due to this permission.

When a user will receive a message he simply uses drag and drop or move the email to the folder to report the message. Also server side mailbox rules are possible to automatically move items.

When the item is stored in the Report Spam (default) folder and SESC recognizes the email, it will use the EWS to get the item and put it in the Moderators Submit Spam (default) Folder. On the user side the item will be deleted and end up in the Deleted Items Folder.

The Moderator will now see the full email with its headers and can verify whether the email is valid to submit or not. In case the Moderator can move the item to the Report Spam Folder to interact as Direct Submitter to provide the sample email to Symantec.

Once the SESC is recognizing the email in a Direct Submitters’ Report Spam Folder, the SESC Service will get the item through EWS and establish a secure connection (HTTPS) to the Symantec upload Server.

Also in that case the email will get deleted and end up in the Deleted Items Folder of the Moderator.

Three steps to technical implement SESC…

Users and Permissions

As mentioned in “How SESC is working” it makes sense to separate the administrative account and the SESC Service Account.

Administrative Account to install and Manage SESC

Active Directory

• Domain User
• Local Server Administrator
• SESC Admins

Temporary Domain Administrative Permissions for creation of “SESC Admins” Global Security Group and correct discovery of Exchange Servers and Sites.

Installation of SESC

Installation of SESC as described in the “Implementation Guide” of Symantec. During installation you need to decide between Exchange 2007 and 2010. In case you have both environments you should have two SESC installations.

Furthermore it makes sense to use a dedicated system that is not hosting Exchange regarding performance.

Configuration of SESC and post installation tasks

Open Console for the first time (Note. It can take a few minutes and nothing will be displayed except the process for the UI)

Regarding the configuration there is nothing really special from application point of view, but for enterprises it may be following to be considered.

The CAS URL for accessing the Exchange Web Services can be also use load balancing (In case just put in the virtual name of the CAS farm), so the high availability is given. In that case you have a CAS farm put the certificates of Symantec as mentioned on all the CAS Servers.

Furthermore the schedule for updates should be choosen at a time when there is not much CAS traffic as well as other Exchange maintenance task.

Nice to know

Restarting/Starting the service from the console ends up with an error on the console side in earlier versions.

The application is not writing in the Application Event Log. After a few seconds the Application is running. In case just use the Services to restart the SESC Service.

Symantec fixed this in the official released version and also the time to restart from the console decreased considerably.

Enable the debugging logs for SESC can be don’t in C:\Program Files\Symantec\SESC\1.0\bin\SESC.exe.config

Restart the SESC Service.

Now the debug logs will be written in the default logfile. (Logfile will increase more than usual)