NUL characters (bytes with value 0) are not allowed in email messages and should not be transmitted over POP3, SMTP or IMAP4 except in certain circumstances. If an attachment contains such a byte it must be encoded using Base64 or Quoted-Printable encoding so that the transmitted data doesn't contain a NUL character.

In some cases, messages will arrive at VPOP3 which do contain such characters. This is usually due to a bug in the upstream mail server which has accepted a message with a NUL character and is passing it on unchanged. The email standards say that these characters are not allowed, so they should not be passed on.

So, the ideal solution would be for the upstream mail server to sort the problem out, as the problem is coming from there (they should either reject the message, or recode the message to base64 or quoted-printable encoding).

If that is not possible, then you can make VPOP3 handle the problem differently. VPOP3 can either remove the nul character totally, or replace it with a specified character (eg a space or question mark)

To do this for POP3 collection (the usual time it is needed) go to a command prompt in the VPOP3 directory and run:

vpop3settings set POP3CltNullCharacterReplacement <asciicode>

For instance, to make VPOP3 set NUL characters to spaces, use:

vpop3settings set POP3CltNullCharacterReplacement 32

You can also use Imap4SvrNullCharacterReplacement, NNTPCltNullCharacterReplacement, and SmtpSvrNullCharacterReplacement to set the NUL character replacement for those components, but these are less likely to be needed.

If you have an incoming SMTP mail feed, then the default setting is that NUL characters in incoming messages will cause the message to be rejected, which is usually the desired behaviour.

Set the <asciicode> to '0' to have the characters rejected, '255' to have them skipped, or any other ASCII code (1 to 254) to have them replaced with that character