From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: ANN: Simple Components v4.13 released Date: Thu, 2 Jun 2016 18:16:46 -0500 Organization: JSA Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1464909385 1602 24.196.82.226 (2 Jun 2016 23:16:25 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 2 Jun 2016 23:16:25 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:30563 Date: 2016-06-02T18:16:46-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:niomun$1gna$1@gioia.aioe.org... > On 02/06/2016 02:29, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:nimjf8$4v6$1@gioia.aioe.org... >> .... >> The use of Ada makes for highly reliable and maintainable code, which is >> necessary for anti-spam efforts (the code has to be changed periodically >> to >> deal with new attacks). (And, no, sorry, the code isn't available, as it >> would make it easier for spammers to evade it in a targetted attack -- >> which >> quite possibly would turn it into an unintentional spam engine via the >> various mailing lists that it filters for.) > > If you have a machine learning algorithm in it or a hand-made set of > rules, disclosing code would show little. It is the trained system state > that does the job. Yes, that's part of it (the white and black lists obviously do a lot of the work), but there is also the issue of precisely how URLs are detected (for one example). The less known about that, the better. > Of course, learning as such is inconsistent with reliability, > maintainability etc, but that is another story. I've pretty much concluded that "learning" per-se (that is, automatically using characteristics of good and bad mail) doesn't work very well in a corporate environment, which the myriad different users have very different opinions on what is good and bad mail. For instance, I don't use certain social networks, banks, and similar services, so any mail purporting to come from them is almost certainly junk of some sort. That set is personal and different for any other user of our server (and the filter is intended to be server-wide). In any case, since most of the code is Janus/Ada and Claw-specific, it isn't necessarily going to be that useful for someone else. (I still intend to port much of it to GNAT on Linux, so it will become more useful when that's done -- but who knows when I'll get the time and energy to do it.) Randy.