Ruppel Mein Mailserver (MX) ist wohl nicht mit seiner IPV6 Adresse auf Port 25 erreichbar.
Wenn der Server für IPv6 konfiguriert ist, läuft das mit mailcow eigentlich out-of-the-box und ohne Änderung irgendwelcher Bindings. Man muss im Gegenteil sogar einiges tun, um IPv6 zu deaktivieren.
Ruppel Error starting userland proxy: listen tcp6 [::]:4190: bind: address already in use
Da lauscht offenbar schon etwas auf Port 4190.
Ruppel Hier mäkelt er “TLS version” und “Ciphers (Algorithm selections)” an.
Anscheinend erlaube ich TLS 1.1 und/oder TLS 1.0.
Das ist normal und hat bei internet.nl keine Auswirkung auf die Punktzahl. Ich komme auf 100 und habe diesen Hinweis ebenfalls. Du musst entscheiden, ob du riskieren möchtest, ggf. für andere Mailserver, die noch ältere Verfahren einsetzen, nicht mehr erreichbar zu sein. Man könnte auch sagen, besser eine nicht mehr ganz so gute als gar keine Verschlüsselung.
internet.nl schreibt ja auch selbst: “Note that quite some mail servers only support older TLS versions. If the sending and receiving mail server both do not support the same TLS version, they will usually fall back to unencrypted mail transport. Because of that it could be advisable to keep supporting TLS versions with a ‘phase out’ status for a while. Make an informed decision based on log data on when to disable these ‘phase out’ TLS versions.”
Ruppel Ein rotes Schild habe ich bei “Key exchange parameters”.
Er behauptet mein MX Server nutzt “DH-2048” und das sei “insufficient”.
mailcow verwendet standardmäßig DH-2048-Parameter unbekannten Ursprungs, die initial aus data/assets/ssl-example nach data/assets/ssl kopiert werden.
Ich hab sie bei mir durch eine 4096-bit-Gruppe gemäß RFC 7919 ersetzt:
internetstandards/dhe_groups
Ruppel Auch ein rotes Schild habe ich bei “DANE existance”.
Wenn mir da einer einen Hint geben kann, wie die Schritte zur Erfüllung dieser Anforderung für Mailcow aussehen, dann wäre ich sehr glücklich.
DANE ist relativ komplex und unabhängig von mailcow einzurichten. Du benötigst auf jeden Fall DNSSEC für deine Domain(s). Dann legst du TLSA-Records im DNS an, die Hashwerte deiner eingesetzten Zertifikate enthalten. Ein Client kann darüber unabhängig prüfen, ob die Zertifikate der Gegenstelle valide sind. Hier ist ein guter Einstieg: 
DANE und TLSA DNS-Records erklärt thomas-leister.de
this blog post
