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.