[SAde] Re: [SAde] Vorschläge her :)

On 22 Oct 2003 at 22:41, Malte S. Stretz wrote:

> (...)
> Wie es der Zufall so will, bin ich gerade dabei, eine neue Conf.pm-API 
> und evtl. auch Dateiformat zu entwerfen. Dabei bin ich latürnich für alle 
> Anregungen wie man's bezogen auf Internationalisierung besser machen kann, 
> offen.

Was für ein netter Zufall. :)

> Ernesto's Erweiterung mit rulesets habe ich schon im Hinterkopf, bin mir
> jedoch noch nicht ganz sicher wie's am besten zu implementieren ist.
> Ebenfalls ist eine 'include' Direktive vorgesehen.

Das finde ich gar nicht mal so notwendig, die Idee von automatischen 
einbinden aller *.cf Dateien eines Verzeichnis ist ja auch relativ
straightforward.  Nur, dass man mit includes da die Reihenfolge des
Ladens einfacher bestimmen kann (anstatt die Dateien durchzunummerieren).

> Da die bisherige Konfiguration schon ziemlich unübersichtlich geworden ist, 
> tendiere ich zur Zeit zu einem neuen, hierarchischen Dateiformat, ähnlich 
> dem das die ISC Software (z.B. bind) verwendet. Das würde dann 
> beispielsweise so aussehen:

Das Format finde ich gut und geeignet.

> # Allgemeine Optionen
> options "default" {
>   rewrite-subject on;
> 
>   # Is eh default, könnte also weggelassen werden.
>   accept-sets all;        # default: accept-sets: all
>   # Aber zusätzlich noch die CVS-Regeln aktivieren...
>   accept-sets "testing";
>   # Zusätzlich "broken" rules ignorieren.
>   deny-sets "broken";     # default: deny-sets "testing" "ancient"
> 
>   # Zusätzlich deutsche und brasilianische Regeln einbidnen, aber
>   # nicht die chinesischen.
>   accept-langs "de"       # default: accept-langs "en";
>                "br";
> }

"accept" und "deny" sind da ein wenig verwirrend, weil man damit
anscheinend Regelsätze aktiviert oder deaktiviert, oder? Würde das
gleich "enable-ruleset" und "disable-ruleset" nennen.

> # Gilt nur für spamd
> options "daemon" {
>   version-tag "i-am-a-daemon";
>   add-header "Foo" {
>     value "Bar $(DATE)";
>   }
> 
>   # Der Daemon soll doch keine "testing" Regeln verarbeiten...
>   deny-sets "testing";
> 
>   # etc.
> }

Ja. Gut ist dabei, dass man in den speziellen Fällen Sachen Overriden
kann, z.B. Regelsätze aktivieren/deaktivieren.  Super wäre es, wenn 
man das auch in der User-Config machen kann, also, dass man in den
globalen Einstellungen sagen kann welche Regelsätze gelten und welche
Verfügbar sind, und der Benutzer kann dann noch weitere aktivieren oder
auch welche deaktivieren. Das ist so gemeint oder?

Das Problem damit sind natürlich die Scores!! Wie werden diese dann
berechnet, das hat "Nix" in der devel-liste ja schon kommentiert, wenn
man da unterschiedliche Regelsätze an und ausschalten kann, wie soll
man dann genetisch die Scores erzeugen?

> # Die Regeln
> rules "default" {
>   # lang "en" wird implizit angenommen!
>   rule "FOO" {
>     type header;
>     match "To";
>     pattern /friend@public\.com/;
>   }
> }

Was für eine "lang" soll man dann Regeln geben, die nicht
Sprachspezifisch sind (wie die meisten URI oder einige RAWBODY Regeln)?
Würde die Sprache eventuell zu jeder Regel einzeln packen, z.B.:

rule FM_DE_ABNEHMEN {
  type body;
  pattern /\bAbnehmen\s+ohne\s+Diät\b/i;
  lang "de";
  describe "de", "Abnehmen ohne Diät";
  describe "en", "Loose weight without a diet";
  score 3.0;
}

Und wenn die Sprache egal ist:

rule HTTP_ESCAPED_HOST {
  type uri;
  pattern /^https?\:\/\/[^\/\s]*%[0-9a-fA-F][0-9a-fA-F]/;
  describe "en", "Uses %-escapes inside a URL's hostname";
  score 0.0, 0.0, 0.0, 0.368;
}

Eigentlich ist bei den Regeln gar nicht mehr so wichtig, welche Sprache
sie sind, wenn man die in den Rulesets schon kategorisiert hat, braucht
man dann keine weitere Unterteilung (nach Sprache), das kann man mit den
Rulesets schon erschlagen (ruleset "german" enthält halt alle deutschen
Regeln). Man kann sich ja auf bestimmte Ruleset-Namen einigen, z.B.
"lang_de", die man dann aktivieren oder deaktivieren kann. Das "lang" in
der Regel würde ich nur zur Info verwenden. Würde das gar nicht mal mit
so was wie "accept-language" koppeln, denn ich kann möglicherweise auch
Spanischen Spam bekommen, obwohl ich gar nicht Spanisch lesen will, d.h.
die eventuellen Spanischen Regeln sollen dann auch einschaltbar sein.

Wichtig ist auch, dass man später weitere "Daten" zu jeden der Elemente
hinzufügen können muss, also z.B später in anderer Datei:

rule HTTP_ESCAPED_HOST {
  describe "fr", "Utilise des séquences % dans le nom de la machine dans
                  une URL";
}

> rules "testing" {
>   # ...
> }
> rules "german" {
>   lang "de";
>   include "/usr/share/spamassassin/rules-de/*.conf";
> }

Würde das "ruleset" statt "rules" nennen, damit man das besser von
den einzelnen Regeln ("rules") trennen kann. Die Idee hier auch 
globs zuzulassen ist genial.

Also flexibel wird das ganze immerhin, wobei ich hier ein Problem sehe,
wie du das den anderen Devel beibringen wirst, damit das mit dem Scoring
(was ja ein wesentlicher wichtiger Aspekt von SA ist) auch gut klappt.
Das kann ich mir momentan bei unterschiedlichen Rulesets, die dann ja 
auch eventuell bei Runtime total unterschiedlich sein werden, gar nicht
so recht vorstellen, wie man es mit GA verheiraten kann.

Kannst du's dir schon vorstellen?

Die Ideen gehen aber schon mal in eine gute Richtung!


Gruss,
Ernesto

-- 
Ernesto Baschny <[email protected]>
 http://www.baschny.de - PGP: http://www.baschny.de/pgp.txt
 Sao Paulo/Brasil - Stuttgart/Germany
 Ernst@IRCnet - ICQ# 2955403



-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54