"Recycle" Spam
Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
URL: https://www.logsat.com/spamfilter/forums/forum_posts.asp?TID=6542
Printed Date: 28 December 2024 at 3:51am
Topic: "Recycle" Spam
Posted By: jerbo128
Subject: "Recycle" Spam
Date Posted: 21 August 2008 at 8:49pm
|
Roberto and crew-
(beating dead dog again)
Any move towards or ideas for a method to send missed spam back to SFE to "recycle" it?
 Jeremy
|
Replies:
Posted By: StevenJohns
Date Posted: 29 August 2008 at 5:26am
|
I have to agree....
Although SF is good, it does still let some spam through, we NEED a method of telling SF that a certain email is spam and that it should then block the IP and register the hash with eth SFDB.
Roberto, what do you suggest we do with spam emails that get through??
------------- www.internetmailservices.co.uk |
Posted By: WebGuyz
Date Posted: 29 August 2008 at 11:07am
Good idea now that everything else is working smoothly.  ------------- http://www.webguyz.net |
Posted By: LogSat
Date Posted: 02 September 2008 at 6:01pm
|
We've always been resilient about allowing users to submit spam emails back to SpamFilter. This is because the process is too prone for errors. Users may not be able to forward back the *original* message, as for example Microsoft Outlook clients will completely change the email and preventing access to the real, original source (there is a plugin to do this... but doubtful the average user will have it).
To be successful, SpamFilter would have to keep a copy of *all* incoming email's headers, not just spam, so that they can later be referenced via some kind of unique ID to allow post-back. The benefit of this however is going to be limited due to the way the SFDB works. Our SFDB is updated in real-time by all SpamFilter's throughout the world, and we require multiple spam reports from each SpamFilter installation, within a short time-frame, before accepting an IP for possible inclusion in the SFDB from that specific installation. In addition, only if several different SpamFilter then in turn report the same IP, will finally the IP become blacklisted. This makes the process extremely reliable, and false positives are extremely, extremely rare, while at the same time allowing for semi-real-time reporting. Having individual users report spam will not help much, as each "human" report will be a drop of water in a lake as far as contributing in reporting an IP to the SFDB. Furthermore... the submission mechanism for the SFDB is kept automated, with encrypted submissions as to reduce the risk of "poisoning" the database with invalid and/or incorrect data. If we allowed an option to provide users with the ability to manually submit data to it, we would increase the danger of spammers abusing this method to upload invalid data to the SFDB, thus reducing its effectiveness. ------------- Roberto Franceschetti http://www.logsat.com" rel="nofollow - LogSat Software http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP |
Posted By: StevenJohns
Date Posted: 02 September 2008 at 6:16pm
|
Roberto,
I see what you are saying and I fully understand your wish to keep the SFDB atuomated and secure.
However, your response does seem to focussed only on blocking the IP of the sending server, rather than the email in question. We get a lot of emails which come form legitimate IP's where the content of the email if obviously spam. This kind of email should not be considered purely based on the ip that sent the email as it may have come from a server which hosts hundreds of domains.
Spammers are getting really educated about the ip's of their servers and we are seeing SF miss emails with obvious spam content.
I think you should be concentrating more on the content of the email rather than on the IP that it came from as your response seems to suggest.
A method of sending the spam email back to our own SF installation and retraining the basyan filters or the keyword filters would be a great idea.
If SF continues to focus soley on the IP of the sending server, then I can see it's effectiveness reducing over time, and that would be a real shame.
Steve.
------------- www.internetmailservices.co.uk |
Posted By: jerbo128
Date Posted: 02 September 2008 at 9:04pm
|
I agree with Steve's idea that we should not look solely at the IP and would like to add:
I am not envisioning a system that will necessarily report to others, but just a way for my SFE installations to re-train themselves. Any way for my users to report these emails in an automated way would be a plus over the manual sifting that we have to do now.
It seems that these "missed" emails come in waves, often scattered over a several hour period. If the earliest recipients of these messsages can make a difference for the rest of the users who have not yet received them - that would be a huge benefit.
|
Posted By: LogSat
Date Posted: 03 September 2008 at 5:09pm
|
The SFDC filter that we introduced a few months ago does act on the emails content, rather than the IP as in the SFDB. With the SFDC, SpamFilter analyzes the body of the emails reported as spam, and creates a hash signature to identify emails with very *similar* content. This has is then uploaded in real-time to our SFDC server. From then on, things will work very similarly to the SFDB filter. Once we receive a number of different reports for the same hash, that hash (instead of the IP) will be blacklisted, and all incoming emails with similar hashes will be rejected.
This method is not nearly as effective as the SFDB filter (on average the SFDC filter will stop only 2%-4% as many emails as the SFDB, but if you receive about 100,000 emails/day, that still means 2,000-4,000 emails stopped by that filter. As I mentioned before, it is very risky to stop emails at an enterprise level based on feedback sent from the end-users. We do however always listen to comments and requests, and this has been one of our oldest, still unsatisfied request. If we're able to come up with a way that will allow users to provide feedback for spam, and at the same time minimizing the risk of stopping valid emails being addressed to an enterprise, we'll definitely implement it. ------------- Roberto Franceschetti http://www.logsat.com" rel="nofollow - LogSat Software http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP |