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

SUppose a user reports spam to 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?

 

What tests does the bayesian filter learn from ?

Could i simply forward a spam back through SF that i edit to intentionaly fail a test. If this could be a workaround, what test would be best to cause the bayesian filter to learn it and would not result in my IP etc being banned ?

Regards

Dave

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.

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

ok, no problem....exactly where would this registered area login page be??? I can't find it.

got it..cheers

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

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

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

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

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

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.

 

Marco,

Thanks for your explanation, you are right on the money. We actually slightly increased the lower limit on the SFDB lookups on our database server itself. This means that our SFDB lookups won't provide a positive match unless there are at least nnn other reports. I'd like to keep the number private so that lurker spammers don't see it. If you wish to know just PM/email us, we'll provide the value.

StevenJohns, if Tesco was listed in the SFDB, it's because a rather large number of recipients have complained. And while I have no proof, I'm guessing it's quite larger than 100... Please note that there have to be a certain number of *different* providers/companies running SpamFilter that have received emails from Tesco, not just one company. For example, if 100 users at LogSat.com complained that it was spam, the report would be only one, from logsat.com. However, the 100 users from LogSat.com would report the spam to MAPS RBL services, like sorbs or spamcop. In this case, if these service blacklist Tesco, and multiple SpamFilter administrators use these RBLs, then yes, each SpamFilter installation would send a report. In this case, the SFDB would then contain the same information as the RBL. If users believe this is wrong, or do not wish to use the SFDB for IPs that were blacklisted due to RBLs, the SFDB lookups can be configured to not use RBL (or any other filter you wish).

As I mentioned earlier, you can always login the registered user area of the website, and perform detailed lookups on the SFDB database to see more details on what is being blocked and for what reason.

Let me explain the "100 complaints".

Consider the following example:

SpamFilter is shipped with default RBL servers. One of them is spamcop's bl.spamcop.net. Tesco sends 10,000 emails, and 100 customers complain and report Tesco to spamcop. Spamcop will then blacklist Tesco in its blacklist. Hundreds of SpamFilter administrators are using spamcop, so when they receive an email form Tesco, they will report it as spam to the SFDB. If more than "nn" different SpamFilter's report that IP to the SFDB, then the SFDB will list the IP.

Please note that Tesco would have to send emails to users who's provider runs SpamFilter (and is using spamcop), in order for SpamFilter to report the IP.

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 *@tesco.com for *@mydomain.com ?? if so, how??

 

Cheers