Info Icon

Locally signed emails are permanently rejected due to invalid S/MIME signatures

Problem

Inbound, 8-bit encoded emails that are signed locally by S/MIME are converted into 7-bit encoded emails by NoSpamProxy and then rejected by the receiving email server because of an invalid certificate.

Analysis

RFC 5751 requires that all signed MIME parts of an email must have 7-bit encoding:

If a multipart/entity signed is ever to be transmitted over the standard Internet SMTP infrastructure or other transport that is constrained to 7-bit text, it MUST have transferred encoding applied so that it is represented as 7-bit text. MIME entities that are 7-bit data already need no transfer encoding. Entities such as 8-bit text and binary data can be encoded with quoted-printable or base-64 transfer encoding.

To ensure full compliance with RFC 5751, NoSpamProxy converts the 8-bit encoding of the email into a 7-bit encoding.

However, because the signing was applied locally and not by NoSpamProxy, the conversion changes the hash value of the email and thus invalidates the signature. Accordingly, NoSpamProxy will permanently reject the email from version 13.2.20258.1435.

This scenario only occurs if the “Remove attached signature from S/MIME-signed emails (recommended)” option has been disabled in the NoSpamProxy rulebook and the email client sends 8-bit encoded emails.

Workarounds

Workaround 1: Enable opaque signing

Microsoft Outlook

Configure your email client to use the opaque signing method when applying the signature. This method summarizes the signature and message into a single binary file so that the signature remains intact when the email gatewaysmodify the email message.

Do the following:

  1. Open Microsoft Outlook.
  2. Go to File > Options > Trust Center Settings > Email Security.
  3. Remove the check mark for Send clear text signed message when sending signed messages
    Enabling opaque signing in Microsoft Outlook
  4. Click OK.

By disabling this option, you have enabled opaque signing.

Microsoft 365/Outlook on the Web, Exchange Server 2013, Exchange Server 2016, Exchange Server 2019, Exchange Online

You can also configure opaque signing using PowerShell:

Set-SmimeConfig -OWAClearSign $false

For more information click here.

Receiving email clients that do not support S/MIME cannot process emails signed using opaque signing.

Workaround 2: Remove local signatures

Configure NoSpamProxy to remove locally applied signatures.

Corresponding emails can be delivered in this way, but lose their S/MIME signature.

  1. Go to Configuration > Rules.
  2. Open the appropriate rule for inbound emails.
  3. Go to the Actions tab, open the S/MIME and PGP validation as well as encryption action, and go to the Validation options tab.
  4. Place the check mark for Remove attached signature from S/MIME-signed emails (recommended).
  5. Click Save and Close.
/by
info icon

The Intranet Role fails to start when using TLS 1.2

Error

The NoSpamProxy Intranet role fails to start if the NoSpamProxy server is configured to use the TLS protocol exclusively in version 1.2 for connection encryption.

Solution

The problem is triggered by the version of Microsoft SQL Server used. For TLS 1.2 to work as the sole encryption protocol, your SQL Server must support encryption with TLS 1.2.

The following article describes the version requirements for Microsoft SQL Server TLS 1.2:
https://support.microsoft.com/en-gb/help/3135244/tls-1-2-support-for-microsoft-sql-server

Please note that the exclusive use of TLS 1.2 as connection encryption does not reflect the settings we recommend as it may compromise compatibility. A corresponding message is displayed under Issues on the Management Console home page.

/by
info icon

The DNS server is blocked by a spam URI Realtime Blocklist

Starting with version 13.1 NoSpamProxy issues a warning if a used DNS server is blocked by a Spam URI realtime blocklist.

DNS server is blocked by Spam URIRBL

DNS server is blocked by Spam URIRBL

What is the significance of this?

This message informs you that the DNS server you are using and which you have configured in the Windows network settings or via the NoSpamProxy console under Configuration > Connected Systems > DNS Servers is blocked on the spam URI Realtime Blocklist. All DNS queries to the URIRBL are thus not answered and the spam protection is slightly weakened.
In most cases, the reason for this is that the free queries from the requesting DNS server are used up, since the lists only allow a certain number of free queries.

How can this be fixed?

The following options allow further requests beyond the free limit of spam URI realtime blocklists:

  • To reduce requests, features like QNAME Minimization (RFC 7816) should be disabled for the NoSpamProxy Gateway role.
  • Using your own DNS server, which only handles your requests (recommended)
  • Change the DNS provider where the limit has not been used up (not recommended)
  • Registration with the operator of the Spam URI Realtime Blocklist to send requests beyond the free limit (usually subject to a fee, DNS server independent)

Another DNS server can be set without much effort via the NoSpamProxy console under Configuration > Connected Systems > DNS Servers. After setting up a new DNS server, the service of the gateway role(s) must be restarted to clear the DNS cache.

We cannot make recommendations for DNS servers, because there are a large number of free providers in this area.

In addition, we would like to point out that this problem is not caused by NoSpamProxy and must be communicated with the corresponding operator of the DNS service.

/by
info icon

What does “Message delivered via relay” mean?

In Message Tracking, messages will appear where the subject begins with “Message delivered via relay”. The reason for this is that the sending SMTP server requests a “Delivery Notification” in the SMTP envelope. However, these notifications are not supported by the receiving SMTP server. These notifications are requested via the NOTIFY parameter of the RCPT TO command, e.g.

RCPT TO:<alice@example.com> NOTIFY=Delay,Failure

Depending on the request this must be altered accordingly on the sending side or the receiving side. This behaviour cannot be changed by NoSpamProxy.

/by
info icon

Emails are rejected with a Base64 error

