Info Icon


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.


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.


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.


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.


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:

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.


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:

  • 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.


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:<> 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.


In some cases, the NoSpamProxy setup fails due to problems regarding PowerShell RemoteWIN. To resolve this issue the registry needs to be modified.

To do this, open PowerShell and enter

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f​.


If Outlook is configured in such a way that emails remain in the outbox after clicking on Send immediately when connected, a problem can occur if you look at the email again before the fact. In this case, the email is returned to draft mode and must be returned to send mode by clicking Send again before it can be sent.

This is not a specific behaviour with the Outlook Add-in, but a general Outlook behaviour.



After installing Windows updates on the Windows servers, a growing number of users are reporting that parts of the Outlook Add-in for NoSpamProxy are no longer displayed. However, the add-in seems to be installed correctly and functioning a expected.

With the latest Windows updates, Microsoft has tightened the security settings for access to group policies. As a result, users can no longer retrieve them. Microsoft describes the solution in its Knowledge Base:



Although the configuration for SwissSign is correct under “Cryptographic key providers” and all gateway roles have access to via TCP 443 (https), the following error message appears in the event log when retrieving certificates:

ID: 026f7e58-9be2-4434-b562-11016c181bfd
Created: 12.06.2015 12:15:56
Mail address:
Request type: CertificateRequest
Request status: Failed
Failure status: TrustCenterError
Error text: Unexpected error: Message:
An error occurred while sending the request.
Error type:

Error code: 2148734208
Program location:
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Netatwork.NoSpamProxy.Cryptography.SwissSignCertificateProvider.<EnrollAsync>d__e.MoveNext()

The request was aborted: Could not create SSL/TLS secure channel.

The request was aborted: Could not create SSL/TLS secure channel.
Error type:

Error code: 2148734217
Program location:
at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)

Subject, CN=Secure Mail: Gateway Certificate


Both in the certificate store of the computer account of one or all gateway roles and in the certificate store of the NoSpamProxy Encryption Gateway there is the pseudo-AutoRAO service certificate for authentication at the service provider SwissSign.


  1. Under “Cryptographic key providers” open the configuration for the provider SwissSign. Here you will find the deposited pseudo AutoRAO certificate.
  2. Click on the certificate to display its details. These details are helpful for identifying the correct certificate in the certificate store of the computer account.
  3. Open “mmc.exe” as administrator on the gateway role.
  4. Click File and Add/Remove Snap-in.
  5. Select Certificates and click Add.
  6. A new window appears in which you select the “Computer account”.
  7. Click”Next”.
  8. Select the “Local computer”.
  9. Click  “Finish”.
  10. Return to the snap-in selection and confirm with “OK”.
  11. Navigate to “My certificates” and find the pseudo AutoRAO service certificate.
  12. Select the certificate and delete it.
  13. Restart the affected Windows system of the gateway role.

If necessary, repeat these steps for all other gateway roles.