Preview: v2.8.0

  • Die DNS-Blacklist greift bereits beim Connect an den Postfix; theoretisch kennt er zu dem Zeitpunkt noch nicht einmal den Empfänger.


    Es gibt zwei Möglichkeiten:

    • die DNS-Blacklist im LiveConfig deaktivieren; SpamAssassin selbst nutzt auch DNS-Blacklists - ggf. muss man hierfür die Punktzahlen aber etwas anpassen.
    • eine DNS-Whitelist nutzen (die hat Vorrang gegenüber den DNS-Blacklists), z.B. dnswl.org (die ist aber kostenpflichtig, die freie Nutzung ist daher gerade aus großen Colo-Netzen heraus nicht direkt möglich)
  • In der Regel werden die Blacklists ja als erste Hürde genutzt um schon einmal ein Teil der Last vom Spamfilter wegzubekommen. Wie Herr Keppler in dem verlinkten Beitrag schon schrieb findet der RBL Check ja statt bevor überhaupt Maildaten ankommen. Im Prinzip wird ja nur die IP Adresse des einliefernden Server geprüft und darauf basieren entschieden ob abgelehnt wird oder nicht.
    Alternatve ist halt die RBL Listen nicht zu nutzen bzw. nur über Spamassassin zu Bewertung zu benutzen.

  • Naja, zu unserem Vorschlag wäre der 2. ja, dass man eine Checkbox bei DNSBL hat, dass die DNSBL Adressen im Spamassasign geprüft werden, welche man einträgt statt direkt, dann würde die Whitelist davor laufen. Aber der erste Vorschlag. s.o. von Hr. Keppler mit dem Zusatzeintrag in Postfix ist besser, finde ich... Frage ist nur die Umsetzung...


    3. Option, evtl geht as auch, man kann doch die Postfix main auch auslagern bzw. Zusatzeinträge darin vornehmen. Was ist, wenn wir im LC DNSBL dekativieren, in der main conf von Postix die ausgelagerte Datei die LC einliest mit DNSBL befüllen, greift dann die Whitelist?

  • Ich verstehe die Frage(n) nicht wirklich.


    Die DNS-Blacklist im Postfix greift (wie schon von bfal beschrieben) unabhängig von allen Empfängeradressen. Postfix schaut ob die IP-Adresse des einliefernden Mailservers geblacklistet ist und lehnt die Verbindung dann (aus guten Gründen) möglichst früh ab.


    "Auslagern von Postfix" usw. verstehe ich nicht - es ist aber immer problematisch, wenn eine Mail erst mal angenommen und dann erst später abgelehnt wird (erzeugt Bounces -> neues Problem...).


    Wie Sie das auf Ihrem Server umsetzen ist also Ihre Sache. Im einfachsten Fall deaktivieren die DNS-Blacklists im LiveConfig und konfigurieren die Blacklist-Bepunktung durch SpamAssassin etwas höher.

  • Die Preview von v2.8.0 wurde eben auf r5493 aktualisiert.
    Fast alle Fehler im Zusammenhang mit der neuen SSL-Verwaltung sind damit behoben, auch die automatische Verlängerung von Zertifikaten läuft damit wieder.


    Das nächste Update ist für kommenden Dienstag (02.07.) geplant - da fokussieren wir uns auf die noch ausstehenden Änderungen in der Oberfläche.


    Viele Grüße


    -Klaus Keppler

  • Eigener DNSBL WhitelistServer wäre ja schwachsin dafür, das wäre so die einzige Idee von uns, wie man das umgehen könnte, da Whitelist DNSBL ja den normalen DNSBL deaktiviert, was eigentlich eine Whitelist auch tun sollte. => rbldnsd <=


    rbldnsd ist die sinnvollste Lösung, falls die dnswl.org nicht nutzbar wäre.


    Nutzer-spezifische Domain-Whitelists können, wie schon mehrfach geschrieben wurde, zum Zeitpunkt der Blacklist(!)-Prüfung nicht realisiert werden.

  • Hi, ja ist möglich, aber Whitelist = Whitelist, sprich, es muss durchkommen, was in ihr drin steht. Sonst wäre es ja keine Whitelist.
    Kann man denn in spamassasing eigene DNSBL Server eintragen, damit man die in lc deaktiveiren kann, damit die Whitelist im LC funzt?

  • Wie ist der aktuelle Stand? Der Termin für die versprochene nächste Preview ist ja nun doch schon ein paar Tage her (Das nächste Preview-Release ist für kommenden Dienstag, 02.07.2019 geplant.).
    Welche "Showstopper" sind noch offen?

  • So verstehe ich das.


    "Backup-Service (lcbackup) noch nicht in GUI integriert
    Das nächste Preview-Release ist für kommenden Donnerstag, 11.07.2019 geplant."


    Wenn sich stable wegen Backup und ein paar "Kleinigkeiten" in GUI verzögert bitte ich um Release gefolgt von baldigem Update.

    # Das Gras wächst nicht schneller wenn man daran zieht # Bitte keine inflationären Vollzitate #

  • Wenn sich stable wegen Backup und ein paar "Kleinigkeiten" in GUI verzögert bitte ich um Release gefolgt von baldigem Update.


    Wir haben aktuell das Problem, dass ein Kunde (wohl unbeabsichtigt) eine sehr frühe Preview-Version produktiv eingespielt hat und dem nun tausende Let's-Encrypt-Zertifikate um die Ohren geflogen sind.
    (eine gefährliche Mischung aus "selber in die Datenbank eingegriffen" und "nö, ich sehe im Log nichts auffälliges").
    (der Eingriff in die Datenbank hatte >50.000 SSL-Aufträge generiert, der Account ist in's Rate-Limit gerasselt, und wir arbeiten mit dem Kunden derzeit an einer Lösung)


    Ja, das war ganz klar die Schuld des betroffenen Kunden, aber wir möchten den nunmal auch nicht im Regen stehen lassen. Zudem "nutzen" wir diese recht extremen SSL-Probleme nun dafür, LiveConfig in solchen Fällen etwas robuster zu machen (Beispiel: wenn DNS-TTL auf 1sec steht, wiederholt LiveConfig tatsächlich alle 1sec den DNS-Check vor einem SSL-Auftrag - das wurde nun aus konkretem Anlass auf eine Mindestwartezeit von 5min geändert).


    Lange Rede, kurzer Sinn: wir feilen aktuell noch am letzten SSL-Dialog (SSL für bestehende Subdomains aktivieren), dann gibt's ein Update der Preview welches wir dann auf "unseren" ersten Produktivservern einspielen um in den Praxistest zu gehen. Backup-Integration läuft parallel dazu weiter, ist aber kein Showstopper mehr.

Jetzt mitmachen!

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