Error:
Emails are rejected by NoSpamProxy even though the Level of Trust Filter has marked them as trusted. In message tracking and in NDR the following reason is given:
“A part of the email could not be decoded. System.formatException: Invalid character in a Base-64 string.”

The following error message is displayed in message tracking:
“The Base64 encoded content was invalid.”

Status:
The problem with the email in question is the NoSpamProxy security check. NoSpamProxy detects a conflict with the RFC’s in the body. It does not have a Base64 encoding and is therefore rejected. This security check can only be disabled in the configuration file of NoSpamProxy.

Solution 1:
Version 7.x and 8.x:

The configuration file to be changed is called “antispamrole.config” and is located in the program directory of NoSpamProxy under “..\nospamproxy\AntiSpam Role\config”. Please note that you can only save the file when the NoSpamProxy service is finished. Otherwise the change will be discarded.

Please search for the following line in the file first:

</netatwork.nospamproxy.proxyconfiguration>

Insert the following key directly above this line:
<dispatchInvalidMails isEnabled="true" />

The result should look as follows:
<dispatchInvalidMails isEnabled="true" />
</netatwork.nospamproxy.proxyconfiguration>

Save the file and restart the NoSpamProxy Service. Now the emails should be received.

From version 9.x:

From Net at Work Mail Gateway 9.x or NoSpamProxy 10.x:
The configuration file to be changed is called “Gateway Role.config” and is located under “C:\ProgramData\Net at Work Mail Gateway\Configuration”. Please note that you can only save the file when the gateway role is finished. Otherwise the change will be discarded. The change must be made on all gateway roles.

Please search for the following line in the file first:

</netatwork.nospamproxy.proxyconfiguration>

Insert the following key directly above this line:
<dispatchInvalidMails isEnabled="true" />

The result should look as follows:
<dispatchInvalidMails isEnabled="true" />
</netatwork.nospamproxy.proxyconfiguration>

Save the file and restart the Gateway Role. Now the emails should be received.

Solution 2:

Version 7.x and 8.x:

Alternatively or additionally there is the possibility of a repair attempt by the Net at Work Mail Gateway. It will then try to ignore the superfluous characters or to fill in the missing characters to get a valid encoding. This does not always work, but can be helpful.

The configuration file to be changed is called “antispamrole.config” and is located in the program directory of NoSpamProxy under “..\nospamproxy\AntiSpam Role\config”. Please note that you can only save the file when the NoSpamProxy service is finished. Otherwise the change will be discarded.

Please search for the following line in the file first:

</netatwork.nospamproxy.proxyconfiguration>

Insert the following key directly above this line:
<encodingOptions invalidBase64LengthHandling="IgnoreExtraCharacters" />

The result should look as follows:
<encodingOptions invalidBase64LengthHandling="IgnoreExtraCharacters" />
</netatwork.nospamproxy.proxyconfiguration>

Save the file and restart the NoSpamProxy Service. Now the emails should be received.

From version 9.x.

The configuration file to be changed is called “Gateway Role.config” and is located under “C:\ProgramData\Net at Work Mail Gateway\Configuration”. Please note that you cannot save the file until the gateway role is closed. Otherwise the change will be discarded. The change must be made on all gateway roles.

Please search for the following line in the file first:

</netatwork.nospamproxy.proxyconfiguration>

Insert the following key directly above this line:
<encodingOptions invalidBase64LengthHandling="IgnoreExtraCharacters" />

The result should look as follows:
<encodingOptions invalidBase64LengthHandling="IgnoreExtraCharacters" />
</netatwork.nospamproxy.proxyconfiguration>

Save the file and restart the Gateway Role. Now the emails should be received.

Both solutions do not work together until version 9.2. If you choose solution 2, there is no fallback to solution 1 if the Base64 decoder cannot repair the email. Starting with NoSpamProxy 10 both can be used together.

/by
info icon

No content can be displayed in the Management Console for user A, but for user B

Error:

The NoSpamProxy Management Console can be started, but crashes if a submenu is opened. This problem does not occur with another or new users.

Status:

The NoSpamProxy Management Console creates temporary files in the temporary folder of the user directory. However, this folder contains more than 65,535 files, which leads to problems in the NTFS file system.

Solution:

The affected user executes the following command via Start -> Run:

rmdir /s /q %temp%

When the operation is complete, the console will function properly again.

/by

Smartcards over remote USB connections do not work

Error:

If smartcard readers are used that are controlled via a network USB port, either the smartcard or the token on the smartcard itself is not displayed.

Status:

This error occurs whenever the connection is established in an RDP session.

Solution:

The smartcard connection via a network-based USB connection should be established via the Hyper-V Manager or the VMWare Manager via a direct connection to the VM.

/by
info icon

The event viewer repeatedly displays warning 1088

Behaviour:

The event viewer repeatedly shows the following message:

---------------
Gateway Role 1088:
Could not secure an inbound connection with the host 192.168.0.100:53627.
Die angegebenen Daten konnten nicht entschlüsselt werden
Error type:
System.ComponentModel.Win32Exception
Error number:2147500037
Program location:
---------------

As a result, an SChannel error will appear in the Windows applications event viewer. It may look like this:
---------------
SChannel 36887:
Es wurde eine schwerwiegende Warnung vom Remoteendpunkt empfangen. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 51.
---------------

Please note that ID and code may differ.

Explanation:

Windows 2008 R2 and later does not support older, weak cipher suites, which are considered cracked. Therefore, a TLS connection is not established if the delivering server can only process these. As a result, the above-mentioned warnings and errors are logged. The delivering server must then perform a fallback to plain text. For this it is necessary that the delivering server establishes a new connection, since the old connection, where no TLS connection could be established, must be closed.

/by