whoami0501 und alle, die anderswo ihre mailout server haben - ist das auf der anderen Seite des Zauns wirklich besser?
Beiträge von joergmschulz
-
-
Code
94.16.116.xist seit gestern geblockt.
https://support.microsoft.com/en-us/supportr…22-3ba03d6b8d75 / Ticket erstellt.
-
Dann hast du etwas falsch gemacht. Nativ laufender MTA kann sich auf eine IP oder eine virtuelle NIC binden (eth0.1) - mit Containern muss dann das NAT richtig eingestellt werden, ggf. muss eine andere Routingtabelle eingesetzt werden.
Diese Antwort ist korrekt. Man muß unter Docker wirklich mit NAT arbeiten. War mir zu blöd, das zu dokumentieren - nutze nun das primäre interface.
-
... Hier scheint es beim docker run Befehl mit
Code-p <ip>:<hostPort>:<containerPort>eine Möglichkeit zu geben, Container an spezifische IPs zu binden. Mal sehen obs klappt. Wenn nicht, wars Lehrgeld.
incoming klappt das wunderbar, aber outgoing wird die primäre IP genutzt. Be mir jedenfalls, ich lasse mich gerne eines Besseren belehren. Würde mir sehr nützen...
-
Ich möchte sie gar nicht mal als Failover einsetzen, sondern für meinen Mailserver, der dann letztmalig die IP (mit Reputation und Whitelistings) wechseln müsste, egal welcher Server drunter hängt.
Das wird nix - der Mailserver verwendet immer die physische IP für den Versand. Oder meinst Du: immer wenn die reputation schlecht wird, wechselst Du halt den Versende-Server (smarthost) und die Failover IP, auf der empfangen wird, wandert gegebenenfalls mit? Es ist eh eine gute Idee, Empfang und Versand auf zwei SMTP Prozesse zu verteilen.
-
ich habe zwar fast alle Disketten weggeworfen, aber auch die 5,25" und 3.5" Disks mit meinen Sourcecodes oder Demos habe ich trotzdem behalten...
irgendwie ärgere ich mich jetzt, die 50 Suse Linux Disketten von damals weggeworfen zu haben. Sind doch ein hübsches Museumsstück.
-
Ok, dann doch nur die erste Methode mit "außer Haus am A der Welt ohne Smartphone und Tablet"
Genau so getan. Nur echte Enten gesehen. Kein Mobilempfang da oben auf der Nordseeinsel. Geschafft, ein Jahr ohne Osterangebote!
-
Kurzfassung:
Es gab plötzlich eine Situation, in der ich mich primär mit mir selbst beschäftigen musst und für den Rest blieb keine Zeit.welcome back! Und: Alles Gute!
-
Ich bin vorhin wegen etwas aus unserem Büro raus, war dann noch gemütlich auf dem stillen Örtchen, komme zurück und der ganze Raum nur so "Endlich bist du wieder da, Emails gehen nicht!!!". Ich setze mich hin, frage woran das denn festgemacht wurde (Tests zwischen den Kollegen, Anrufe von außerhalb), entsperre den Bildschirm, schaue auf mein Thunderbird, schaue auf die Uhrzeit, schaue auf das grüne Monitoring... sagt plötzlich der erste Kollege "Jetzt kam wieder eine!". Kurz darauf auch die anderen...
Ich habe wortwörtlich nichts gemacht. Glaubt man mir natürlich nicht. Hilft auch echt nicht, dass es gestern einen ähnlichen Effekt bei etwas anderem gab.Ha! Da bin ich endlich den Fluch losgeworden. Früher, als ich noch admin war, geschah mir das dauernd. Am schlimmsten Wochenends. Anruf: nix geht. Einloggen: geht doch. Kommentar: Danke daß Du so toll geholfen hast.
-
mit der bullseye-minimal Version mußt Du vielleicht weniger abspecken, bevor Du ans Netz gehen willst. Ansonsten wirklich: Geschmackssache.
-
ein paar kleine Eingriffe in ufw, und dann wird geblockt wie erwartet - siehe https://github.com/chaifeng/ufw-docker
oder in
/etc/ufw/after.rules vor dem letzten Commit:
Code
Alles anzeigen# BEGIN UFW AND DOCKER # *filter :ufw-user-forward - [0:0] :ufw-docker-logging-deny - [0:0] :DOCKER-USER - [0:0] -A DOCKER-USER -j ufw-user-forward # these are your local networks / docker networks -A DOCKER-USER -j RETURN -s 10.0.0.0/8 -A DOCKER-USER -j RETURN -s 172.16.0.0/12 -A DOCKER-USER -j RETURN -s 192.168.0.0/16 -A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN # allow some common ports -A DOCKER-USER -p tcp --dport 25 -j RETURN -A DOCKER-USER -p tcp --dport 1025 -j RETURN -A DOCKER-USER -p tcp --dport 1465 -j RETURN -A DOCKER-USER -p tcp --dport 143 -j RETURN -A DOCKER-USER -p tcp --dport 1143 -j RETURN -A DOCKER-USER -p tcp --dport 1993 -j RETURN -A DOCKER-USER -p tcp --dport 4190 -j RETURN -A DOCKER-USER -p tcp --dport 80 -j RETURN -A DOCKER-USER -p tcp --dport 587 -j RETURN -A DOCKER-USER -p tcp --dport 443 -j RETURN -A DOCKER-USER -p tcp --dport 8443 -j RETURN -A DOCKER-USER -p tcp --dport 9980 -j RETURN -A DOCKER-USER -p tcp --dport 993 -j RETURN -A DOCKER-USER -p tcp --dport 8888 -j RETURN -A DOCKER-USER -p tcp --dport 8021 -j RETURN -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16 -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 192.168.0.0/16 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 10.0.0.0/8 -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.16.0.0/12 -A DOCKER-USER -j RETURN -A ufw-docker-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW DOCKER BLOCK] " -A ufw-docker-logging-deny -j DROP COMMIT # END UFW AND DOCKER -
i wo, irgendwann sagt Apple dann von heut auf morgen Schluß mit IPV4, und wer nur noch IPV4 macht, bleibt draußen
-
Enten mit zwei Augen? Ich dachte die haben alle zwei Augen.
Nee, die Enten hier haben alle vier. Damit das 4Augen Prinzip durchgehalten werden kann.
-
Mach ich schon jeher so! Einmal kritisch von Rechts geguckt, einmal von Links: Müsste passen! => Uuund durch!
Mannomann Du hast ja recht. 4Augen. 2Hirne. Quak!
-
im normalen Umfeld / bei Servergrößen, die Du hier von der Stange orderst, ist in der Regel so viel Plattenspeicher vorhanden, daß eine Trennung der Nextcloud Daten von der Nextcloud App nicht sinnvoll ist; die Performance profitiert auf jeden Fall.
Eher ist es sinnvoll, die Datenbank auf separates Blech zu schieben, dann kannst Du Lastspitzen zwischen NC App und NC Datenbank auf mehrere Kisten verteilen. So viel Auslastung wirst Du bei Deiner Erstinstallation aber nicht erleben.
Paß beim Docker auf Deine Firewall Regeln auf - solltest Du ufw nutzen, beachte https://github.com/chaifeng/ufw-docker: Sonst erlebst Du, daß Ports offen stehen, von denen Du das nicht erwartest (z.B. der redis server für Nextcloud oder der Datenbankserver).
-
joergmschulz Facebook und angehängtes Zeug a la WhatsApp und Co. gelten nicht als kritisch;
ich würde sogar meinen, wenn der Laden in die Luft fällt, hat das bis auf gröbere Staubwolken keine Auswirkung;
Einspruch, Euer Ehren. Die Auswirkungen wären riesig, aber positiv. Menschen würden wieder in echt miteinander sprechen müssen und müßten den Wahrheitsgehalt von Informationen in der echten Welt überprüfen. Oben steht aber was von 'wirklich kritischen' Systemen. Ob Facebook und Co wirklich kritisch sind, oder in ihren Auswirkungen wirklich kritisch betrachtet werden müssen, steht zur Debatte.
-
Wow, Facebook hat sich da ein wunderbares Eigentor zusammengeklickt:
BGP zerschießen, DNS unerreichbar, Gebäude-Zutritt nicht mehr möglich, wahrscheinlich auch die Alarmierungsketten für diejenigen, die es richten könnten.
Was lernen wir: bei wirklich kritischen Systemen nochmal nachsehen, wo der single point of failure liegen könnte. Und: bei wirklich kritischen Änderungen 2Augen Prinzip.
-
korrekt, das habe ich mißverstanden, und nun Asche über mein Haupt! Blocken die ehrlich smtp out:25 ??? Auf die Idee wäre ich nicht gekommen.
-
Port 25 erst nach einem Telefonat freigeschaltet bekommt.
Das ist doch nicht weiter schlimm - Deinen ausgehenden smtp server willst Du doch sowieso mit 587 oder einem custom Port erreichen. 25 zieht nur lästigen MailIn Verkehr an, den Du auf dem Server für eingehende Mail haben möchtest. Und der steht näher an Deinem rspam.
-
Eine sehr gewagte These.
ja? Schnell ein Beispiel aus der Geschichte der exploits: https://bigb0ss.medium.com/expdev-hp-open…er-b25ea5fab43f
