After the installation
After completing the installation, you will find an entry for the NoSpamProxy Command Center in the start menu, if you have installed it.
If you have installed all roles on the same server, a link to the configuration wizard appears on the overview page of the configuration interface. You can use this wizard to import your license and complete the configuration of NoSpamProxy.
Setting up the DNS configuration
Automatic sender identification enables the receiving server of an email to clearly determine whether it actually originates from the specified sender. In addition, the server can determine whether the submitting server is authorised to deliver emails on behalf of the sending domain. This is made possible by the use of special methods for sender identification, which are becoming more and more widespread as standard tools for email security. The individual methods are described under the abbreviations
- SPF (Sender Policy Framework),
- DKIM (DomainKeys Identified Mail) and
- DMARC (Domain-based Messaging, Authentication, Reporting and Conformance)
and build on each other. With DANE (DNS-based Authentication of Named Entities), a procedure for validating the recipient is added.
The corresponding information on SPF, DKIM, DMARC and DANE must be published in the DNS configuration of the respective company domain and thus made available to the external communication partners. In this way, the communication partner is given the opportunity to establish beyond doubt whether the email actually was actually sent from the sender displayed. In addition, the reputational risk for the corporate domains also decreases.
Video: Setting up SPF, DKIM and DMARC (German only)
NoSpamProxy on a domain controller
After installing NoSpamProxy on a domain controller, you will find the four user groups
- NoSpamProxy Configuration Administrators
- NoSpamProxy Monitoring Administrators
- NoSpamProxy People and Identities Administrators
- NoSpamProxy Disclaimer Administrators
under Active Directory > Users and Computers.
Video: Setting up email routing and connectors (German only)
Establishing the connection to the Intranet Role
The connection of the NoSpamProxy Command Center to the Intranet Role is set to localhost after installation.
If the NCC is installed on a different computer than the computer of the Intranet Role, you must adjust the connection.
Proceed as follows:
- Perform one of the following two steps:
- Click NoSpamProxy and select Action > Change server from the menu.
- Right-click NoSpamProxy and select Change server from the co ntext menu.
- Enter the name of the server (for example mail.example.com) and the port (usually 6060).
- Click Save and Close.
For the change to take effect, you must close and restart the NoSpamProxy Command Center.
NOTE: If the NoSpamProxy is operated in a DMZ and you want to control the service remotely from the LAN via the NoSpamProxy Command Center, you only need to enable TCP port 6060 on the firewall and port 6061 for HTTPS. This connection is encrypted on a certificate-based basis. For further information, see Port allocation.
Configuring the certificate for the Web App
A certificate is required so that users can use the NoSpamProxy Web App and backend services securely.
NOTE: After installation, a self-signed certificate is already stored that enables a connection to the Web App. We advise against the use of this certificate and recommend the use of a previously imported certificate to optimise security.
- Go to Configuration > NoSpamProxy Components > NoSpamProxy Web App.
- Click Modify.
- Under DNS name, enter the host name under which the Web App can be reached.
- Enter the port used and click Next.
NOTE: Port 6061 is used by default. If you want to establish an HTTPS connection, use port 443.
- Configure the certificate you want to use to secure the NoSpamProxy Web App:
- Private certificate NoSpamProxy creates both a private certificate and a root certificate. You must install the root certificate on all computers from which you want to connect to the Web App.
- Existing certificate You are using an existing certificate that you have previously purchased from a certificate authority and deposited in NoSpamProxy.
- Click Finish and restart.
Configuring installed on-access virus scanners
To solve (recurring) problems with the interaction of installed on-access virus scanners, configure your virus scanner so that the directories are
-
C:\ProgramData\Net at Work Mail Gateway\Core Antispam Engine
- C:\ProgramData\Net at Work Mail Gateway\Temporary Files\MailQueues
- C:\ProgramData\Net at Work Mail Gateway\Temporary Files\MailsOnHold
-
C:\Program Files\NoSpamProxy\Core Antispam Engine
NOTE: If you have updated from version 13, the path is C:\Program Files\Net at Work Mail Gateway\Core Antispam Engine.
be excluded from the scan on all systems with the Gateway Role or Web Portal installed.
NOTE: Note that the path is a hidden directory.
For servers with Web Portal installed, the following folder (default path for storing files for the Web Portal) must be excluded:
- C:\Program Files\NoSpamProxy\Web Portal
NOTE: If you have updated from version 13, the path is C:\Program Files\Net at Work Mail Gateway\enQsig Webportal.
Otherwise, with some virus scanners, access to the Web Portal may be severely delayed and communication problems may occur.
In addition, an exception for the processes
- amserver.exe and
- NoSpamProxy.CoreAntispamEngine.exe
should be set if the on-access virus scanner allows this.
NOTE: Make sure that your locally deployed virus scanner does not use behaviour-based analyses to draw conclusions from the fact that malware is actively stored by processes in the path C:\ProgramData\Net at Work Mail Gateway\Temporary Files\Netatwork.NoSpamProxy.Addins.Core.Actions.MalwareScan.FilebasedMalwareScanner. The files themselves should or must be checked, but the placement of malware in the folder in question must not lead to the classification of the corresponding process that performs this.
If you do not find the path described above, it is most likely an older NoSpamProxy installation that has already been updated several times. In this case, please first check the file C:\ProgramData\Net at Work Mail Gateway\Configuration\Gateway Role.config and look for the entry <storageLocation path=.
This path is currently used by the Gateway Role.
If you have enabled file-based virus scanning in the rules, also ensure that your scanner is configured to completely delete or quarantine infected files and archives. If the scanner is configured to Clean up, NoSpamProxy often cannot detect that these have been modified by the installed scanner. Thus, the "file-based virus scan" then fails despite successful detection by NoSpamProxy. This occurs particularly with archives.
Deposit of a TLS certificate for inbound connections
If a separate TLS identity is to be used in the receive connector, this must first be stored in the computer certificate store on all systems with NoSpamProxy components. Subsequently, the following service accounts must be granted read permissions on the private key:
-
NT Service\NoSpamProxyGatewayRole
-
NT Service\NoSpamProxyManagementService
-
NT Service\NoSpamProxyPrivilegedService
-
NT Service\NoSpamProxyIntranetRole
Configuring the SSL Certificate for the Web Portal
To deposit a certificate to secure the Web Portal, it must first be added to the computer certificate store. The certificate may be
- a wildcard certificate,
- a SAN certificate or
- trade a single certificate.
The certificate must then be selected for HTTPS in the bindings area of the default website.
Configuring the Large Files directory
In order to enable the full functionality of the Web Portal, especially for the Large Files functionality, the service accounts mentioned below must be equipped with the corresponding rights on the directory configured for Large Files:
- IS AppPool\enQsigPortal - Write
- NT Service\NetatworkMailGatewayFileSynchronizationService - Modify
Setting up the multiple assignment of service ports
If you want to use one port for multiple web services, you must set a Host Header. A host header is also referred to as hostname. This is used to distinguish between different services that are operated via a common port or a common IP address. For example, it is possible to operate the Web Portal and the Web App via port 443 (or another port).
Setting a host header is only possible with the help of the PowerShell cmdlet Set-NspWebApiConfiguration. Below you will find a description:
Procedure
Enter the following command in the command line:
Set-NspWebApiConfiguration -Port <ThePortUsed> -DnsName <TheDNSName> -UseHostHeader true -ShowCertificateSelectorUI
Setting the value true for the parameter UseHostHeader configures the use of the host header. In this example, the use of the parameter ShowCertificateSelectorUI also determines that a Windows dialogue is displayed, with the help of which you can specify the thumbprint of the certificate.
NOTE: After executing the cmdlet, you must restart the NoSpamProxy Command Center.