Postfix Whitelist smtpd_client_restrictions

    Guten Morgen,


    ja, ich weiß, vieles ist eine Frage der Philosophie und eigener Vorlieben, aber grundsätzlich verstehe ich im Bereich E-Mail eine Whitelist so, als dass diese gewhitelistete Mail auch dann zugestellt werden soll, wenn sie, aus welchen Gründen auch immer, auf irgendwelchen Blacklists steht.


    Insofern stellt sich mir die Frage, warum die via 'LiveConfig -> Serververwaltung -> E-Mail -> Postfix' eingetragenen Whitelists erst in den smtpd_recipient_restrictions zum Tragen kommen, während die Blacklists bereits vorher via smtpd_client_restrictions geprüft werden.


    Macht das wirklich Sinn?

    Die Idee hinter der aktuellen Konfiguration ist wie folgt:

    • Ein Server, der auf einer Blacklist steht, wird grundsätzlich abgelehnt.
      Es ist nicht vorgesehen, einzelne Ausnahmen zu schaffen. Steht ein Server auf einer Blacklist, dann wird er auch an andere Mailserver nicht senden können - Ausnahmen verkomplizieren die Sache dann erheblich.
    • Danach greift das Greylisting.
    • Ausnahme: wenn ein Server auf einer DNS-Whitelist geführt wird, dann wird das Greylisting übersprungen. Ziel hierbei ist, unnötiges Greylisting "bekannter" Mailserver (gmail, GMX, usw.) zu verhindern.


    Aus diesem Grund kann man die DNS-Whitelist im LiveConfig auch nur dann pflegen, wenn Greylisting aktiviert ist.

    Zitat von kk

    [*]Ein Server, der auf einer Blacklist steht, wird grundsätzlich abgelehnt.
    Es ist nicht vorgesehen, einzelne Ausnahmen zu schaffen. Steht ein Server auf einer Blacklist, dann wird er auch an andere Mailserver nicht senden können - Ausnahmen verkomplizieren die Sache dann erheblich.


    Und genau hier sehe ich ... Diskussionsbedarf:


    - gerade die Mailserver der T-Online landen regelmäßig bei Spamcop auf der Liste. Ist ja auch legitim, wenn die Spam verschicken und damit automatisch gelistet werden.
    - Kunden beschweren sich dann aber, warum sie $Endkunde keine Mail an sie senden kann. "da kommt immer so ne komische Meldung!"
    - Die Erklärung "wenden Sie sich an T-Online, deren Server verschicken Spam" besänftigt die wenigsten, auch wenn das die einzig korrekte Antwort ist. Immerhin blockiert die T-Online ja auch rigoros alle Spamversender, und wenn es nur "ich will den Newsletter doch nicht haben"-"Spam" ist.



    Alles in allem keine leichte Abwägung.

    Dann macht es aber vermutlich mehr Sinn, eine separate Liste mit "Blacklisting-Ausnahmen" zu pflegen, statt die DNS-Whitelist dafür zu verwenden.
    DNS-Whitelists sind i.d.R. weniger dynamisch als Blacklists, daher macht es IMHO schon Sinn, akute Spam-Fluten weiterhin über Blacklists abzuhalten.


    Wir schauen uns die Postfix-Konfiguration mal an, mir schwebt da so was wie "/etc/postfix/blacklist-exceptions.db" vor, in die man dann (manuell) die auszunehmenden Mailserver eintragen kann.

    Zitat von kk

    Wir schauen uns die Postfix-Konfiguration mal an, mir schwebt da so was wie "/etc/postfix/blacklist-exceptions.db" vor, in die man dann (manuell) die auszunehmenden Mailserver eintragen kann.


    So ungern ich Ausnahmen pflegen und dadurch die Großen bevorzugen möchte (die definieren ja auch keine Ausnahmen für uns!) - auf das wird's rauslaufen müssen.

    Aktuell sehen die smtpd_client_restrictions ja etwa so aus:

    Code
    smtpd_client_restrictions =
    permit_mynetworks,
    check_sasl_access hash:/etc/postfix/sasl_access,
    permit_sasl_authenticated,
    reject_invalid_hostname,
    reject_unknown_reverse_client_hostname,
    reject_rbl_client ix.dnsbl.manitu.net


    Ich schlage vor, dass wir nach "permit_sasl_authenticated" noch eine (manuell pflegbare) Liste für's Server-Whitelisting aufnehmen:

    Code
    smtpd_client_restrictions =
    permit_mynetworks,
    check_sasl_access hash:/etc/postfix/sasl_access,
    permit_sasl_authenticated,
    [COLOR=#ff0000][B]check_client_access hash:/etc/postfix/client_exceptions,[/B][/COLOR]
    reject_invalid_hostname,
    reject_unknown_reverse_client_hostname,
    reject_rbl_client ix.dnsbl.manitu.net


    Diese Liste enthält dann die IP-Adressen oder Hostnamen von Servern, die man immer durchlassen möchte, z.B.:

    Code
    mailout01.t-online.de OK
mailout02.t-online.de OK
...


    wobei statt "OK" evtl. ein "DUNNO" angebracht wäre, das müssten wir noch testen. Schließlich sollen die restlichen Prüfungen (insbes. Antivirus) ja weiterhin ausgeführt werden.

    Zitat von antondollmaier

    So ungern ich Ausnahmen pflegen und dadurch die Großen bevorzugen möchte (die definieren ja auch keine Ausnahmen für uns!) - auf das wird's rauslaufen müssen.


    Ich stelle dann mal ganz kätzerisch die Frage, ob diese Blacklists jeweils so geeignet sind. Eigentlich sollte dann z.B. Spamcop mal eine Ausnahme für T-Online definieren.


    Am schrecklichsten finde ich persönlich derzeit die IronPort-Sache von Cisco (https://www.talosintelligence.com/). Damit haben wir derzeit die größten Probleme - am einen Ende sitzen (oft kommunale :p) Kunden, die sich so ne IronPort zur Spam-Abwehr anschaffen aber die dann quasi unkonfiguriert mit "FooBar"-Standard-Zertifikaten betreiben, am anderen Ende fühlt sich niemand Verantwortlich für's Blacklisting oder De-Listing (es gibt da schlicht keine Ansprechpartner, keine Dokumentation und keine Verantwortung... ein Blacklisting erfolgt scheinbar willkürlich...).
    So, das musste mal raus... :mad:

    Ich muss Anton vom Ansatz her Recht geben - es mag tatsächlich LC-User geben, die solche Ausnahmen unkompliziert setzen möchten. In der Sache an sich bin ich jedoch - gerade auch bei T-Offline - knallhart: da würde ich niemals und unter keinen Umständen eine Ausnahme machen, denn das tun die Großen für uns "Kleine" auch nicht. Ganz im Gegenteil - die agieren oft so, als wären sie die Hüter von Recht und Ordnung des Internet. Und wenn ich da noch an die schöne Option "Liste der sicheren E-Mail-Server" im Speedport von T-Offline denke (hab ich quasi jede Woche Anfragen von Neukunden, die keine Mails versenden können, weil unsere Mailserver da natürlich nicht in der Liste stehen), dann bestärkt mich das nur in meiner Meinung. Sollen denen ihre Kunden mal schön Dampf machen, wenn Sie geblacklistet wurden. Wir müssen schließlich auch selbst handeln, wenn uns das passiert und die "Großen" kommen uns auch nicht entgegen. Auch das musste mal raus ;)

    Zitat von kk

    wobei statt "OK" evtl. ein "DUNNO" angebracht wäre, das müssten wir noch testen. Schließlich sollen die restlichen Prüfungen (insbes. Antivirus) ja weiterhin ausgeführt werden.


    Mit einem DUNNO wird ja die Regel nur übersprungen und die nächste Prüfung kommt in Betracht. Steht diese IP dann auf einer Blacklist, wird sie mittels reject_rbl_client ja doch wieder abgelehnt.

    Zitat von kk

    Dann macht es aber vermutlich mehr Sinn, eine separate Liste mit "Blacklisting-Ausnahmen" zu pflegen, statt die DNS-Whitelist dafür zu verwenden.
    DNS-Whitelists sind i.d.R. weniger dynamisch als Blacklists, daher macht es IMHO schon Sinn, akute Spam-Fluten weiterhin über Blacklists abzuhalten.


    An sich ist das meines Erachtens eine gute Idee, allein der Aufwand für die manuelle Pflege ist enorm groß, wenn ich an die Anzahl der einzupflegenden IPs denke. Da ist das Einbinden einer Whitelist noch vor den rbl_rejects einfacher. Im Falle einer aufkommenden Spamflut kann man diese schnell kurzfristig entfernen.

    Zitat von ThomasKochler

    An sich ist das meines Erachtens eine gute Idee, allein der Aufwand für die manuelle Pflege ist enorm groß, wenn ich an die Anzahl der einzupflegenden IPs denke. Da ist das Einbinden einer Whitelist noch vor den rbl_rejects einfacher.


    Na kennst du welche die wirklich was taugen?


    Wobei ich den Aufwand relativieren würde, je nach aufkommen kann man die doch hinzufügen wenn es Probleme gibt und dann wächst es mit der Zeit von alleine. Ich gehe einfach mal davon aus das die Whitelist ja nicht der einzige Gatekeeper ist und die meisten Mails ganz normal durchgehen.


    Wird diese Funktion künftig umgestezt? Aktuell haben wir wieder das Problem mit der Telekom. Natürlich sind die Kunden im glauben, der Fehler liegt bei uns, wo sonst? :rolleyes: So eine Whitelist-Funktion wäre eine große Hilfe, auch wenn ich die Telekom nicht mag. Es geht hier jedoch an erster Stelle um die Kundenzufriedenheit.

    Gibt es hier schon etwas neues oder ist die Sache schon in vergessenheit geraten? Es sollten irgendwo ausnahmen definiert werden für Absender, die dann auch wirklich durchkommen. Aktuell beschweren sich Kunden, das Mails von facebook nicht ankommen, weil die auf irgendeiner Blacklist stehen. Schuld sind natürlich wir, wer sonst... bei facebook kann man ja nicht fragen, wir sind hingegen immer erreichbar. Mit einer ausnahmeregel wären solche Anfragen künftig überflüssig. Wenn es um facebook geht, verstehen einige keinen Spaß.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden