Beiträge von 17martin

    Mein Mailserver steht noch nicht bei Netcup (Umzug geplant). Gestern ist auf gefallen, dass wir auf der T-Online Blackliste gelandet sind (Fehler 554 im SMTP Dialog). Genau genommen ist nicht unser Server auf der Blacklist gelandet, sonder der ganze IP Bereich, weil unsere IP-Nachbaren wohl Unfug treiben. Da muss ich Telekom mal loben, das ging alles sehr schnell und einfach. Hier gibt es eine gute Beschreibung, was man beachten sollte: https://postmaster.t-online.de (Allgemein eine gute Beschreibung, was man als Mail-Server einhalten sollte)

    Das Onlineformular ausgefüllt (mail-tester.com 10/10 Punkte erwähnt und dass wir auf sonst keiner verbreiteten Blacklist stehen). Antwort innerhalb von 1,5 Stunden. Nochmal 1,5 Stunden später haben sie unsere Mails wieder angenommen.

    Ich werde meinen Server bald neu installieren (bisher ist der zum probieren) und möchte dann gleich mit Buster anfangen.

    Weiß eigentlich was netcup beim "Stretch minimal System" Image alles anpasst? Partitionierung und Deutsche Sprache weiß ich noch. Zyklisch fstrim? Irgendwas für KVM oder ihre Server?

    Mir geht‘s darum, dass in 20 Jahren auch dasselbe rauskommt, wenn ich es als pdf exportiere. Wäre bspw. hilfreich, wenn ich n Wort im Dokument ersetzen will o.Ä., aber nicht alles umschmeißen will.

    Keine Ahnung, wie LaTeX da tickt...

    Als LaTex-Suite unter Windows habe ich immer MiKtex genutzt. Das war gut. Wenn du die MikTeX Version mit archivierst kommt natürlich auch in 20 Jahren wieder das selbe .pdf raus, wenn man sie dann noch zum laufen bekommt. Wenn du in 20 Jahren ein dann aktuelles LateX nimmst kann das schon anders aussehen. Eventuell gibt es manche Pakete nicht mehr oder haben sich im Verhalten geändert. Dadurch dass .tex aber plain Text ist, kommst du an deinen Inhalt auf jeden Fall immer dran. Der Ansatz von Latex ist ja gerade "Kümmer du dich um den Inhalt. Layout kann ich eh besser."

    Bei Word reicht es ja schon einen anderen Drucker auszuwählen um sich das Layout zu zerschießen. Zumindest war das lange so. Das sind nicht mal paar Minuten stabiles Layout.

    17martin  KB19 wie soll sich denn SNI bei einem Mailserver wie Dovecot auswirken?

    man hat ja nicht wie bei Apache virtuelle Hosts, oder?

    Doch schon. Du hast z.B. users@domain1.de und users@domain2.de als Mailaddressen, die der Server zuständig sein soll. Mit SNI kannst du beide auf einem Server verwalten und jeder kann "seinen" Mail server unter mail.domain1.de bzw mail.domain2.de erreichen. Ohne TLS is das ja eh kein Problem. Mit TLS muss im Zertifikat auch der richtige Host-Name stehen. Ohne SNI geht das nur in dem man ein Zertifikat, das alle Domains enthält, erstellt. Mit SNI, kannst du für jede Domain ein anderes Zertifikat ausliefern.

    Wen interessiert das überhaupt? Bitte nicht weiterlesen…

    Bis auf die Tatsache, dass sich mein Thunderbird seltsam verhält (Fehlermeldung & sofortige Speicherung in gesendeten Objekten⁈), wenn der Postfix dahinter aufgrund von Fehlern nicht erreichbar ist, ist besonders das XCLIENT-Feature für dovecot-submissiond sehr praktisch.

    Einziger Schönheitsfehler: Derzeit gibt es keine Möglichkeit, Details über den verwendeten TLS-Cipher im Header zu hinterlegen. Dovecot selbst kann es noch nicht und Postfix weiß nichts davon, was Dovecot vorher ausgehandelt hat.

    Wenn das stabil läuft, sehe ich trotzdem keinen Grund mehr, für Postfix mehr als Port 25 nach außen zu öffnen.

    Interesiert mich auf jeden Fall. Das soll in mein "Buster"-Setup dann auch mit rein. Gerne weiter berichten. Weiterer Vorteil: Dovecot unterstützt SNI, Postfix nicht. Obwohl das mit Postfix 3.4 vielleicht doch kommen soll. Damit kann dann auch jeder unter mail.seinedomain seine Mails abgeben, ohne das man ein Zertifikat braucht in dem alle Domains drin stehen, die der Server bedient.

    Sehe ich das richtig, dass man bei gleichzeitiger Nutzung von RSA und ECDSA Zertifikaten noch immer möglichst viel selbst erledigen muss, wenn sich der Publickey nicht andauernd ändern soll? (Stichwort TLSA-Record)

    D.h. den Key und CSR für beide Varianten erstellen und nachher das Zertifikat mit certbot certonly anfordern. Um die Verlängerung bzw. den Speicherort kümmert man sich besser selbst mit einem kleinen Script.

    Oder habe ich irgendeinen supertollen modernen Weg übersehen? Genutzt wird übrigens Debian Buster, die eingesetzten Versionen sollten somit aktuell sein.

    Bei ECDSA Zertifikaten, nein (nichts übersehen). Bei RSA Zertifikaten kannst du die Option --reuse-key nutzten, um zu verhindern, dass sich der Key dauernd ändert.

    Ich hoffe ja, dass es die OpenSSL 1.1.1. noch nach Buster schafft.

    Ab certbot 0.25 (in stretch-backports verfügbar) gibt es die option --reuse-key. Damit sollten ohne eigenen CSR die TLSA (3 1 1) Einträge gleich bleiben. Am besten den Parameter in die cli.ini packen.

    Stimmt, vergessen: Apache2 unter Debian

    Falls du Stretch nutzt, Apache ist noch gegen OpenSSL 1.0.1 gelinkt. Falls du wie gunnarh auf der Kommandozeile deine Cipher ausprobierst, wird aber OpenSSL1.1.0 genutzt. Ja das Ergebnis ist anders, besonders die Reihenfolge.

    Das könnte sein, was du willst (ungetestet):

    HIGH:MEDIUM:ALL:!LOW:!EXP:!DES:!MD5:!RC4:!IDEA:!SEED:!aNULL:!eNULL:!PSK:!DSS:!SRP:-RSA:-SHA:-3DES:DES_CBC3_SHA

    Ob du MEDIUM und ALL wirklich brauchst, solltest du dir überlegen. TLSv1.2 und/oder TLSv1 oder einzelne Cipher hinzufügen macht vielleicht mehr Sinn. Je nachem, was du erreichen willst.

    Hallo,

    ich habe gerade meinen neuen VPS500 G7 in Betrieb genommen. Sieht soweit alles ganz gut aus. Betriebssystem ist Debian Stretch. Ein "cat /proc/cpuinfo" zeigt unter Flags die unterstützten Erweiterungen des Instruktionssatzes an. Leider werden "aes" und "pclmulqdq" nicht unterstützt. Ich denke gerade die beiden wären für viele hier ein großer Vorteil, da sie Verschlüsselung (besonders AES-GCM) und Signierung wirklich stark beschleunigen und zumindest OpenSSL sie in fast jeder Distro von selbst nutzt. Das könnte besonders Last-Bursts auf den Servern lindern. Da hätten ja alle, was davon...

    Ich weiß nicht wie heterogen die Netcup-Server sind auf denen VPS gehostet wird. Für die Leistung wäre es natürlich am besten den kompletten Instruktionssatz des Host weiter zugeben. Dann ändert sich aber eventuell der Instruktionssatz, wenn eine VM auf einen anderen Server umgezogen wird. Das mag manche Kunden stören.

    aes und pclmulqdq (zusammen mit sse3, ssse3, sse4.1, sse4.2) werden seit Intel Westmere/ Nehalem-C (2010) unterstützt. Intel SandyBrdige (2011) und AMD Bulldozer (Opteron 62xx, 2011) unterstützen zusätzlich noch avx und xsave. Ich denke die Netcup-Server werden keine älteren Prozessoren einsetzten und sollten somit in der Lange die Instruktionen anzubieten.

    Kann Netcup den Parameter "qemu -cpu" Parameter anpassen? Je nachdem wie heterogen die Server sind auf einen wirklichen Prozessor (ein älterer Intel sollte von einem neuen abbildbar sein) oder zumindest dem generischen "qemu64" oder "kvm64" ein paar weitere Instruktionen, die er unterstützten soll, mitgeben? Mit x2acpi wird das ja schon gemacht, glaube ich. Instruktionen hinzuzufügen, sollte, meine ich, keinen Bestandskunden stören, oder?

    Ich habe OpenSSL mal gezwungen aes und pclmulqdq zunutzten (egal, was die Cpu Flags anzeigen) und zumindest auf meinem Host geht das. Aber wie ich den ganzen Services, die die OpenSSL-Lib nutzten, das beibringe, weiß ich noch nicht. Falls jemand das schon gemacht hat, bin ich für Infos dankbar.