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)

Just FYI:

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.

Yes I use mail merge too. This becomes easy for me to indentify emails

Free Android Games

OK, I got it ... Core config ... reporting level.

[quote user="Vincent Fatica"]
P.S., In the forum's message composer, how do you get your code to appear in a box?
[/quote]

That was just an indent actually. :)

/Rolf 

thanks Rolf, I now used this setting and indeed, the whitelist doesn't grow now when I send missed spam to the spam correction account ! Many thanks for your help ! regards, dabreaka

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. 

> Hopefully somebody has a new URL for this?

I have no new URL but I do have a copy that I can send you.  Drop me a line at the e-mail address below.

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:

exit

start

restart

online

offline

pause[module]

unpause[module]

Some examples:

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:

"MercuryConsole pause debug"

/Rolf

Thanks.

The download is here:

Rolf:

I just thought I'd drop in an give you another big "thanks" for this one, it has been working beautifully since installed.

Matt

I have no idea about C++ but what you should do is basically (from Pascal code):

- get a temp file name with mi.mercury_command(GET_TEMPFILE, @FileNameBuf, nil)

- extract the message to the temp file with mi.fm_extract_message(job, FileNameBuf, 0)

- modify file contents according to your wishes

- update the message with mi.ji_update_job_data(job, FileNameBuf)

- delete the temp file 

/Rolf 

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. 

[:O]

Wish i found that before [:D]

Thanks

Thanks for your answere!

Yes, it's a global daemon.

At this time I will test it with a file per user. If a user has no config file,

the daemon has to do nothing.

Thanks :)

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.

/Rolf 

[quote user="Peter Strömblad"]

[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.

[/quote]

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.

It could probably be achieved with a simple policy running a batch file.  Mercury is very flexible in this respect, and adding access to external processes is straightforward.

Glad to hear you're using this: I plan to keep it much more aggressively up-to-date than has been the case in the past, but don't hesitate to let me know if you find errors or need clarifications.

Cheers!

-- David --