Smartermail Antispam checks are done prior to the Incoming message being moved to the Spool Proc folder. The reason these Antispam checks are done first and foremost is so that Smartermail can determine whether to block the message if it exceeds your Incoming Weight Threshold for those Spam checks that have Enabled for Incoming SMTP Blocking. After Antispam checks it then moves the message to the Spool Proc folder for additional processing, such as Declude or MailSniffer, or other third-party applications.

 

To be honest I can't recall whether Incoming messages are sent to the external SpamAssassin server before they are moved to the Spool Proc folder or after they are returned to the primary Spool. I'll have to double-check. However, if it is after then you can disable the Antispam check in Smartermail and enable that Antispam check in your external SpamAssassin server, in which case you could enable your Spool Proc folder, have a Scheduled Task to fire a script at 1 minute intervals that moves messages older than XX minutes back to the Spool, and have your external SpamAssassin server do the Antispam checks.

Hi Colin,

I'm still using this Node.js scheme and its working perfectly. However, I also have a second mail server, a free smartermail one configured as a backup MX, er, actually, its now configured for domain forward in SM gateway mode. In any case, recently, spammers have discovered this second server. I have the antispam setup the same way as on the primary, without bayesian of course. But without the spam delayer code running, it is subject to the same issues you describe above.

So, I set the whole thing up over on that server and couldn't understand why it was simply moving all the messages back into the queue. The answer was that on the backup mx box the SM configuration has not users or domains, so the .HDR files all have the last line as:

containsLocalDeliveries: False

Which causes a failure in our code here:

            if (lines.length > 5 &&
                lines[1].match(/@/) &&
                lines.some(function(line){ return line == 'containsLocalDeliveries: True'; })

....which in turn causes the code to write the files immediately back into the spool.

I modified that bit so it looks like:

Hi,

 

we use declude, which gets the mails from the proc folder, I would like to use this but I see it will most likey create an issue, as declude and the delayer will try grab the files from the proc folder, is there a way to maybe get SM to deliver to a folder lie "delay" then the delay prog scans them and then once the peiod is over return them to the proc folder where declude can run its own checks and return them to the spool folder ?

 

it would be nice to be able to use both