[SOLVED] Manitu provider

[AndreasHemsen]

Hallo zusammen,
als neues Mitglied habe ich eine Frage – vielleicht eine etwas dümm, ich bin mir nicht sicher.
Ich bin in diesem Bereich völlig neu, daher bitte ich um Nachsicht, falls meine Frage dümm erscheint.
Ich habe Proxmox Mail Gateway installiert und bin mithilfe von YouTube-Tutorials schon weit gekommen.
Ich verstehe aber nicht, wie ich eingehende E-Mails von meinem Provider „Manitu.de“ (wo meine Domain gehostet wird) so konfigurieren kann, dass sie direkt in meinem Posteingang landen, ohne den Umweg über das System des Providers.
Hat jemand Erfahrung mit der Konfiguration der Einstellungen für den Provider „Manitu“?
Wo genau muss ich die Einstellungen anpassen?

Vielen Dank im Voraus für eure Antworten.

 

[UdoB]

Ich betreibe selber keinen eigenen Mailserver mehr, kann aber dennoch einleitend antworten:

Deine eigene Domain wird ja irgendwo (bei Manitu) verwaltet und du solltest Zugriff auf third-level Einträge und auf den MX-Record haben. Falls das nicht der Fall ist, hast du vermutlich verloren.

Der MX-Record muss auf deinen Server zeigen. https://de.wikipedia.org/wiki/Mail_Exchange_Resource_Record

Als Beispiel der Record unseres Gastgebers:

~# host -t mx proxmox.com
proxmox.com mail is handled by 10 mail.proxmox.com.

~# host mail.proxmox.com.
mail.proxmox.com has address 94.136.29.106

Das sind fundamentale Grundlagen. Es sollte etliche Tutorials zu dem Thema geben und die Doku des PMG sollte eigentlich auch hinreichende Hinweise beinhalten.

Nachtrag: und der Reverse PTR muss korrespondieren - habe ich mal gelernt. Überraschenderweise ist das bei Proxmox nicht der Fall:

~# host 94.136.29.106
106.29.136.94.in-addr.arpa domain name pointer proxmox-new.maurer-it.com.

Diesen Umstand muss bitte jemand anderes erklären, mich irritiert das - möglicherweise sind meine Kenntnisse auch nur veraltet.



(( Nur nebenbei, ich will dich wirklich nicht abschrecken: ich habe das selber-hosten vor ~12 Jahren aufgegeben, weil es immer schmerzhafter wurde. SPF/DKIM/DMARC bereiteten mir heftige Kopfschmerzen, und die fehlende Akzeptanz der "großen" Provider hinsichtlich der von mir von "bösen" Adressen gesendeten Email brach mir dann das Genick. Vielleicht geht das heutzutage ja einfacher... ))

 

[a.woll]

Ich betreibe selber keinen eigenen Mailserver mehr, kann aber dennoch einleitend antworten:

Deine eigene Domain wird ja irgendwo (bei Manitu) verwaltet und du solltest Zugriff auf third-level Einträge und auf den MX-Record haben. Falls das nicht der Fall ist, hast du vermutlich verloren.

Der MX-Record muss auf deinen Server zeigen. https://de.wikipedia.org/wiki/Mail_Exchange_Resource_Record

Als Beispiel der Record unseres Gastgebers:

~# host -t mx proxmox.com
proxmox.com mail is handled by 10 mail.proxmox.com.

~# host mail.proxmox.com.
mail.proxmox.com has address 94.136.29.106

Das sind fundamentale Grundlagen. Es sollte etliche Tutorials zu dem Thema geben und die Doku des PMG sollte eigentlich auch hinreichende Hinweise beinhalten.

Nachtrag: und der Reverse PTR muss korrespondieren - habe ich mal gelernt. Überraschenderweise ist das bei Proxmox nicht der Fall:

~# host 94.136.29.106
106.29.136.94.in-addr.arpa domain name pointer proxmox-new.maurer-it.com.

Diesen Umstand muss bitte jemand anderes erklären, mich irritiert das - möglicherweise sind meine Kenntnisse auch nur veraltet.



(( Nur nebenbei, ich will dich wirklich nicht abschrecken: ich habe das selber-hosten vor ~12 Jahren aufgegeben, weil es immer schmerzhafter wurde. SPF/DKIM/DMARC bereiteten mir heftige Kopfschmerzen, und die fehlende Akzeptanz der "großen" Provider hinsichtlich der von mir von "bösen" Adressen gesendeten Email brach mir dann das Genick. Vielleicht geht das heutzutage ja einfacher... ))

Das Ideal: Wie es aussehen sollte (FCrDNS)​

Für einen sauberen Mailversand fordert der Internet-Standard (RFC 5321) und die Best Practice der großen Provider ein dreistufiges, kreisrundes Matching:

1. MX-Record: proxmox.com verweist auf mail.proxmox.com.
2. A-Record (Forward): mail.proxmox.com verweist auf die IP 94.136.29.106.
3. PTR-Record (Reverse): Die IP 94.136.29.106 sollte per Reverse-DNS wieder exakt auf mail.proxmox.com verweisen.

Wenn Schritt 2 und Schritt 3 exakt übereinstimmen, spricht man von FCrDNS.

Die Realität: Was passiert bei Proxmox?​

