- Installing the root certificates:
In order to verify signed documents, the root certificates used by the trust centers must be installed. You can download a zip archive with the certificates recommended by Secrypt using the following link: http://www.secrypt.de/downloads/6wb8212103bd/secrypt/certificates/secrypt_issuer_certificates.zip
Unpack the ZIP file into the certificate folder of your digiSeal product on your hard disk.
If you are using the digiSeal server, please use the configured directories. These can be found in the Administration/Basic configuration/Exhibitor certificate directory section and for each verification process in the Process configuration/Verification/Certificate directory section. Update these directories with the new certificates and restart the processes.
If you are using digiSeal Reader, you can find the folders here:
Win 7/Vista: C:\ProgramData\digiseal ****\certificates\issuer_certificates
Win XP: C:\Documents and Settings\All Users\Application Data\digiSeal ***\certificates\issuer_certificates
- Checking the authenticity of the ZIP archive:
To verify the authenticity of the Zip archive you can use the following signature: http://www.secrypt.de/downloads/6wb8212103bd/secrypt/certificates/secrypt_issuer_certificates.zip.p7s
The digiSeal reader is available to you free of charge as test software. The authenticity of the ZIP archive is confirmed when the verification has been carried out successfully and the signature has been created by us.
The following is an excerpt from the Cisco Knowledge Base:
If you use Transport Layer Security (TLS) encryption for e-mail communication then the ESMTP inspection feature (enabled by default) in the PIX drops the packets. In order to allow the e-mails with TLS enabled, disable the ESMTP inspection feature as this output shows.
CiscoASA# config t
CiscoASA(config)# policy-map global_policy
CiscoASA(config-pmap)# class inspection_default
CiscoASA(config-pmap-c)# no inspect esmtp
CiscoASA# wr me
In ASA version 8.0.3 and later, the allow-tls command is available to allow TLS email with inspect esmtp enabled as shown:
policy-map type inspect esmtp tls-esmtp
allow-tls action log
no inspect esmtp
inspect esmtp tls-esmtp
This article describes how to export the static trust settings.
To extract the static entries from the trust positions, proceed as follows:
- Open SQL Management Studio (Express) to manage your Mail Gateway database.
- Connect to the database server on which the “NoSpamProxyDB” database is located.
- Create a new SQL query for the NoSpamProxyDB by clicking “New query”.
- Insert this query into the query / query editor:
SELECT Domain, Gravity, LevelOfTrust
WHERE (Gravity = 0);
Perform the query by clicking on the red exclamation mark.
This query lists all static entries in the domain trust. If you need a program to import into version 7.6, or if you have problems executing these commands, please contact our support team. With this query you can avoid the use of our “Mail Gateway API-Sample” for reading domain trusts.
Please also consider that the static domain trust settings for known email providers are automatically entered by the setup during a new installation.
Emails are a popular medium for distributing malware. While most malicious attachments are reliably detected by the integrated CYREN Antivirus Filter, new malware can occasionally go undetected. With the help of NoSpamProxy, however, it is possible to block potentially harmful attachments, to allow only senders considered trustworthy by the Level of Trust or to quarantine them.
Please note that the quarantine functionality requires a working Web Portal and Large Files license.
Creating a content filter to block, filter or quarantine attachments
- Go to Configuration > Content filter > Content filters.
- Click Add, enter a name for the filter and click Next.
- In the Content filter entries dialog, click Add.
- In the Content filter entry dialog, enter a name for the entry and configure the entry according to your requirements.
- Click Save and close.
- (Optional) Repeat steps 3 and 4 if needed.
Activating the content filter for all inbound emails
- Go to People and identities > Partners > Partners > Default partner settings and click Modify.
- On the Content filtering tab, for inbound emails select the filter you just created.
- Click Save and close.
It is also possible to define your own content filtering for individual senders, e.g. to allow certain attachments from certain senders that are otherwise prohibited.
To do this, adjust the respective content filter according to your requirements and activate it
- for the entire sender domain (e.g. example.com) or
- for individual users within a domain (e.g. “support” as part of example.com, i.e. email@example.com).
Please note that these filters will override the global and domain-specific default settings.
List of potentially harmful attachments and recommended procedure
Please note that these are only recommendations of a general nature and are not suitable in every scenario.
Starting with version 11.1 you can automatically release files after a period of time (default 2 hours) after a new scan by the Cyren engine has been performed and returned no positive results. This procedure is especially recommended for attachments to be quarantined according to the list below. Usually, malicious content is detected after 30 minutes at the latest. While the content is not yet detected as harmful when it arrives, this can often be the case after a short time.
The WebPort is the port to which the MMC connects when accessing the individual roles. Furthermore, the roles connect via the configured port and count 1. If the WebPort is configured to 6060, the services connect via 6061. You should only change this port if it is necessary.
To change the WebPort, proceed as follows:
First, stop all NoSpamProxy services. The corresponding setting is made in all configuration files. These files can be found in the configuration directory under “C:\ProgramData\Net at Work Mail Gateway\Configuration\”. If you also use the WebPortal, you will find the corresponding configuration files under “%Program Files%\Net at Work Mail Gateway\enQsig Webportal\App_Data\”.
Look for the line that begins with the following characters:
Add the following attribute:
port="6060" (the new port value must be entered here).
The line should now look like this:
<netatwork.nospamproxy.webservices serverCertificateThumbprint="xxx" port="6060" />
serverCertificateThumbprint will look different on each NoSpamProxy server.
Now, change the URL reservation via
netssh. The HTTPSYSMANAGER tool from http://httpsysmanager.codeplex.com/ makes this easy. Alternatively, enter the following command on the command line:
netsh http add urlacl url=http://+:8060/NoSpamProxy/ sddl=D:(A;;GX;;;LS)(A;;GX;;;NS)
Restart all services now.
Switch to the new port in the MMC.
Then re-create the role connections.
In some cases, the NoSpamProxy Outlook Add-in is deactivated due to long loading times. This article describes procedures for changing this.
- Long loading times
If you have installed a local virus scanner on the client system, you should exclude the real-time scan for the following directory:
C:\Users\<<<username of the logged in account>>\AppData\Local\Assembly
This directory contains the DLL files for the Add-in, which change with every update. Thus the entire directory should be excluded from the real-time scan.
- Prevent deactivation, despite long charging time
You can change the Load Behaviour for the Add-in, ideally to Load Behaviour = 3 in the registry.
Registry Path = HKEY_CURRENT_USER \ SOFTWARE \ Microsoft \ Office \ Outlook \ Addins \ Netatwork.MailGateway.OutlookAddIn
MS Technet Articles = https://msdn.microsoft.com/en-us/library/bb386106.aspx#LoadBehavior
If you use NoSpamProxy Large Files behind Microsoft TMG, you will get error messages if you send files containing umlauts via NoSpamProxy. The error message is very cryptic and only indicates that it is an internal server error. A 500 type error message is displayed. The reason for this message is the use of so-called high bit characters, which are forbidden by default in Microsoft TMG as part of the HTTP security filter.
If you activate logging in TMG, you will see that a connection has been denied:
To solve the problem, the high bit character must be allowed in the HTTP policy in the rule.
For security reasons, GlobalSign limits the API to certain request IP addresses. In order for you to successfully complete your requests, you need to store the public IP addresses of your gateway roles with GlobalSign.