KeyHelp Community

Hallo KeyHelp Team,

es wäre super, wenn es die Möglichkeit geben würde, einen rbl_overwrite aus dem KeyHelp Panel heraus zu machen, sodass DNS / IP Adressen für DNSBL im Server gewhitelisted werden können.

Like this: https://www.howtoforge.de/anleitung/wie ... itelistet/

Off-Feature-Request: Kann mir jemand in diesem Atemzug noch sagen, ob die Einstellungen gespeichert bleiben - im Falle eines KH Updates - wenn ich sie im Postfix nun manuell vornehme oder ob es ggf. andere negative Effekte geben kann?

Cherrs
Toorms

Hallo,

händische Änderungen in der Postfix-Konfiguration (sofern diese nicht bereits durch ein KeyHelp Feature abgedeckt sind) sind immer update-save.

Toorms wrote: ↑Fri 26. Aug 2022, 08:40 es wäre super, wenn es die Möglichkeit geben würde, einen rbl_overwrite aus dem KeyHelp Panel heraus zu machen, sodass DNS / IP Adressen für DNSBL im Server gewhitelisted werden können.

Like this: https://www.howtoforge.de/anleitung/wie ... itelistet/

Die MTA Funktion check_client_access Dient in ihrer ursprünglichen Bedeutung der Zugriffskontrolle und ist sicher nicht dafür entworfen worden, um schlampig administrierte und dadurch spammende Mailserver durchzuwinken.
Ich persönlich halte es nicht für zielführend, das so wie von dir gewünscht ins Panel zu integrieren, denn so würde man das in KeyHelp etablierte Sicherheitskonzept mehr oder weniger ad absurdum führen.

Natürlich bleibt es jedem Admin selbst überlassen, bei individuellem Bedarf den zusätzlichen Check in die MTA Konfiguration einzupflegen. Ab und zu muß der Admin eben auch mal händisch eingreifen, das Panel ist kein universeller Problemlöser.

Toorms wrote: ↑Fri 26. Aug 2022, 08:40 Kann mir jemand in diesem Atemzug noch sagen, ob die Einstellungen gespeichert bleiben - im Falle eines KH Updates - wenn ich sie im Postfix nun manuell vornehme

Davon darfst du ausgehen, wie Alex schon sagt

Danke für die Antworten.

Nunja, ob ich dem Mail Versender auf der anderen Seite sage "euer Server ist ungeil konfiguriert / ihr seit auf der BL" oder in China fällt ein Sack Reis um ... die Mail muss beim Client eingehen und ich kann nicht wirklich darauf warten, bis die Gegenseite ihren Kram auf die Kette kriegt.

Aber ich verstehe heute Anmerkung natürlich

Toorms wrote: ↑Fri 26. Aug 2022, 10:01 ich kann nicht wirklich darauf warten, bis die Gegenseite ihren Kram auf die Kette kriegt

An diesem Punkt bin ich pragmatisch...unsauber konfigurierte Mailserver bleiben außen vor.
Ich habe viele Jahre lang meine Mailserversetups immer wieder angepaßt, um mit solchen Mailservern kommunizieren zu können. Aber die Zeiten sind vorbei, ich sehe einfach nicht ein, warum ich mir zusätzliche Arbeit machen soll, nur weil andere Mailserveradmins zu faul, inkompetent, whatever sind, ihren Job ordentlich zu machen.

Toorms wrote: ↑Fri 26. Aug 2022, 10:01 die Mail muss beim Client eingehen

Hmm...Wo ziehst du für dich die Grenze? Gilt das Argument auch noch, wenn die Mail virenverseucht ist...?

Alexander wrote: ↑Fri 26. Aug 2022, 09:27 Hallo,

händische Änderungen in der Postfix-Konfiguration (sofern diese nicht bereits durch ein KeyHelp Feature abgedeckt sind) sind immer update-save.

Die Diskrepanz, was ich hier vermute ist folgende: Die Zeile "smtpd_recipient_restrictions =" in der main.cf wird durch KeyHelp angepasst (durch Änderungen in der BL Listen z.B.). Wenn ich nun meine manuellen Änderungen mache, wie diese ...

Code: Select all

check_client_access hash:/etc/postfix/rbl_override,
... reject_rbl_client BLACKLIST.DNS (diese lasse ich unangetastet), 
... reject_rbl_client BLACKLIST.DNS (diese lasse ich unangetastet), 
permit

... dass diese dann mit einer neuen Änderung im Admin Panel "Mail Server Konfiguration" weg sind.

Daher nochmal meine Nachfrage nach dem Feature Wunsch. Ich meine, wer das nicht nutzen möchte, der kann es ja weg bzw. deaktiviert lassen.