Bei Proxmox bricht die Kette im dritten Schritt. Die IP 94.136.29.106 gehört offensichtlich zur Infrastruktur des IT-Dienstleisters Maurer IT (der Firma hinter Proxmox) und liefert den PTR Proxmox-new.maurer-it.com.

Jetzt fragt man sich zurecht: Warum blockieren Google, Microsoft und Co. diese Mails nicht sofort?

Dafür gibt es drei Hauptgründe:

1. Das SMTP-HELO-Matching ist entscheidender​

Wenn der Proxmox-Mailserver eine Verbindung zu einem anderen Server aufbaut, grüßt er im SMTP-Protokoll mit einem Namen (dem sogenannten HELO/EHLO-Hostnamen).

Moderne Spam-Filter prüfen beim Reverse-DNS primär zwei Dinge:

• Gibt es überhaupt einen gültigen PTR-Record? (IPs ohne PTR fliegen sofort raus).
• Entspricht der PTR dem Namen, mit dem sich der Server im HELO vorstellt?

Wenn der Proxmox-Server sich bei der Gegenstelle mit HELO proxmox-new.maurer-it.com meldet, ist der Check für den empfangenden Server bestanden! Der PTR matcht das HELO. Dass die Mailadresse am Ende @proxmox.com heißt, ist für diesen spezifischen Netzwerk-Check zweitrangig.

2. Der "Generic-PTR"-Filter​

Spam-Filter prüfen, ob ein PTR nach einer dynamischen Endkunden-Leitung aussieht (z.B. dsl-94-136-29-106.provider.de). Das ist hier nicht der Fall. proxmox-new.maurer-it.com sieht valide nach einem statisch konfigurierten Server einer IT-Firma aus. Viele Filter geben sich damit im ersten Schritt zufrieden.

3. SPF, DKIM und DMARC fangen es ab​

Und hier kommen wir zu dem Punkt, den du aus deinem eleganten Rückzug vor 12 Jahren erwähnt hast. Heute läuft die echte Authentifizierung fast ausschließlich über die Krypto- und Policy-Einträge im DNS der Absender-Domain:

• SPF (Sender Policy Framework): Im DNS von proxmox.com steht eine Liste der IPs, die senden dürfen. Wenn dort 94.136.29.106 (oder das Subnetz) erlaubt ist, ist alles legitim.
• DKIM (DomainKeys Identified Mail): Die Mail wird auf Server-Ebene kryptografisch signiert. Der Empfänger prüft den Schlüssel via DNS von proxmox.com. Ist die Signatur gültig, ist der Transportweg (und damit der PTR) fast egal.
• DMARC: Bindet SPF und DKIM zusammen und sagt, was passieren soll, wenn die Checks fehlschlagen.

Weil Proxmox diese drei Technologien mit Sicherheit sauber für proxmox.com hinterlegt hat, vertrauen die großen Provider den Mails – selbst wenn das klassische Reverse-DNS-A-Record-Matching hinkt.

 

[Johannes S]

Vielleicht geht das heutzutage ja einfacher...

Ist es nicht, ich habe u.a. aufgrund der im folgenden Vortrag dargelegten Pitfalls nie damit angefangen und der Vortrag hat meine Entscheidung für mich bestätigt (es war am Ende halt wirklich so schlimm, wie ich befürchtet habe mit meinen Halbwissen):
https://media.ccc.de/v/clt26-387-warum-kommt-meine-mail-nicht-an-ein-uberblick


Die Technik ist dank mailcow, pmg und co nicht schwer einzurichten, der saubere Betrieb, um nicht auf Antispamlisten zu landen, dagegen schon. Dafür ist mir zuhause meine Zeit zu schade

 

[a.woll]

Ist es nicht, ich habe u.a. aufgrund der im folgenden Vortrag darfelegten Pitfalls nie damit angefangen und der Vortrag hat meine Entscheidung für mich bestätigt:
https://media.ccc.de/v/clt26-387-warum-kommt-meine-mail-nicht-an-ein-uberblick

Dem stimme ich zu. Es ist nicht leichter. Die Herausforderung, es richtig machen zu müssen, ist gewachsen. Aber es ist machbar.
Wenn man seinen DNS sauber hält, SPF, DKIM und DMARC auf Maximum härtet (also ausschließlich hardfail bzw. reject) und den Server in einem geeigneten IP-Netz aufsetzt, dann schafft man ein System, bei dem nur noch dann ein primärer Reputationsschaden zu erwarten ist, wenn die eigenen Accounts gehackt werden.

Die Technik ist dank mailcow, pmg und co nicht schwer einzurichten, der saubere Betrieb, um nicht auf Antispamlisten zu landen, dagegen schon. Dafür ist mir zuhause meine Zeit zu schade

Bei Antispamlisten hätte ich nur Sorge, auf uceprotect-L2 oder -L3 zu landen. Das sind die einzigen soweit ich weiß, bei denen du bestraft werden kannst, ohne selbst was gemacht zu haben. Deswegen hab ich auch dafür gesorgt, in einem Subnetz und bei einem Provider zu sein, mit tadellosem Ruf. Mein PMG filtert Spam auch nach außen, um nicht in Honeypots bei Spamhaus etc. zu landen.

 

[AndreasHemsen]

Hallo alle Antwort Gebern

Ich schiebe dies Projekte erst mal im Kühlschrank, will erst mehr Kenntnis bekommen über selbst hosting und Anverwandte.

Vielen Dank für eure ausführliche Antwort.