Date: Fri, 29 Mar 2024 15:33:37 +0000 (UTC) Message-ID: <557713412.6679.1711726417381@cwiki-he-fi.apache.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6678_1803353815.1711726417381" ------=_Part_6678_1803353815.1711726417381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
(part of RulesProjectPlan)
LorenWilton: 'There is a second t= hing here that gives me even greater concern. We have discovered that rules= can be discussed openly on the users or dev list just fine, even going int= o some detail on what they do and how they work, and it will not have a not= icible effect on how well a rule catches spam.
We have also found that the instant an actual rule is posted on the user= 's list, it will lose about 80% of its effectiveness, usually within about = 16 hours. Within a week it will be virtually useless. Sometimes the rule wi= ll regain some effectiveness a few months later, and in rare cases posting = a rule will not affect the hit rate. But in general, public posting in a re= adable forum of a rule body will negate the usefulness of the rule almost i= nstantly.
One can speculate on why this happens, since the rules are there to read= on any SA system, and can be trivially downloaded from SA and SARE for cas= ual examination. Evidence shows though that this doesn't have an effect on = the effectiveness of the rules. But posting the body of the rule on a maili= ng list does. Moderately strange, but of moderate concern, also.
I have some concern that a rules project *might* open up new rules to in= effectiveness, similar to posting them in a forum. However, the difficultie= s (for the average spam tool writer, at least) in using svn may prevent thi= s from being a real problem. But it is worth devoting a few moments thought= to the possibility.'
JustinMason= : it *is* a problem, but in my opinion there's really nothing that can be d= one about this =E2=80=93 we're an open source project, and the code is visi= ble. while there's downsides, it also brings big benefits as well (as I sai= d, the alternative is working for Brightmail . Open development is a requirement of being an ASF projec= t, btw.
(To cut and paste some paragraphs from a mail I sent a few months ago...= ) I've thought about this for several years, since I work on a project that=
I still haven't made any kind of hard-and-fast cut-and-dried decision. B= ut my tendency is towards the following:
In cases where info must remain secret to secure convictions; keep it se= cret. A conviction, esp of a major spammer or ratware vendor, can make a mu= ch bigger difference to the state of antispam than anything else.
In cases where info may provide better filtering for a few months at a f= ew sites, if kept secret; I don't think it's entirely useful to keep this s= ecret. Here's a few reasons:
pressure from other sides. Hash-buster development in 2002 and 2003 is a= great example. We thought they were changing due to Razor and Pyzor, but t= hen realised a year later that it was AOL's similar systems that drove the = changes =E2=80=93 it had nothing to do with our open-source projec= ts.
2. the secret may be rediscovered elsewhere (e.g. our realisation a few = months back in Sp= amAssassin that we were matching about 5 different aspects of one ratwa= re's behaviour without connecting them);
3. forcing the ratware developer to update their software and keep chang= ing makes hard work for them, annoys their customers, and leaves the users = who are using pirate copies vulnerable anyway. Lots of spammers ar= e running pirated versions of their ratware, so cannot update if their spam= starts hitting rules that hit structural features of the message or SMTP d= elivery.
4. better openness allows people to *enter* the field of antispam forens= ics. I found a lot of interest out there, and quite a few people already lo= oking into the field quietly on their own, after presenting a talk about sp= am forensics at a hacker conference in San Diego last year. People are alre= ady doing this for fun, and for their own use, but they don't talk about it= and we ourselves are missing out a lot of the details.
5. think about #4 for a sec and you'll realise that it's another form of= open-source v closed-source thinking, and also analogous to the full-discl= osure argument in network security.
The key factor to fix this problem, we think, is to have fast, fast turn= around on rule publishing =E2=80=93 that way when the spammer mutates, if t= hey do, we can keep up. we know we need to get things turning around faster= =E2=80=93 Theo's "sa-update" script (SaUpdatePlan) is the key to this.
There are other techniques, also, but let's not talk about them here... =
doh, I'd already written about this on the wiki =E2=80=93 see also PublicRules.