We've finally *just* been able to reproduce this. Thank you a LOT for the patience and the help. I can confirm everything is a suspected. SpamFilter is replacing the NULL character with the ".", and its placement just happened to be between the <CR><LF>.<CR><LF> sequence causing the email to be terminated.

While we come up with a permanent fix, the good news is that there is actually a very easy workaround that so far seems to avoid the problem.

In the SpamFilter.ini file, simply change the following setting to "1" (there is not even the need to restart SpamFilter after the change...)

We received the files, and were finally able to pinpoint the issue thanks to your wireshark capture.

Please see the first screenshot showing the incoming file to SpamFilter. What you see is not a period between the <CR><LF> separators. Wireshark shows that it is actually a NULL character (byte value of 0). This is a control character that, per RFC, should not be used in the mail body. 

SpamFilter does receive the email successfully, and however this is where the 2nd part of the problem begins (the first part is the remote server sending an invalid NULL character....). 

Please now see the second screenshot showing the outgoing email from SpamFilter to your destination SMTP server. When SpamFilter forwards the email, it tries to "fix" the invalid NULL character and replaces it, of all things, with the "0x2e" character, which happens to be the period. Since this period, (un)luck has it, is surrounded by the <CR><LF> sequence, this just happens to indicate the end-of-email sequence and thus your destination SMTP server obviously stops receiving the email.

This has got to be one of the most unlucky sequence of events we've seen...

I'll try to see if there's anything we can do to either prevent SpamFilter form autofixing the invalid NULL characters, or to at least replace them with a different, non-dot, character...!

We received the logs, and as you said, this is going to be an interesting issue... The only way we're going to be able to see what is happening is by actually "seeing" what the original email looks like.

SpamFilter does have a "Debug" tab to capture SMTP traffic, but it doesn't capture *all* of the email's body, so it's not going to help here. What would help would be to install either WireShark (Etherreal) on the SpamFilter server (or any other packet capture utility), and capture all SMTP traffic from the remote server (I'll send you the IP common to the 2 emails in the logs via email).

If you'd like, you could also provide our address to the vendor to copy us as well on the emails. We can then run the packet capture on our end and try to get to the bottom of this. Please let us know in advance if you'd like for us to run the trace so we can setup up our end before they send the emails.