Spamproblematik in den Griff bekommen

    Die Spam-Lösung müsst ihr euren Servern selber beibringen. Wenn ihr euch auf halbgar vorgekaute Fertiglösungen verlassen wollt, braucht ihr auch eine neue Personallösung um die Spam-Lösung verstehen zu können.



    Disclaimer: Mir ist klar das es User gibt die nur eine handvoll viele Server betreiben und sich deswegen nicht genauer mit ihren Systemen beschäftigen wollen (können). Ich sehe nur nicht den Sinn für eine Kleinstmenge an Kunden derartige Lösungen bauen zu müssen (die oft ohnehin individualisiert werden müssen). Ich _schätze_ das der Großteil der Kunden von KK o.g. Lösungen selber fahren können. Vielleicht habe ich aber auch total unrecht..
    Ich hoffe einfach mal das an den Features intern sinnvoll nach Prioritäten gearbeitet wird.

    Ja ich könnte mir auch alles selber hinbiegen, ich möchte aber das das zukünftige Updates überlebt ohne das ich selber ständig wieder eingreifen muss. (solche Kinkerlitzchen nennt man effektives Arbeiten) . Meine Arbeitszeit ist dafür einfach zu teuer insbesondere wenn man bedenkt das ich mit dem Hosting nicht mein Hauptgeschäft bestreite.


    Zitat

    . Ich sehe nur nicht den Sinn für eine Kleinstmenge an Kunden derartige Lösungen bauen zu müssen (die oft ohnehin individualisiert werden müssen).


    Kleinstmenge an Kunden? Das grösste Problem an Emails ist nunmal die Spamgeschichte wenn es das nicht gäbe wäre Email nicht mehr als Textfiles hin und herschicken(ausser bei größeren Setups). Und im Moment wird Spam überhaupt nicht behandelt.(Nein Greylisting ist und bleibt ein Witz).


    Selbst Confixx hatte das vor ~8 Jahren schon drauf. Und wie gesagt in der Featurebeschreibung steht es schon seit Ewigkeiten.

    Zitat von Mogwais

    Selbst Confixx hatte das vor ~8 Jahren schon drauf. Und wie gesagt in der Featurebeschreibung steht es schon seit Ewigkeiten.


    Confixx kann Out of the Box kein "Greylisting" und wird es auch nie mehr können.
    Dass man es in Postfix einbinden kann bzw. die GUI (2004 von mir ...) modifiziert wurde, ändert nichts daran, dass LC hier weiter ist.


    Es wäre nur schön, wenn man die main.cf ergänzen/ändern könnte, ohne dass die Änderungen bei Updates wieder gelöscht werden. Plesk ist da leider auch nicht weiter.

    Zitat von antondollmaier

    Confixx kann Out of the Box kein "Greylisting" und wird es auch nie mehr können.
    Dass man es in Postfix einbinden kann bzw. die GUI (2004 von mir ...) modifiziert wurde, ändert nichts daran, dass LC hier weiter ist.


    Ja aber mir gings um Spamassasin und Sortierung, Greylisting halte ich mittlerweile für vollkommen wertlos. ;)



    P.S
    Confixx war auch nicht der heilige Gral, es hatte viele Macken. Aber das wenige was ging lief halt anstandslos.
    P.S.S
    Deine Hilfestellungen im Ipx Forum waren damals immer sehr nützlich ;)

    Entschuldigt bitte die Wartezeit, dafür erkläre ich das nun auch gleich etwas ausführlicher. :cool:


    Grundsätzlich kann man aktuell z.B. SpamAssassin per Milter oder über die master.cf in Postfix einbinden - Mails werden somit analysiert und bewertet; eine eventuelle Sortierung/Filterung muss dann aber im Mailprogramm (oder über ebenfalls selbst konfigurierte Sieve-Regeln) stattfinden.


    Aktuell stellen wir die SpamAssassin-Integration per LiveConfig fertig. Dabei gab es eine ganze Menge Herausforderungen, die schwer unter einen Hut zu bekommen sind:

    • die Spam-Filterung soll pro E-Mail-Adresse konfigurierbar sein (also die Schwellwerte zur Markierung bzw. Ablehnung einer Mail)
    • die Spam-Filterung soll sowohl mit "echten" Postfächern als auch mit reinen Weiterleitungen funktionieren. Bei Weiterleitungen müssen die Einstellungen der ursprünglichen Mailadresse genutzt werden (nicht die der eventuellen Ziel-Postfächer)
    • die Ablehnung einer Spam-Mail muss zum SMTP-Zeitpunkt der Einlieferung erfolgen, um keinen Backscatter zu erzeugen und die Mail-Ablehnung auch rechtssicher zu gestalten
    • Blacklist/Whitelist pro E-Mail-Adresse


    Das Hauptproblem besteht darin, eine Mail während der Einlieferung aufgrund einer Spam-Bewertung abzulehnen. Wird eine Mail eingeliefert, dann kann diese an mehrere Empfänger gleichzeitig gehen (z.B. kann eine Mail gleichzeitig an anton@kunde.de und berta@beispiel.de zugestellt werden). Nun kann es sein, dass Anton und Berta unterschiedliche Spam-Einstellungen haben und auch bei verschiedenen LiveConfig-Kunden eingerichtet sind - im Extremfall würde Anton vielleicht keine Spam-Filterung aktiviert haben und Berta per Blacklist fast jede Mail ablehnen lassen.
    Die Analyse der Mail kann erst nach deren vollständiger Übertragung (also zum Ende des DATA-Befehls hin) erfolgen. Zu diesem Zeitpunkt kann der Mailserver aber nur die gesamte E-Mail ablehnen (einzelne Empfänger können nur zum RCPT-Zeitpunkt abgelehnt werden, da ist der Mail-Inhalt aber noch unbekannt).


    Es gibt also rein technisch bedingt keine perfekte Lösung für dieses Problem, man muss sich auf einen Kompromiss einlassen:

    • entweder lehnt man zum SMTP-Zeitpunkt gar keine Mails ab (damit keine Bounces erzeugt werden dürfen Spam-Mails dann auch nur stillschweigend in einen Spam-Ordner verschoben werden; klappt nicht mit reinen Mail-Weiterleitungen),
    • oder man berücksichtigt bei mehreren Empfängern nur die Spam-Einstellungen des ersten Empfängers (also auch nur dessen Whitelist/Blacklist usw.)


    Unserer Erfahrung nach ist die Zustellung einer Mail an mehrere Empfänger auf einem Zielserver relativ selten (Ausnahme: "lokal" gesendete Mails, z.B. Rundschreiben/CC innerhalb einer Empfängerdomain; lokal eingelieferte Mails lassen sich aber am SASL-Header erkennen und können von einer Spam-Filterung ausgenommen werden).
    Gleichzeitig ist die erste Variante ("Spam-Ordner") in der Praxis etwas problematisch, da die Postfachnutzer nichts davon mitbekommen, dass eine Mail im Spam-Ordner liegt; wer Mails per POP3 abruft bekommt das überhaupt nicht mit. Man könnte dann zwar z.B. einen wöchentlichen Spam-Report verschicken, die meisten Nutzer erwarten aber dass Mails "sofort" zugestellt werden (sowohl als Absender als auch Empfänger).


    Unsere Lösung besteht nun darin, dass wir einen eigenen Milter-Service implementieren (liveconfig-milter). Ein Milter-Dienst ist bei Postfix rein technisch die einzige Möglichkeit, Mails nach dem DATA-Event abzugreifen und dann ggf. noch abzulehnen. Zudem kümmert sich dieses Tool um die Weiterleitung einer Mail durch SpamAssassin (via spamd) und sendet dabei den Ort der benutzerspezifischen SpamAssassin-Konfiguration mit - das ist etwas, was kein anderer uns bekannter Milter-Dienst beherrscht.
    Der Code ist (wie immer bei uns ;-)) in C geschrieben damit alles schön performant & ressourcenschonend läuft und wird nach Fertigstellung unter einer Open-Source-Lizenz freigegeben.


    Ich hoffe, damit für etwas mehr Verständnis bei der Mail-Konfiguration gesorgt zu haben. Für einen zuverlässigen, stabilen und rechtssicheren Mailserverbetrieb gehört eben etwas mehr dazu als eine Quick&Dirty-Integration vom SpamAssassin.


    Und weil ich gerade dabei bin: wir haben noch ein anderes Tool entwickelt, mit dem Logfiles (u.a. auch das Postfix-Log) ausgewertet werden können, um Statistiken über den Versand und Empfang von E-Mails pro E-Mail-Adresse erzeugen zu können. Dieses Tool (lclogparse) ist inzwischen fertig und läuft bei uns seit rund drei Wochen auf einem produktiven Mailserver völlig problemlos. Hier fehlt nun "nur" noch das Auslesen der aggregierten Statistikdaten und die Anzeige im LiveConfig; das alles kommt mit in die nächste Version (v1.7.2).


    Viele Grüße


    -Klaus Keppler

    Zitat von kk

    Und weil ich gerade dabei bin: wir haben noch ein anderes Tool entwickelt, mit dem Logfiles (u.a. auch das Postfix-Log) ausgewertet werden können, um Statistiken über den Versand und Empfang von E-Mails pro E-Mail-Adresse erzeugen zu können.


    Mit Anzeige, wann eine Mail warum angenommen oder abgelehnt wurde?


    Dann hat LC gerade ">6 Mannjahre" Arbeitszeit, die ein Berliner Unternehmen in die Entwicklung eines Mail-Nachfolge-Tools gesteckt hat, im (für mich/uns) relevanten Teil ersetzt.

    Zitat von antondollmaier

    Mit Anzeige, wann eine Mail warum angenommen oder abgelehnt wurde?


    Nein, so etwas steht bislang selbst bei uns nur auf der Wunschliste.
    Das Tool wäre prinzipiell dazu in der Lage, da es alle Mail-Sessions verfolgt. Es wären da aber noch viele Detail-Fragen offen (Information-Leakage wenn eine Mail an verschiedene Empfänger geht; Performance bei großen Mail-Mengen (Speicherung der Detailsdaten in der DB? Wenn ja, wie lange? RRD? Datenschutz? usw...).


    Spontane Idee: optional könnte man auf dem Mailserver eine MySQL-DB aufsetzen, an die das Log-Tool dann alle Auswertungen meldet; via LC-GUI könnten dann Auswertungen auf diese DB gefahren werden. Hätte (meiner Meinung nach) die geringsten Auswirkungen auf die Performance und würde vielfältigste Möglichkeiten bieten. :)

    Zitat von kk


    Und weil ich gerade dabei bin: wir haben noch ein anderes Tool entwickelt, mit dem Logfiles (u.a. auch das Postfix-Log) ausgewertet werden können, um Statistiken über den Versand und Empfang von E-Mails pro E-Mail-Adresse erzeugen zu können. Dieses Tool (lclogparse) ist inzwischen fertig und läuft bei uns seit rund drei Wochen auf einem produktiven Mailserver völlig problemlos. Hier fehlt nun "nur" noch das Auslesen der aggregierten Statistikdaten und die Anzeige im LiveConfig; das alles kommt mit in die nächste Version (v1.7.2).


    Hallo, vielen Danke für die Stellungnahme.
    Nur fürs Verständniss: lclogparse wird in der 1.7.2 wohl integriert werden. Die SpamAssassin-Integration wird noch länger dauern. Habe ich das so richtig verstanden ?

    Spamassassin ist ja mittlerweile integriert. Ist in diesem Zusammenhang auch noch mit der unten genannten Umsetzung einer Whitelist/Blacklist pro E_Mail Adresse zu rechnen?


    Zitat von kk


    Aktuell stellen wir die SpamAssassin-Integration per LiveConfig fertig. Dabei gab es eine ganze Menge Herausforderungen, die schwer unter einen Hut zu bekommen sind:

    • die Spam-Filterung soll pro E-Mail-Adresse konfigurierbar sein (also die Schwellwerte zur Markierung bzw. Ablehnung einer Mail)
    • die Spam-Filterung soll sowohl mit "echten" Postfächern als auch mit reinen Weiterleitungen funktionieren. Bei Weiterleitungen müssen die Einstellungen der ursprünglichen Mailadresse genutzt werden (nicht die der eventuellen Ziel-Postfächer)
    • die Ablehnung einer Spam-Mail muss zum SMTP-Zeitpunkt der Einlieferung erfolgen, um keinen Backscatter zu erzeugen und die Mail-Ablehnung auch rechtssicher zu gestalten
    • Blacklist/Whitelist pro E-Mail-Adresse

    Die Lösung mit Spamassassin unter Liveconfig (solange man mit einer Globalen statt Konto bezogenen Konfiguration arbeiten möchte) funtkioniert wunderbar. Man sollte sich nur etwas in Spamassassin und dessen Konfigurationsmöglichkeiten etwas einarbeiten.
    Bei uns kommt soweit kein Spam durch und es entstehen auch keine merklichen False/Positive Probleme, die Kunden sind zufrieden.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden