Hallo Nicola,
warum es mir bei den Vorschlägen ging, habe ich scheinbar noch nicht
ganz rüberbekommen. Also versuche ich es nochmal, mich verständlicher
auszudrücken.
Nicola Tiling schrieb:
> An dieser Stelle soll nur der header
> erweitert werden und das Subjekt verändert, wenn der Spam Score den
> Wert "$acl_m4" überschreitet. Das kann ich ja aber erst NACH dem check
> im vorherigen Absschnitt zu fassen bekommen.
In meinen Auszügen aus der Konfig sollte genau dies rauskommen. Erstmal
kommt ein "warn"-Block, wo das Spam-Scoring durchgeführt wird, mit einer
Bedingung, bei welchen Mails dies zu geschehen hat.
Danach kommen 1 bis x "warn"- oder "deny"-Blöcke, wo das Ergebnis
verarbeitet wird. Meine Erfahrung ist, dass ich die gleichen
Bedingungen, die ich bei Scoring-Block verwendet habe, auch bei den
Folgeblöcken verwenden muß, plus zusätzliche, um die weiteren Aktionen
zu steuern. Zum Beispiel, Header-Elemente hinzufügen. Sonst wird eine
Mail nicht mit einem Score versehen (wegen whitelist zum Beispiel), das
fehlende Ergebnis führt aber dazu, dass trotzdem die Mail mit Header
versehen wird.
>
> Ich habe jetzt einfach mal den spamcheck an der Stelle rausgenommen.
> Außerdem habe ich die "$acl_m4 > 0" zugefügt, sodass, wenn acl_m4 leer
> ist, die Bedingungen insgesamt auch nicht erfüllt sein soll
>
Ich glaube, dass "$acl_m4 > 0" noch nicht ganz ausreichend ist. Entweder
sollte man im "warn"-Block, der gegebenenfalls die Header modifizieren
soll, die kompletten "condition"-Elemente aus dem Scoring-"warn"
wiederholen, oder eine andere Kennzeichnung benutzen, die sicherstellt,
dass die Mail wirklich mit einem Scoring versehen worden ist. Meiner
Meinung reicht "{>{$spam_score_int}{0}}" nicht aus, weil dieser Wert
gegebenenfalls undefiniert ist. Konkret zum Beispiel für den zweiten Block:
> warn condition = ${if < {$message_size}{500k}{1}{0}}
> condition = ${if and { {eq{$header_X-SA-Run:}{Yes}} \
> {!eq {${lookup pgsql{WHITE_FROM}}}
> {1}} \
> {!eq {${lookup pgsql{WHITE_SUBJ}}}
> {1}} \
> } {yes}{no}}
> condition = ${if and{ {>{$spam_score_int}{0}} \
> {>{$acl_m4}{0}} \
> {>{$spam_score_int}{$acl_m4}} \
> } {1}{0}}
> message = X-Spam-Flag: YES\n\
> X-Spam_score_int: $spam_score_int\n\
> X-Spam_value: $acl_m4\n\
> X-Spam_bar: $spam_bar\n\
> X-Spam_subject: *****SPAM*****($spam_score)
> $h_subject:\n\
> X-Spam_report: $spam_report\n
Die Duplizierung der lookups ist durch das Caching der Ergebnisse
praktisch ohne nennenswerten Auswand. Innerhalb der ACLs sind mehrere
"condition"-Elemente erlaubt, sie werden "und" verknüpft (leider gilt
dies nicht für Router :-((
Alternativ setzt man im Scoring-Block eine weitere Variable mit einem
Merker (Bedeutung: "für diese Mail ist ein Scoring gelaufen") und fragt
sie dann im folgenden "warn" ab.
Ich hoffe, es ist klarer geworden, was ich meinte.
Gruß -vol
_______________________________________________
Exim-users-de mailing list
[email protected]
http://lists.exim.org/mailman/listinfo/exim-users-de
