SpamAssassin (JAM Software) - ORF Forums

Hello coolgj,

This usually happens when the 'temporary email files' folder that is specified on the Blacklists > External Agents page in the ORF Administration Tool is not excluded from virus checking, and the resident anti-virus deletes or locks the .eml before the External Agent could scan it.

Please double-check your AV settings on the ORF server and make sure that the temporary email file folder is added to your AV's exclusion list.

Please let me know if this has solved the issue.

@coolgj: How about the Windows Defender Real-Time protection (if it is installed/enabled)?

Based on the error message, this might also be a permission issue (i.e. SpamAssassin may have inadequate rights to access the file). To test this, try to run the spamassassin.exe from a command line and scan a test file in the 'temporary email files' folder you specified in the ORF settings (on the Blacklists > External Agents page). Make sure that you also enter the 'command-line parameters' you specified in External Agent Properties dialog for your External Agent (Blacklists > External Agents > [Agent Name] > Run tab). This way you can verify whether 1) the spamassassin executable can run with the extra switches, and 2) if it has permission to access the files saved in the selected 'temporary email files' folder.

For the test above, I would suggest using the EICAR standard anti-virus test file (http://www.eicar.org/85-0-Download.html). If there is any real-time malware protection on the system, it will remove it before you could scan test file with SpamAssassin.

What is the entire error message that you receive when the scan fails. The one you posted seems to be only a fraction of it. Furthermore, what is the output of spamassassin.exe when you run it from the command-line to test the file in the temporary email file folder?

Could you post the full command that you enter, including the parameters you use in the ORF settings?

I have yet to test the latest version of Spamassassin (and try to reproduce this issue), so I am not entirely sure what is causing the reported problem. However, if you are trying to connect SpamAssassin to ORF only because you find that ORF is unable to handle the incoming spam on its own, then I suggest a different approach instead i.e. we address the issue of the unsatisfactory filtering performance of ORF. Depending on how aggressive the filtering settings are, 97-99% of spam (that is 3-1 out of 100) should be caught by ORF. Any less than that indicates a technical or configuration issue. Our recommendations for a high filtering performance are summarized by our Best Practices Guide, available at http://vamsoft.com/support/docs/how-tos/best-practices-5.4.1 -- if you have not applied advice from this document before - and even if you have - I strongly suggest that you implement *all* of the "tips for higher performance" (both low and medium risk ones).

However, should you find that even with the recommended settings too much spam is allowed through, then please, send us an email to with a few recent ORF log files, your ORF configuration file (see „a few tips to get things fixed faster” at http://vamsoft.com/customer-service) and some spam samples, for analysis.

If you follow our Best Practices guide and assign the Auto Sender Whitelist test to both points (Before and On Arrival), ORF's false positive rate should be close to zero. Considering that the spam-catch rate of your ORF installation is just 78% and that legitimate emails are blacklisted when you enable certain tests (which tests exactly? - besides the GeoIP and Charset blacklist), I am confident that a technical and/or configuration problem is preventing ORF from functioning properly. If you were to send us the files mentioned in my previous post, I could review them and see if I can find any issues, as well as provide suggestions on how to improve the filtering performance of ORF.

As for JAM Software's SpamAssasin, I will try to reproduce the reported issue in our lab and get back to you as soon as possible.

Hello coolgj,

Thank you for your patience. I believe I have found the solution to your problem. Apparently the issue seems to be with the pipe redirection '<' (STDIN) when used as a command-line parameter in ORF. The < and » pipes are features of the windows command prompt (cmd.exe), so the standard Windows process APIs that ORF uses do not understand them. The workaround to this issue is to create a batch file that calls the spamassasin.exe with the correct parameters, which in turn can be interpreted by cmd.exe. So, the correct settings are the following:

[ORF External Agent Properties]
Agent executable: C:\Windows\System32\cmd.exe
Command-line parameters: /Q /C ""C:\Program Files\JAM Software\SpamAssassin for Windows\sa.bat" {EMAILFILESPEC}"

[Batch file - sa.bat]
@echo off
"C:\Program Files\JAM Software\SpamAssassin for Windows\spamassassin.exe" -e < %1
exit %ERRORLEVEL%

Make sure that the double quotes are not omitted anywhere as they are required if the file path contains any whitespace characters.

Please let me know if this has helped.