Jolinar wrote: ↑Fri 26. Aug 2022, 10:22
Toorms wrote: ↑Fri 26. Aug 2022, 10:01 ich kann nicht wirklich darauf warten, bis die Gegenseite ihren Kram auf die Kette kriegt
An diesem Punkt bin ich pragmatisch...unsauber konfigurierte Mailserver bleiben außen vor.
Ich habe viele Jahre lang meine Mailserversetups immer wieder angepaßt, um mit solchen Mailservern kommunizieren zu können. Aber die Zeiten sind vorbei, ich sehe einfach nicht ein, warum ich mir zusätzliche Arbeit machen soll, nur weil andere Mailserveradmins zu faul, inkompetent, whatever sind, ihren Job ordentlich zu machen.

Toorms wrote: ↑Fri 26. Aug 2022, 10:01 die Mail muss beim Client eingehen
Hmm...Wo ziehst du für dich die Grenze? Gilt das Argument auch noch, wenn die Mail virenverseucht ist...?

Verstehe ich beides zum teil ja, meine Managed-Kunden aber nicht. Also das ist sowieso ein Thema über das man stundenlang diskutieren und philosophieren kann

Nein, virenversucht nicht, aber das wird nochmal an anderer Stelle geprüft. Aber wenn ich einen Mail Server habe, wo ich weiß, dass Kunde XY damit täglich kommuniziert, dann muss eine Lösung / Kompromiss gefunden werden. Ein schneller. Da ich weiß, dass die Gegenseite nicht gerade die schn(he)llsten sind, mache ich es eben.

Cheers.

Toorms wrote: ↑Fri 26. Aug 2022, 10:28 Die Diskrepanz, was ich hier vermute ist folgende: Die Zeile "smtpd_recipient_restrictions =" in der main.cf wird durch KeyHelp angepasst (durch Änderungen in der BL Listen z.B.). Wenn ich nun meine manuellen Änderungen mache, wie diese ...
Code: Select all
check_client_access hash:/etc/postfix/rbl_override,
... reject_rbl_client BLACKLIST.DNS (diese lasse ich unangetastet), 
... reject_rbl_client BLACKLIST.DNS (diese lasse ich unangetastet), 
permit
... dass diese dann mit einer neuen Änderung im Admin Panel "Mail Server Konfiguration" weg sind.

Ohne jetzt Alex' Erklärung vorgreifen zu wollen...Aber die main.cf wird zeilenweise (und das im wörtlichen Sinne) verarbeitet und die Zeile mit "smtpd_recipient_restrictions =" ist eine andere als die Zeile mit "check_client_access ...".

Jolinar wrote: ↑Fri 26. Aug 2022, 10:34 Ohne jetzt Alex' Erklärung vorgreifen zu wollen...Aber die main.cf wird zeilenweise (und das im wörtlichen Sinne) verarbeitet und die Zeile mit "smtpd_recipient_restrictions =" ist eine andere als die Zeile mit "check_client_access ...".

Hier einmal die vollständige formatierte Zeile dann:

Code: Select all

smtpd_recipient_restrictions = 
    permit_mynetworks, 
    permit_sasl_authenticated, 
    reject_unauth_destination, 
    reject_unauth_pipelining, 
    reject_non_fqdn_recipient, 
    check_policy_service unix:private/policy,
    hash:/etc/postfix/rbl_override,
    reject_rbl_client bl.spamcop.net, 
    reject_rbl_client bl.score.senderscore.com,
    permit

Diese wird vom KeyHelp Panel allerdings bei Änderungen der abgerufenen Blacklists geändert. Nun habe ich die befürchtung, dass wenn ich meinen manuellen Käse reinsetze, dass dieser dann weg ist, sobald ich mal wieder eine Blacklist hinzufüge oder ähnliches, denn ...

Code: Select all

...
    hash:/etc/postfix/rbl_override,
...
    permit

sind meine manuellen Änderungen.

Auch zusätzliche Einträge unter "smtpd_recipient_restrictions" werden prinzipiell respektiert.

Ich lese da quasi den aktuellen Wert von "smtpd_recipient_restrictions" ein, schmeiße dann "permit_dnswl_client" und "reject_rbl_client" Einträge raus, und füge diese anschließend wieder an. Die ursprüngliche Reihenfolge kommt damit natürlich ggf. durcheinander.
Quasi wenn man von oberen Beispiel ausgeht, würde das nach dem Speichern von "Konfiguration -> E-Mail-Server" bei rauskommen:

Code: Select all

smtpd_recipient_restrictions = 
    permit_mynetworks, 
    permit_sasl_authenticated, 
    reject_unauth_destination, 
    reject_unauth_pipelining, 
    reject_non_fqdn_recipient, 
    check_policy_service unix:private/policy,
    hash:/etc/postfix/rbl_override,
    permit
    reject_rbl_client bl.spamcop.net, 
    reject_rbl_client bl.score.senderscore.com,

Probiere es aber gern einmal selbst aus.

Alexander wrote: ↑Fri 26. Aug 2022, 13:01 Auch zusätzliche Einträge unter "smtpd_recipient_restrictions" werden prinzipiell respektiert.

