Glad to hear that you have fixed it.

Probably the wrong forum, but I'll ask anyway.

As I am still in training mode, I am moving spam to another mailbox using a global rule.
This allows me to interrogate and correct "false positives"

I have defined a number of domains in the manual whitelist using wildcards.

Despite this (and seeing the "Do Test" say matched), a large number of mails are being flagged as 100% Spam.
So my move rule is firing on the added X-SPAMWALL header.

I am then having to forward these email to the NoSpam address.

This implies that the whitelist is not being processed - or is being referred to after the scan.
I am then having to forward these email to the NoSpam address.

 
Any suggestions ?

Do you have a rule that bypasses the spam moving rule for the whitelisted messages? I have two rules above my spam moving one:

    If message contains the whitelisted header, exit processing

    If message is sent from the admin account, exit processing

The first one skips the spam moving rule if the whitelisted header is present, and the second one makes sure that messages forwarded from the spam holding mailbox to users (i.e. false positives) don't end up back there.
 

I have also discovered that the whitelist does not work as expected. Despite adding addresses to it, it will still flag 'safe' messages as spam. Is this a bug? I do not see the point in setting up extra processing rules, adding unneccessary complexity to something that should be dealt with by the whitelist.

[quote user="Greenman"]I have also discovered that the whitelist does not work as expected. Despite adding addresses to it, it will still flag 'safe' messages as spam. Is this a bug? I do not see the point in setting up extra processing rules, adding unneccessary complexity to something that should be dealt with by the whitelist.[/quote]

I have not heard any problems with whitelisting at all...  so perhaps check the addresses added to it and compare it to the messages that do not get prevented from spam control. You most likely will find out that the addresses do not match. If they match, do get back to me (directly) with the examples.

You should have received 4 examples now.

Deleted.

I am still seeing emails whose addresses are on the Spamhalter whitelist being classified as spam. I will email one of these to you, Han v.d. Bogaerde

I am sorry to keep bringing this up, but there are still issues with this whitelist.

I have SpamHalter configured to add a tag to messages it identifies as spam. The tag was originally [SPAM]. Mercury then used a filter to pass messages tagged with [SPAM] to a 'spam' account.

After repeated 'false positive' identification of messages from addresses in the whitelist I changed the tag to [SPAM01] and edited the Mercury filter to reflect this in case the original [SPAM] tag was being applied before it reached our server. However, mail from some addresses in the whitelist is still being incorrectly tagged.

Can someone please tell me if there is anything extra which needs to be done? I copy an address in Pegasus, and in Mercury (which I access through the Remote Desktops mmc snap-in), I click Configuration>SpamHalter and then click the Whitelist tab. I paste the address in the lower pane in the dialog, adding it to the existing list, then click OK.

When I test an address I follow the same procedure, except I paste the address in the Test: field and then click 'Do Test!' and I see 'Match!'

Am I doing anything wrong?

[quote user="Greenman"]

I am sorry to keep bringing this up, but there are still issues with this whitelist.

I have SpamHalter configured to add a tag to messages it identifies as spam. The tag was originally [SPAM]. Mercury then used a filter to pass messages tagged with [SPAM] to a 'spam' account.

After repeated 'false positive' identification of messages from addresses in the whitelist I changed the tag to [SPAM01] and edited the Mercury filter to reflect this in case the original [SPAM] tag was being applied before it reached our server. However, mail from some addresses in the whitelist is still being incorrectly tagged.

Can someone please tell me if there is anything extra which needs to be done? I copy an address in Pegasus, and in Mercury (which I access through the Remote Desktops mmc snap-in), I click Configuration>SpamHalter and then click the Whitelist tab. I paste the address in the lower pane in the dialog, adding it to the existing list, then click OK.

When I test an address I follow the same procedure, except I paste the address in the Test: field and then click 'Do Test!' and I see 'Match!'

Am I doing anything wrong?

 [/quote]

I've delayed answering this to verify that my whitelist was working as specified. I've had no problem where the actual MAIL FROM: address of the message matched the whitelist email address. I have a real spammy account with my ISP that they use for delivering the actual monthy bill.  I've whitelisted this address and it works as specified.

Well, I have no idea what is going on. I'll just have to put up with it until I/someone discovers the solution to the problem.

Are you on the latest version?  Could you turn on debug mode and post a relevant section of the Spamhalter log which shows this behaviour?

Thanks for the suggestion. I'll do as you suggest.

Could you post a few lines from your whitelist, with the actual names changed it you like, or PM them to me and I will compare them to mine which works fine and see if it is different in any way.

I think the problem has been resolved. It was my mistake (again).

As well as the filtering rule which moved messages tagged with [SPAM01] to the 'spam' account, there was also a rule which examined the headers for spam - some spam emails which spamhalter had missed contained a spam indicator in the header and I had added a global rule which looked for that and moved the message. So, although the mail was whitelisted by SpamHalter, the next filtering rule would have moved the message to the spam account anyway.

Since deleting the extra rule, I have not seen any false positives.

Thanks for the help anyway.