Beiträge von 17martin

  • Unabhängigkeit mehrere Email-Domains auf einem Server

    Hallo Forum,

    ich ziehe gerade meinen Mailserver von einem anderen Anbieter auf einen netcup Server um. In dem Zuge aktualisiere ich auch von Debian Stretch (bisher dovecot+postfix) auf Buster. Ich hoste Mails für mehrere Domains, die möglichst unabhängig sein sollen. Am liebsten sollten man auch von außen nicht so einfach sehen, dass die Domains zusammen gehören. Mir ist klar, dass am Ende alles auf der gleichen IPv4 endet und man somit immer herausfindet kann, dass das auf dem gleichen Server gehostet ist.


    Die User der Domain domain1.com können mit Hilfe von SNI imap und submission über mail.domain1.com betreiben. Mit dem neuen SNI fähigen postfix oder mit dem submission-proxy von dovecot sollte das ja gehen. Damit brauche ich kein Zertifikat mehr, in dem alle Domains zusammen enthalten sind. Die Mail-Clients sollten alle SNI beherrschen.


    Aber wie bekomme ich das für die smtp Kommunikation (Port 25, Server zu Server) am besten hin?

    Mein Server sendet Email: Da kommt der Spam-Check vom Empfänger ins Spiel. Ich habe bisher nicht gefunden, dass man den HELO/EHLO in Abhängigkeit der Absender Domain setzten kann. Den Reverse-DNS kann ich auch nur auf einen Wert setzten. Das heißt hier habe ich wenig Chance das domain-spezifisch zu machen und muss einen Namen nehmen, der dann für alle Domains genutzt wird. Auch mit exim, der ja schon lange SNI beherrscht, habe ich da keine Lösung gefunden. Oder kennt dafür jemand eine tolle Lösung?

    Mein Server empfängt Email: Hier könnte ich den MX domain-spezifisch (mail.domain1.com) setzten. Dann muss aber der sendende Server auf jeden Fall SNI beherrschen, sonst antwortet mein Server mit dem falschen Zertifikat. Hat jemand Erfahrungen, ob die TLS-fähigen Server auch SNI beherrschen? Wie reagieren die Server, die das nicht beherrschen, auf das falsche Zertifikat? Rückfall auf unverschlüsselte Kommunikation? Der EHLO und Reverse-DNS sollten hier ja keine Rolle spielen. Oder doch lieber als MX für alle Domains den Namen aus dem Sende-Fall nehmen?


    Ich bin doch sicher nicht der einzige mit dem Anwendungsfall. Habt ihr eine Lösung dazu gefunden (außer eigene IPv4 für die Domains)?

  • Große Mailprovider und deren Alles-ist-Spam-Regelung

    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.

  • Debain Buster kommt voraussichtlich am 6.7.2019

    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?

  • Das längste Thema

    Zitat von 03simon10

    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.

  • Das längste Thema

    Pufferueberlauf

  • Das längste Thema

    Zitat von mainziman

    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.

  • Das längste Thema

    Zitat von killerbees19

    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.

  • Das längste Thema

    Zitat von killerbees19

    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.

  • Das längste Thema

    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.