SaneSecurity signatures are not for spam control. They are additional antivirus/antimalware signatures that can utilized by ClamAV.
Spam control is is done using the built-in Spamhalter or a third party app like POPFile. Both utilize bayesian filtering through which incoming mail passes. Both add a header on which you can filter. Both must be trained.
I can't recommend one over the other because I've only used POPFile but my sense is that both are equally effective. SpamHalter is built-in so is the logical one to utilize. Support is available on this forum.
Edit: Correction... Support is available on the Mercury Community Support forum
Also, There is a guide to SpamHalter available here: http://www.vandenbogaerde.net/pegasusmail/pf_sh_index.html. It is based on the Pegasus Mail helpfile but is applicable to Mercury in most respects.
I haven't given up on this project, it's just turned out to be a lot more complicated without some guidance. I'm hoping that one of the programmers from the original mercury software will catch this and give me some more direction. Meanwhile i keep trying to work on this, does anyone know the proper way to "identify" a variable type then show it's contents? that's kind of where i'm at now... (Visual C++ 2010 Express - Using a virtual WinXP machine to code, only windows i had an extra key for VM)
Spamhalter for Mercury trying to detect this kind of faked sender's address. It is mail from local e-mail adress, but it was received from foreign server by unauthorized SMTP. So, messages with faked sender is marked as SPAM automaticly, regardless on message content.
1000 apologies for opening an old thread, but this would be quite easy to do. I write a lot of Database programs commercially and this would be quite straight forward to achieve. The *downside* is that as it would need to run as a policy, it may slow down the processing of mail as each one needs storing before the policy task completes. Have to say I don't know if Mercury processes these in parallel or series.
That aside, we can have Mercury pass the email text to an application that then inserts them into the required database.
Drop me a line if you still (after all these years!) think it's worth looking at.
As there has been questions about controlling various parts of Mercury remotely from a batch file or a program I made a commandline version of the webtools package, available here:
The program can use the same command daemon as the webserver version (included in the zip archive), but will work without it as well. If running Mercury as a service under Windows Vista or later it's advisable to use the daemon or some functions will be unavailable.
Supported commands are:
To stop Mercury the command is "MercuryConsole exit"
To put Mercury offline: "MercuryConsole offline"
To put Mercury back online: "MercuryConsole online"
To pause Mercury core: "MercuryConsole pause"
To unpause Mercury core: "MercuryConsole unpause"
To pause a module, for instance MercuryS: "MercuryConsole pauseS"
To unpause MercuryS: "MercuryConsole unpauseS"
Depending on version of Mercury and Windows, if the command daemon is used, and if running in program mode or service mode, behavior will differ some. Please try it out in your environment so you know how it will work before using it in any automated routine.
The command daemon can only accept one connection at the time, so if you use it you can't run the web version and the commandline version at the same time.
To have the console window stay open until you press return (so you can read program output) add "debug" as a second parameter:
this is a good one. I totally hate spam and many of my friends are angry with me because they received emails from my email address and I don't know about you, but the subject headings are now done intelligently so it bypass my spam software. Hope they changes some of the Spamhalter's features to accommodate these spamming.
A job can have only one sender but multiple recipients, so there is separate data for each recipient within the job.
You should at least be able to get the From field without enumerating anything, though, otherwise there is some other problem with the code. Try checking the result of ji_get_job_info to make sure you actually get something in the JobInfo record.
[quote user="dms"] Is there a way to file a bug against the DDK sample? Mercury DDK\DDK Samples\Resident Daemon\daemon2.c contains the error.[/quote]
I've notified David of this issue - there is no public bug-track - thanks for your efforts.
I just experienced this same problem. The sample daemon2.c as distributed in the DDK still contains the error last discussed in November of 2008. Were it not for this forum chain I would have been unable to get the sample to run.
I realized that Mercury is winding down but it sure would be nice if there was a single place to find known problems and any solutions or work arounds. I'm surprised that there is no bug reporting and tracking mechanism but I guess at this stage of the product life cycle it is too late to expect change.