MX auf mail.domain.tld und rDNS auch auf mail.domain.tld. Es ist relevant, das vorwärts und rückwärts passt.
mail.domain.tld -> 123.123.123.123 (A Record und MX)
123.123.123.123 -> mail.domain.tld (rDNS Record, kann z.B. mit tracert oder traceroute angezeigt werden)
Es zeigt aber immer noch alles auf domain.tld . PTR, MX Record etc.
Wie sieht die docker-compose.yml aus, die Du verwendet hast? Bitte keine Passwörter posten.
Da ist außer SSH, HTTP und HTTPS gar nichts offen, auf dem Server. Imho Container Ports nicht rausgelegt. Gar keinen.
Ich kenne Mailu nicht, vielleicht wäre https://mailcow.email sowieso die bessere Wahl…
Naja, er hat ja schon im Eingangspost geschrieben, dass er mit Mailcow "ordentlich gescheitert" ist. 
Warum genau ist es eine schlechte Idee den Mailserver auf der Root-Domain zu haben? Würde ich gerne wissen, werde ich aber auch jetzt ändern. (Hoffentlich stirbt Mailu dann nicht wieder)
U.a. weil Du dann nicht eine Website, die auf "domain.tld" hören soll, auf eine andere IP als den Mailserver legen könntest. Oder weil man ggfalls nicht domain.tld als rDNS Eintrag anlegen will. Oder oder oder.
Du hast unbegrenzt viele Subdomains. Also lieber eine eigene für den Mailserver verwenden.
Hast du bei Cloudflare rein zufällig die orange Wolke an beim MX Record (sofern überhaupt möglich)? Weil dann ist‘s klar das das nicht geht, da Cloudflare MX nicht durchleiten kann.
Das geht bei MX Records nicht, aber beim A Record muss es natürlich aus sein (s.o.).
Jop. E-Mail landete nur im Spam, weil ich einfach nur "test" im Betreff hatte und es dadurch von Gmail aussortiert wurde.
Im Volltext der Spam Mail steht drin, wieso es aussortiert wurde. Im Web-Gmailclient die drei Punkte bei der Mail und "Original anzeigen"
Da ist noch einiges bei Dir im Argen, imho hast Du Dich vorher nicht ausreichend mit der Erstellung eines Mailservers inklusive allem drum herum beschäftigt. Daher knirschts jetzt noch an Stellen, die Du mangels Kenntnis (noch) nicht identifiziert hast.
rDNS habe ich nun im SCP geändert. Ja, TTL habe ich auf "Auto", habs mit TLS verwechselt (lol). Ich setze die die TTL mal auf 2min vom MX Record. Wie lang soll ich es dabei belassen?
Eigentlich bringt das aktuell eher wenig, das hätte deutlich vor der Umstellung passieren sollen. Denn die Caches der Internet Provider schauen da evtl erst wieder deutlich später drauf.
Der MX Record pointed aber auch einfach auf die gleiche Domain, da der Mail-Server darauf läuft. Also user@domain.com -> Mailserver domain.com, nicht mail.domain.com oder sowas.
Das ist eine schlechte Idee, nimm mail.domain.tld
Zudem gilt (ich bin mir nicht sicher ob das bei Dir passt:
Typ Name Inhalt Proxy Status TTL
A mail 123.123.123.123 Nur DNS 2 Min. (IP des Servers auf dem der Mailserver unterwegs ist, also die IP deines VServers / RS)
MX domain.tld mail.domain.tld Nur DNS 2 Min.
Ist denn Cloudflare auch wirklich der DNS Server Deiner Domain? Das kannst Du im Whois Deiner TLD nachsehen.
Naja, die Mail sollte trotz rDNS Eintrag ankommen, aber es wundert dann nicht, dass sie bei Gmail erst mal im Spam gelandet ist.
Es gibt hier mehrere andere Threads, die sich mit Mails an T-Online und Microsoft beschäftigen. Bei T-Online brauchst Du eine manuelle Freischaltung, sonst kommt da nichts an und dazu wiederum ein Impressum mit vollständiger Adresse auf einer Seite, die der Maildomain zuzuordnen ist.
Bei MS wird man ggffalls eher einen externen SMTP Relay benötigen, da steht Netcup einfach zu häufig auf der Blocklist.
Den rDNS muss der Eigentümer der IP setzen, also Netcup. Geh zu Deinem Server im Servercontrolpanel unter Netzwerk und setz den rDNS.
TTL "aktiviert" gibts nicht. Vermutlich hast Du sie auf "auto" gesetzt. Wenn Du willst, dass sie asap durchs Internet propagiert, setzt Du sie auf 2 Min. Wie lange ist sie gesetzt? Btw. nicht vergessen, sie nach Fertigstellung aller Konfigs wieder zurück zu stellen auf einen sinnvolleren Wert.
Nochmal: Wann hast du die DNS Einträge gesetzt? Und SMTP hat mit dem Eingang nichts zu tun. Das mal vorweg
Und wie ist die TTL (Time to Live) des MX bzw. zugehörigen A Records gesetzt? Wenn die auf nen halben Tag eingestellt ist, braucht man sich nicht wundern, wenns gleich nach einer Änderung noch nicht geht.
Wie siehts mit dem rDNS Eintrag auf der IP aus? Wenn der nicht passt, ist der Rest fast irrelevant.
Dann ist vermutlich der SMTP Port nicht aus dem Container rausgelegt oder evtl war auf der Kiste auch vorher schon ein Mailserver drauf, der den Port blockiert.
netstat ( netstat(8) — net-tools — Debian bullseye — Debian Manpages ) und
docker ps -a
Sehr cool. Damit wird Tail-/Headscale wieder sehr interessant. Danke für die Hinweise.
Wenn der Mailserver korrekt konfiguriert wäre, würde ich vermuten, dass der MX noch nicht überall geändert / propagiert ist.
Unverzichtbares Tool zur Mailkonfiganalyse: Network Tools: DNS,IP,Email (mxtoolbox.com)
wobei es da kürzlich auch Verbesserungen gab: https://tailscale.com/blog/throughput-improvements/
Oh, danke! Sehr interessant! Da haben sie ja wirklich enorm was rausgeholt und Kernel WG sogar überholt (bis Wireguard das auch einbaut). Dann ist Headscale seeeehr viel interessanter.
Weißt Du evtl, ob die originalen mobilen Apps auch mit einem Headscale Server arbeiten?
Eure Vorschläge habe ich mir angesehen aber ich glaube soviel brauche ich garnicht.
Das ist bei allen Lösungen gar nicht viel. ZT, Netbird bieten Controller vom Hersteller, bei denen man sich nur nen Account machen muss. Dann installiert man auf allen Rechnern die Software (ist bei Wireguard auch nötig) und verbindet sich. Eine solche Verwaltung von mehreren Personen ist bei den genannten Diensten deutlich einfacher, bei Netbird kann man auch Zugriff mit "Verfallsdatum" konfigurieren. Auch wenn Dus hierfür nicht brauchst, kann ich nur empfehlen sich das mal anzusehen. Damit kann man so viele Probleme erschlagen.
Für den Einsatzzweck würde ich aber in der Tat auch eher eine andere Lösung empfehlen. Nebenbei könnten auch Synclösungen wie https://syncthing.net/ hier in Frage kommen, da brauchts dann gar kein VPN.
Tailscale gäb‘s auch noch, bin damit sehr zufrieden.
Kleine Ergänzung hierzu: da Tailscale Wireguard im Userspace realisiert, kann es nicht von der Kernelimplementation profitieren (Netmaker und Netbird können das schon). Es gibt Tests, die zeigen, dass Tailscale hinsichtlich Geschwindigkeit bei allen genannten VPN Lösungen eher das Schlußlicht darstellt. Als Vorteil wird bei dieser Implementation genannt, dass Tailscale auf mehr Plattformen als WG möglich ist.
Wenn die Verbindung nur für die Fernverwaltung verwendet wird, ist all das natürlich irrelevant. Wenn darüber Transfers laufen, kann es schon Sinn machen, sich die performanteste Lösung rauszusuchen. Anscheinend sind das aktuell die Kernel-Wireguard Implementationen von Wireguard (itself), Netmaker und Netbird. Meiner Erfahrung nach sind die beiden Net... auch schneller als Zerotier, allerdings nicht um viel (ZT: ca 50 Mbytes/s, Net...: ca 60 Mbytes/s).
Yep. Hab ich bei meinem Kerio Mailserver selektiv auch so gemacht - praktischerweise in der GUI. Ich verwende den kostenfreien Tier von https://de.sendinblue.com/ , da gibts noch 100 kostenfreie Mails pro Tag mehr (insgesamt 300).
