I know that this has been brought up before - I am not trying to beat a dead dog...

I have some users that despite how "tight" I make the filter, they continue to receive spam that the filter has missed.

I would really like to see a feature where I (as an administrator) can submit spam that was not caught by the server.  Right now, our users have been trained to copy email headers and forward messages to mailto:spam@domain.com - spam@domain.com .  We then go through those emails and manually blacklist ips, and add keywords to our list.  No only is this VERY time consuming, but it is not very effective in the big picture.

If anyone else has ideas - I would like to hear from you.

Jerbo128

While wishing for features I'll bring up the dead horse I keep flogging

It would be great to have a spamassassin plugin (similar to anti-virus plugin) Currently I'm using Mdaemon (only for Spamassassin, all other filtering disabled)  behind my SFI and it catches that last little bit that manages to get by SF and keeps me from having to learn regex

I currently have it set up to test for the Autowhitelist flag recently incorporated into SFI and if it exists then it bypasses spamassassin check. Of course I can't teach SF about the spam but I can at least make sure my customers never see it.

Would be nice to have it all in one. I think thats the last thing SF is missing in an otherwise fantastic product.

SUppose a user reports spam to mailto:spam@domain.com - spam@domain.com . , and your mailserver would relay mail to this specific adress back to the SPF server, which in turn would recognise the TO adress, and act on it.

In effect 'certain adresses' could be considered 'inbound' for the SPF server. This also opens the opportunity for internet users to report spam to your SPF system.

If the report is presented to the SPF system in a certain format, so that the SPF engine can use the data within to effectively issue a block on the reported spammer...

What do you think Roberto?

For that last bit of spam we wrote some tools using some email COM components. Basically we strip out any header info that SF adds and remove the last received from address and feed it through but add a single ^ to the subject line and our keyword filter is looking for that ^ and will reject the mail. The only difference between the original message and the one we resend is ^ in the Subject and of course we have to use our IP address as we can not spoof that. Jury is still out on how this effective it is but if we had an option in SF to have a directory where only known spam was placed I could easily make the message look 100% like the original stripping out anything added by SF and removing out ip from the Recieved line.

Lots of work but I really hate spam.

What I would like is to have a seperate DB where all "good" mail is archived to, exactly the same way as the quarantine DB works. Then, when a user gets an email that is spam, they forward it to mailto:spam@domain.com - spam@domain.com . When this mail arrives, we could easily figure which  origional email this is, and as we have the origional...we could retrain the bysian based on the origional email.

forgot to add.....

ANY email filtering program that cannot be retrained is not that great.

IF a spam gets past the filters, then the filters arn't working properly and they need to be retrained. ?This can only be done when a user gets spam and sends it back to the server to be retrained.

Question...Logsat...what do you suggest users do with spam emails that your program failed to detect????

Logsat,

I understand, however teo things spring to mind. Firstly, we are still receiving emails that get through all of the current filters and have no way to teach SF that these are indeed spam emails.

Secondly, can you please explain exactly how the SFDB works, as a HUGE customer (Tesco ... the largest supermarket in the UK) seems to have their mail server's IP listed in SFDB, but not in any other DB as in spamcop, spamhause, ordb etc.

Also, how can we get this IP delisted??

Cheers

SFDB went straight to the top after it's implementation. It simply is the best performing filter (dare i say it) on the web....

How it works: if a (settable) number of SF users declare a certain mail as beeing spam, ALL SF members reject the mail in question. So it's a joint effort / joint intelect type of filter. ANY spam that is not caught by SFDB filter, is because of 'your own' doing, and SFDB is fed with that.

I'm sorry, but I don't share you'r feelings......

SFDB blacklisted Tesco, the largest supermarket in the UK.....well donw...NOT !!!!!

refresh and see what i added.. then you'll undersdtand

sorry, I didnt describe it correctly, it should be;

*my* SF will block the sender since 'N' number of users declared the mail as beeing spam...

Apparantly, a number of the SF users think the tesco mails are spam, and your system believes it, since 'n' number of users say so.

Marco,