Ich lese da quasi den aktuellen Wert von "smtpd_recipient_restrictions" ein, schmeiße dann "permit_dnswl_client" und "reject_rbl_client" Einträge raus, und füge diese anschließend wieder an. Die ursprüngliche Reihenfolge kommt damit natürlich ggf. durcheinander.
Quasi wenn man von oberen Beispiel ausgeht, würde das nach dem Speichern von "Konfiguration -> E-Mail-Server" bei rauskommen:
Code: Select all
smtpd_recipient_restrictions = 
    permit_mynetworks, 
    permit_sasl_authenticated, 
    reject_unauth_destination, 
    reject_unauth_pipelining, 
    reject_non_fqdn_recipient, 
    check_policy_service unix:private/policy,
    hash:/etc/postfix/rbl_override,
    permit
    reject_rbl_client bl.spamcop.net, 
    reject_rbl_client bl.score.senderscore.com,
Probiere es aber gern einmal selbst aus.

Danke für deine ausführliche Antwort. Ist die Frage ob die Reihenfolge Auswirkung hat … wenn ja, wäre ungeil.

Im Live System kann ich es leider nicht testen, hättet ihr was da zum Testen?

Besten Dank und viele Grüße

Setz dir nen V-Server zum Testen auf, fertsch.
Alex hat doch gesagt, dass es funktionieren wird.
Warum zweifelst du an seinen Worten?

Der gesamte „Test“ wird ungefähr zwei Minuten dauern. Mach das also einfach Nachts um drei auf deinem Produktivserver und kein Kunde wird es je merken.

Tobi wrote: ↑Fri 26. Aug 2022, 14:16 Mach das also einfach Nachts um drei auf deinem Produktivserver und kein Kunde wird es je merken.

Auch wenn du in diesem speziellen Fall recht hast...Man macht niemals irgendwelche Tests an produktiven Systemen!
Irgendwann (und dann garantiert zum ungünstigsten Zeitpunkt) geht so ein Test dann mal voll in die Hose...

@TE:
Bau dir für solche Zwecke daheim mit Virtualbox, VMWare, Whatever eine stabile Testumgebung auf.
Vorteile einer solchen Umgebung:
- keine Gefahr für produktive Systeme
- die Test-VMs können jederzeit in einen vordefinierten Zustand zurückgesetzt werden
- für spezifische Tests kann man die Rahmenbedingungen vorher exakt festlegen, was man bei Produktivsystemen nicht immer kann

Jolinar wrote: ↑Fri 26. Aug 2022, 14:28 Auch wenn du in diesem speziellen Fall recht hast...Man macht niemals irgendwelche Tests an produktiven Systemen!
Irgendwann (und dann garantiert zum ungünstigsten Zeitpunkt) geht so ein Test dann mal voll in die Hose...

Also in diesem speziellen Fall sollte man eigentlich direkt nach dem restart von postfix merken, ob es funktioniert oder eben nicht. Wenn nicht kann man es auch sofort wieder rückgängig machen.
Noch besser man macht eine Kopie der Config-Datei und kann so im Falle des Falles durch einfaches Umkopieren den status quo wiederherstellen.

Aber hier nach einem „Testserver“ für persönliches Ausprobieren zu fragen empfinde ich, gelinde gesagt, als dreist.

Alexander wrote: ↑Fri 26. Aug 2022, 13:01

Code: Select all

smtpd_recipient_restrictions = 
    permit_mynetworks, 
    permit_sasl_authenticated, 
    reject_unauth_destination, 
    reject_unauth_pipelining, 
    reject_non_fqdn_recipient, 
    check_policy_service unix:private/policy,
    hash:/etc/postfix/rbl_override,
    permit
    reject_rbl_client bl.spamcop.net, 
    reject_rbl_client bl.score.senderscore.com,

Probiere es aber gern einmal selbst aus.

Habe es gerade mal getestet.

Sobald ich einen neuen Blacklist Server per GUI hinzufüge, schreibt er - wie du es auch schon geschrieben hast - unten drunter. Das Problem ist, dass er es unter das "permit" schreibt, womit die Meldung

Code: Select all

warning: restriction `reject_rbl_client' after `permit' is ignored

erscheint. Also eine Sache von beiden wäre ganz cool, wenn das umgesetzt werden könnte:

a) Die neuen Einträge, welche über die GUI geschehen werden vor das "permit" geschrieben, wenn eins vorhanden ist (müsste ja manuell vom Admin eingetragen werden derzeit)
b) Die ganze rbl_overwrite wandert ins KeyHelp "Konfigruation -> Mail Server", was noch schöner wäre. Ich meine, wer es nicht nutzen möchte, der kann es ja einfach unangetastet lassen. Dennoch bin ich der Überzeugung, dass es für den ein oder anderen Hilfreich wäre.

Aus den restlichen Diskussionen klinke ich mich hier mal nicht ein ...

Geht doch

KeyHelp Community

rbl_overwrite Möglichkeit aus dem Keyhelp Panel

rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel

Re: rbl_overwrite Möglichkeit aus dem Keyhelp Panel