At 9:30 AM +0100 7/14/09, sanesecurity@xxxxxxxxxxxx wrote:
Bill Landry wrote:This signature really scared me...Yep, me too. I've got a really busy schedule right now, but look for an update to the download script within the next week or so. As usual, I will announce it here...It would be nice if you could stick something like for example this in the config file: ham_folders = /home/*/Maildir/.Ham/cur/ Then the script downloads the signature files to a temporary directory, and runs "clamscan" with the "-d" option to choose the temporary directory.If you ran the script, you would see that it already does this.I've already been through your script. You scan one small test file to make sure that the signatures aren't corrupt.If any of the emails that are scanned are then flagged up as infected by one of the new signatures you could spit out a fatal warning and not apply the new sigs.Rather, I am planing to simply strip the signatures that do not meet the user's minimum character requirements and possibly place them into a temporary file for viewing and maybe even log the occurrence to the log file.That's not a very good solution. All that does is stop small domains being listed. It doesn't stop domains like facebook.com being listed. A *much* better solution would be to give the user an option to scan a folder(s) of their selection before rolling them out.No reason to cause panic by spitting out fatal warnings and bypassing the entire signature file for one errant signature.I disagree. If a user has specifically stated that no email in this folder is spam, and then a signature update starts identifying messages in that folder as spam, the user should be warned. Perhaps you could add a "ham_folder_threshold" configuration option or something so you can specify how many emails in that folder should trigger before stopping the rollout.This sort of scanning should take place before the signatures even appear in the signature file, but the "com" listing clearly proves that it isn't. Next best option, do it locally before rolling them out.This also protects against malicious updates to signature files, by their maintainer, or by an enterprising hacker.
I find your comment "malicious updates to signature files, by their maintainer," insulting.
As for your comment about checking against ham I am not sure that is as good as you think. If we checked our DB against our ham I doubt it would help a european site.
We wash all our signatures now against the uribls whitelists, local whitelists, bondedsenders, Fortune 1000, etc and we require a minimum signature length.
Since we started this we have had only one issue and that was with a new domain in use by Microsoft that hadn't yet showed up in uribls whitelists. Thus, not only was that signature in use temporarily in our DB until we locally whitelisted it but it was in all URIbls and I doubt it would have made it into your local ham.
And I can't help remind people again that certain signatures, such a jurbls, should only be used with scoring. We score and did not lose any mail because of that signature.
As for malicious changes, Steve pushes all files out signed and if you are paranoid enough to be worried about the backend you might have also mentioned that your own mailserver is at a certain level of risk as well. You could also write a rechecking routine for your local use or not use the signatures at all.
Lastly, talking about the script writers/maintainers. I think they do a great job. After all, script writers/maintainers and signature guys are all doing this for free.
So if you don't like the system you are free to use/do something else or in the spirit of the community you might offer something back.
I don't mean to say "my way or hiway" but you have previously discussed this a number of times; Bill gave his response; others chimed in; its time to stand down.
Tom PS Thanks for the contrib to the community provided in a later post.