I know how it works, and I think it has at least one fatal flaw in it's design.

If 10,000 users sign up for a mailing list, then some time later, 100 of then descide that they no longer want it....invariably they don't bother to unsubscribe, they just mark it as spam.

Using this scenario, lazy/stupid/ignorant users can quite easily report an email as being spam, whereas in fact it isn't. The problem here is that if the company in question uses a single mail server IP for both the mailing list and the normal company mail (as Tesco do), then all of the normal email (Tesco use email to place orders with their suppliers, which can be for hundreds of thousands of pounds) will also be blocked.

Therefore, the failing here is that SFDB has no confirmation that the email that is being submitted is in fact spam.

I would suggest that it is very likely that the number of users declaring mail as spam is far too small.

Just my opinion...

As far as i know, your spam/mail system is 'only' one user in the SFDB chain, so, no matter how many of your internal users decalre the mailer as spammer, your system will issue the sending IP ONCE to SFDB.

So, if 'n' number of antiispamsystems say it is spam (read: ISP's/businesses), your system will adhere to that, no matter HOW OFTEN those ISP/businesses report the sending IP as spammer, it will only keep the ip alive in the SFDB.

you know the fun thing? you can bypass the SFDB alltogether, or increase the number, so that the chance of a falce positive gets smaller.

the setting "network reliability' number is the one you need to set to zero, or raise...

Excellent...didn't know what that setting was...cheers.

any suggestion on a suitable number...it defaults to 3.....maybe a bit low

Had mine set to 3 but then a Hotmail server started getting rejected by SFDB so I bumped mine up to 6. Seems to be pretty good and haven't seen any more major ISP servers stopped.

yeah, 3 might be a bit too low for your organisation, try 10 and see what happens, if your false positives go away,  work your way down by one a day/week untill they return. The lower the number the more 'aggressive' the filter works, the higher the number, the lesser affective it becomes.

You need to find out what works best for you by trial and error.

p.s. you can allways whitelist this tesco domain, if you think it ok all your internal users can receive their mails.

Roberto,

Now I'm confused...

An earlier post suggested that the "Network Reliability" number was the minimum number of "spam complaints" that an IP had to have before SF DB would block the IP. Then, (as the default is 3), Webguyz suggested 6, Marco suggested 10 as being a suitable number, but you are suggesting that the tesco IP might have more than 100 "complaints".

Please can you have a look at your database and give me some examples of how many "complaints" some IP's typically get. I understand that you may not wish prying spammers to know this, so feel free to PM it to me. This will give me a good idea as to what a realistic number should be.

Cheers

• Your network reliability level is set to 3
• my domain, which uses the SFDB, blocks 20 messages from 123.123.123.123.  my domain submits 123.123.123.123 to the SFDB, and the SFDB accepts 1 and only 1 submission for 123.123.123.123 from me.
  
• Joe's domain, also on the SFDB, blocks 5 messages from 123.123.123.123; that becomes the 2nd submission for 123.123.123.123 on the SFDB.
  
• Bob's domain, also on the SFDB, blocks 5 message from 123.123.123.123 as well;that becomes the 2nd submission for 123.123.123.123 on the SFDB.
• You are receiving a message from 123.123.123.123.  Your SpamFilter setup is trying to determine if it should accept the connection.  When you query the SFDB, it says 123.123.123.123 has been blocked 3 times.  Since this is greater than or equal to your network reliability limit, you block the message from 123.123.123.123.

Roberto, got the PM..thanks.

sgeorge, thanks for the explanation.

I think that I need to whitelist the tesco domain for certain local domains. I know that I can whitelist certain sender email addresses for specific recipients, but can I whitelist mailto:*@tesco.com - *@tesco.com for mailto:*@mydomain.com - *@mydomain.com ?? if so, how??

Cheers

excellent....sorted.

Thanks everyone for clearing this up.

so what is good level to start using the SFDB option?

we currently don't have it enabled but I'm certainly interested in trying it.

3 sounds dodgy from this thread.

10 or more?

and presumeably people are choosing the options which to check on like keywords, bayesian, invalid sender etc.