Beiträge von s.pflug

Folgendes hat bei mir geholfen:
http://bugs.endian.it/view.php?id=2431

Bugs in der Community Version scheinen nicht ( kurzfristig ) gefixt zu werden :?
Das war für mich ein Grund schweren Herzens vorerst zurück zum IPCOP zu wechseln.
Nicht weil ich umbedingt mehr vom Produkt halte, sondern da ich persönlich das Gefühl habe,
dass die Community aktiver ist und Lösungen schneller gefunden werden.

Dies soll keine Bewertung dieses Forums und ihrer User sein.
Meine Kenntnisse in dem Bereich sind einfach nicht aussreichend um auf gut Glück im Bugtracker zu suchen und
die Änderungen selbst umzusetzen ( denn nicht jede Problemlösung ist dort so gut beschrieben wie diese hier).

Folgendes habe ich mir gerade zusammengeknobelt:

Vorher den Ordner /usr/share/spamassassin/ z.B. per WINSCP sichern.

sa-update -D
rm /usr/share/spamassassin/*
cp -r /var/lib/spamassassin/3.002005/* /usr/share/spamassassin/

Anschließend habe ich Endian durchgestartet und der Fehler scheint verschwunden zu sein.

Was mir komisch vorkommt:
Die neuen Definitionen bestehen aus ~10 Dateien weniger. Kann das korrekt sein ?

Scheint bekannt zu sein:
http://bugs.endian.com/view.php?id=2432

War mir früher schon einmal aufgefallen, richtig deutlich wurde es, als ich gestern neu installiert habe:
Schau ich in die SMTP Mailstatistik, habe ich z.B. bei den Spam Mails folgende Werte:

täglich: 1470
wöchentlich: 1471
monatlich: 1234
jährlich: 0
Send / Received weichen noch stärker von einander ab.
Bei allen Statistiken wird der gleiche Erstellungszeitpunkt angezeigt.
Das in der Übersicht / SMTP Proxy ganz andere Werte angezeigt werden ist dann schon fast selbstverständlich

Einerseits würde ich sagen "Hauptsache bunt", andererseits kann man den Statistiken wohl nicht für 1,50€ trauen.

Ist das wirklich fehlerhaft oder habe ich einen Fehler in meiner Denkweise ?
Ich würde schon gerne herausbekommen, ob das was vorne reingeht auch hinten raus kommt

Gruß

S.Pflug

Habe vermutlich eine Zwischenlösung in Form einer Transportregel gefunden, falls noch jemand eine einen besseren Lösungsansatz hat würde ich mich freuen.

von Benutzern außerhalb der Organisation
und wenn die X-Spam-Flag YES enthält
Dem Betreff eine [UNKNOWN] voranstellen
und X-Spam-NichtImAD mit YES festlegen
außer, wenn mindestens einer der Empfänger im Feld "An" oder "Cc" Mitglied einer AlleADEmpfänger ist

Bei AlleADEmpfänger handelt es sich um eine dynamische Verteilergruppe, die alle Mail-Adressen der Firma enthält.
Derzeit stelle ich zum Testen nur ein [UNKNOWN] vor den Betreff, in Zukunft werden sie vermutlich einfach gelöscht.
Die Kopfzeile X-Spam-NichtImAD setzte ich, um diese Mails in weiteren Transportregeln auszufiltern ( hat mit dem Lösungsansatz nichts zu tun).

HAllo,

die Hilfe verweist ja per default auf die ungültige URL http://docs.endian.com/2.3/en.

Diesen Pfad kann man in der Datei /etc/custom.conf anpassen.

Einfach

DOCS_URL='http://docs.endian.com/2.3/en'

durch

DOCS_URL='http://docs.endian.com/'

ersetzen.

Mag sein, dass dies nicht die Docs für die Community Version sind, aber besser als gar nichts

Hallo,

ich habe hier die Community v2.3 vor unserem Exchange ( Empfang per SMTP).
Ich benutze nicht die interne Spam-Quarantäne, sondern leite den Spam auf die eMail Adresse eines
Öffentlichen Ordners weiter.

Kommen "Normale eMails" ( kein Spam, kein Virus) an nicht vorhandene Adressen rein reicht Endian diese auf dem normalem Weg an den Exchange durch, der sie mit einer Unzustellbarkeitsbenachrichtigung abweist.

Erkennt Endian allerdings eine Nachricht als Spam leitet er sie ( wie konfiguriert ) an den Öffentlichen Ordner weiter.
Hierbei prüft er nicht ob die ursprüngliche Empfängeradresse tatsächlich vorhanden ist ( wie soll er auch?).
Ich habe quasi ein Spam-Catchall Postfach.

Läst sich dort eine Überprüfung auf gültige Empfangsadressen ( optimal mit LDAP/AD-Abgleich, manuell wäre aber auch ok) implementieren ?

Gruß

S. Pflug