Shared settings for connectors

Some of the following settings are used in multiple connectors:

You must give each connector its own name using the Name field. The name must be unique compared to other connectors from the same area. The name helps you to distinguish different connectors. You can use it to briefly describe the function of the connector.

Depending on the type of connector, it can be used either on multiple Gateway Roles in parallel or only on a single role. Select the Gateway Roles on which you want to operate the connector.

A smarthost is a dedicated server for the delivery of emails. Smarthosts are located, for example, with your Internet provider or in your own company network, if emails may only be sent via this server.

  • On the Dedicated server page, enter the server name (recommended) or the IP address and port of the dedicated server.
  • If the server requires authentication, enter the user name and password.

TIP: To check whether the password you have is the same as the configured password after you have finished the configuration, click Verify.

NoSpamProxy supports the Basic method. With this method, user name and password are transmitted unencrypted over the Internet. If your provider supports this, you should activate connection security for the connections.

You must configure the options for connection security to smarthosts as described under Connection security. SMTP send connectors for emails to external addresses use the certificate-based identity as client identity.

Connection security of an SMTP smart host

NOTE: If you send emails to external addresses through another smarthost and force encryption in the trust settings for a domain, the emails will fail to be sent to that domain if the smarthost does not support encryption for the respective email. You have to make sure that the smarthost for the emails always supports StartTLS.

Direct delivery via DNS servers will try to deliver the emails directly to your target servers. Define the necessary connection security for this connector. You can also store a specific client identity here so that NoSpamProxy can authenticate itself to other servers.

The connection security defines the encryption of the transport connection. The dialog described here is used multiple times for the different connectors. In some connectors, individual configuration options are hidden. This concerns the encryption on the transport route. This does not refer to end-to-end encryption.

Settings for connection security

In the Security Settings section, you can set the level of security for sending emails to local addresses. The following settings are available:

Allow connection security through StartTLS (recommended) In this mode, encryption of connections is possible but will not be forced. The encryption of the connection via StartTLS is optional for the inbound server. A certificate in the section Server identity for receive connectors is required. Optionally, to provide proof of identity of the send connector, you can provide a certificate in the area Client identity.

Demand connection security through StartTLS If you want to ensure that all connections are encrypted using the appropriate receive connector, you must select this option. Now NoSpamProxy requires an encrypted connection from the sending server via StartTLS. You must provide the Gateway with a certificate in the Server identity section.

Use TLS as connection security With this setting, an SMTP connector expects a connection establishment via SMTPS. A POP3 connector expects POP3S. Only use this setting if it is absolutely necessary. The StartTLS protocol is common method for connection encryption. Usually a separate port (usually 465) is used for SMTPS, as the connection is automatically expected to be encrypted, similar to HTTPS over port 443.

Deactivate connection security With this setting, connections are never encrypted. In this case, NoSpamProxy will not offer any connection security to the inbound servers.

WARNING: SMTPS on port 25 is not RFC compliant. Instead, use a separate receive connector that you place on port 465.

NOTE: The necessary encryption level for connection with StartTLS or SMTPS is 128 bit or better. Connections with a lower encryption strength are not accepted. Furthermore, only TLS connections are allowed. SSL connections are not supported because they are no longer considered secure.

SSL certificates are required to encrypt the transport connection. The receiving email server requires a certificate as server identity to enable the encryption of the connection. The sending email client can prove its own client identity with a certificate.

Server identity An SSL certificate in the receive connector is used to provide connection security. Using the certificate as server identity at the receiving email server, StartTLS or TLS encryption is enabled. Without a certificate, the encryption for connections must be deactivated.

Client identity An SSL certificate in SMTP send connectors is used to secure the identity of the sending email server. Even without a certificate as client identity, the connection security through StartTLS or TLS can be used, because the certificate of the server identity of the receiving server is sufficient for the encryption of the transport connection.

WARNING: When adding a certificate for transport encryption by StartTLS, the Gateway Role needs read permissions for the private key. These rights for the role are granted automatically. However, you must stop and restart the Gateway Role once for this change to take effect and for the Gateway Role to be given read permissions for the private key of the certificate in use. A corresponding warning message also appears in the interface.

After selecting the certificate, you may need to enter a PIN code into the Certificate PIN (optional) field.

NOTE: Please check the entry of your PIN very carefully, as many certificates protected by a PIN code are irrevocably destroyed if entered incorrectly three times.

If SSL is forced for connections, you can determine which clients are permitted to connect in the section Required client identity by only allowing access if the counter device authenticates with a corresponding certificate.

Allow connections of any server Any server may connect.

Require a certificate The certificate to be provided by the counter device depends on the certificate selected here: For intermediate or root certificates, the counter device must authenticate itself with a certificate which contains the selected certificate in the certificate chain. For end certificates, the counter device must authenticate itself with this exact certificate.

Require a trusted certificate The certificate chain of the provided certificate must be resolvable via the certificates of the Windows certificate store.

Defining the necessary client identity

The costs are used if several send connectors can be used for the delivery of emails. In such a case, the connector with the lowest cost is used. If the email cannot be delivered via this connector, the email delivery has permanently failed. In this case no further connectors with higher costs are used.

A send connector can be configured to deliver emails only for a subset of the available DNS namespace. If several connectors apply to one email, the connector with the lowest cost is used.

By default, a namespace of * as sender domain and * as recipient domain is automatically created in a new connector. This means that there is no restriction in the DNS namespace for a new connector, since the placeholder "*" corresponds to every possible name. If the connector you have created is not to manage all domains, you must delete the default namespace and replace it with another namespace.

Connector namespaces

A connector namespace consists of a pattern for both the sender domain and the target domain. This pattern may also contain placeholders (* and ?).

Definition of a DNS namespace

EXAMPLE:  To create a send connector for external addresses that only sends emails from the domain "example.com" to the domain "netatwork.de", the following settings must be made.

Sender domain pattern Target domain pattern
example.com netatwork.com