Hallo Liste,
ich habe für ein paar meiner privaten Domains mailbox.org als Backup-MX eingetragen (Prio 90 vs. Prio 10). Leider landen immer wieder Mails bei Mailbox.org. Dass Spammer die weniger priorisierten MXer nutzen ist klar, aber es landen auch Mails z.B. der Denic, OVH, hetzner etc dort. Es sind zwar immer nur wenige, also 2-3 Mail pro Tag, aber trotzdem unschön. Muss man sich nicht laut RFC an die Prioritäten halten? Gibt es wege, wie man das Verhalten optimieren kann? Z.B. längeres Greylisting auf dem Backup-MXer? Eigentlich war der Plan, dass nur bei einer Störung die Mails zum Backup-Postfach kommen. Werden vielleicht teilweise die mta-sts-Einträge benutzt (die sind ja ohne Prio)?
VG Marc
Die Frage taucht immer wieder auf; aber Du weisst ja gar nicht, ob für den versendenden Server zum fraglichen Zeitpunkt Dein primärer MX a) erreichbar war (da kann es ja auch mal kurzzeitige Routingprobleme geben) und b) er die Mail nicht vielleicht aus irgend einem Grund (z.B Stress Mode) abgelehnt hat. Kurzer Sinn: Wenn man einen Backup MX publiziert, muss man damit rechnen, dass auf ihm auch Mails eingehen, deshalb sollten die beiden Systeme möglichst gleichwertig sein und weiterhin der Transport an die finale Destination in jedem Fall sichergestellt sein. Alles andere funktioniert nicht gut. Wenn Du Zugriff auf die TTL Deiner DNS-Zonen hast, könntest Du stattdessen nur einen Eintrag machen und den im Bedarfsfall ändern, das klappt aber halt nur bei kurzlebiger TTL für die MX Einträge oder die ganze Zone. Sowas kann man auch skripten, wenn der DNS Provider eine API anbietet (Mailserver 5 min nicht erreichbar => stelle auf Backup MX um).
Grüße, Jakob Curdes
On Fr, 15 Mär 2019 at 10:22:43 +0100, Jakob Curdes wrote:
Aloha,
Wenn Du Zugriff auf die TTL Deiner DNS-Zonen hast, könntest Du stattdessen nur einen Eintrag machen und den im Bedarfsfall ändern, das klappt aber halt nur bei kurzlebiger TTL für die MX Einträge oder die ganze Zone. Sowas kann man auch skripten, wenn der DNS Provider eine API anbietet (Mailserver 5 min nicht erreichbar => stelle auf Backup MX um).
das funktioniert aber je nach TTL auch nicht zuverlässig, weil da draussen eine Menge nameserver TTLs nicht korrekt beachten, zum Beispiel alles unter 60 Sekunden schlicht ignorieren.
Dann kommt es noch drauf an, ob der DNS-Provider die Änderungen auch schnell übernimmt und wie er ragiert wenn man die Änderung mehrmals hintereinander macht.
Grüße, Florian
Am 15.03.2019 um 10:33 schrieb Florian Streibelt:
On Fr, 15 Mär 2019 at 10:22:43 +0100, Jakob Curdes wrote:
Aloha,
Wenn Du Zugriff auf die TTL Deiner DNS-Zonen hast, könntest Du stattdessen nur einen Eintrag machen und den im Bedarfsfall ändern, das klappt aber halt nur bei kurzlebiger TTL für die MX Einträge oder die ganze Zone. Sowas kann man auch skripten, wenn der DNS Provider eine API anbietet (Mailserver 5 min nicht erreichbar => stelle auf Backup MX um).
das funktioniert aber je nach TTL auch nicht zuverlässig, weil da draussen eine Menge nameserver TTLs nicht korrekt beachten, zum Beispiel alles unter 60 Sekunden schlicht ignorieren.
Dann kommt es noch drauf an, ob der DNS-Provider die Änderungen auch schnell übernimmt und wie er ragiert wenn man die Änderung mehrmals hintereinander macht.
Von 60s würde ich auch bei einer privaten Domain nicht ausgehen. Wenn es um die Zeitskalen geht, braucht man eh mindestens 2 MX. 600s oder auch 1800s wird aber meist problemlos möglich sein. Ich kenne die Behauptung, dass manche Nameserver kurze TTLs nicht beachten, kann das aber aus eigener Erfahrung mit Mailmigrationen nicht bestätigen (außer bei Systemen, die Spam ausliefern). Und die Nutzer hinter einen solchen Server haben dann halt Pech gehabt bzw. ihre Mail kommt erst an wenn der primäre MX wieder da ist. Wir betreiben solche Lösungen operationell für Kunden mit DNSMadeEasy, Hetzner z.B. hat aber auch eine gute API für sowas.
JC
Hi Jakob, hi Marc, hi,
Jakob Curdes - 15.03.19, 10:22:
Die Frage taucht immer wieder auf; aber Du weisst ja gar nicht, ob für den versendenden Server zum fraglichen Zeitpunkt Dein primärer MX a) erreichbar war (da kann es ja auch mal kurzzeitige Routingprobleme geben) und b) er die Mail nicht vielleicht aus irgend einem Grund (z.B Stress Mode) abgelehnt hat. Kurzer Sinn: Wenn man einen Backup MX publiziert, muss man damit rechnen, dass auf ihm auch Mails eingehen, deshalb sollten die beiden Systeme möglichst gleichwertig sein und weiterhin der Transport an die finale Destination in jedem Fall sichergestellt sein. Alles andere funktioniert nicht gut. Wenn Du Zugriff auf die TTL Deiner DNS-Zonen hast, könntest Du stattdessen nur einen Eintrag machen und den im Bedarfsfall ändern, das klappt aber halt nur bei kurzlebiger TTL für die MX Einträge oder die ganze Zone. Sowas kann man auch skripten, wenn der DNS Provider eine API anbietet (Mailserver 5 min nicht erreichbar => stelle auf Backup MX um).
Das ist interessant, da ich bei einem Mailserver-Umzug auch darüber nachgedacht habe, einen Backup MX zu verwenden, um dann den primären Mailserver einfach mal stoppen zu können, um zu sehen, inwiefern das funktioniert.
Naja, da ich das erst mache, wenn der zweite Mail-Server weitgehend identisch zum ersten eingerichtet ist, und dann auch Dovecot drauf läuft, komme ich ja in jedem Fall an die Mails dran. Es ist so oder so gut zu wissen. Danke für deine Zusammenfassung.
Ich hab bislang nie einen Backup-MX für meinen privaten Mailserver verwendet, da ich mir sagte: Naja, wenn das Ding mal kurzzeitig weg oder nicht erreichbar ist, dann versuchen es die anderen Mailserver eh erneut. Bis auf evtl. Spammer, aber entgangenen Spam-Mails weine ich keine Träne nach.
Ciao,
Am 15.03.2019 um 10:40 schrieb Martin Steigerwald:
Hi Jakob, hi Marc, hi,
Jakob Curdes - 15.03.19, 10:22:
Die Frage taucht immer wieder auf; aber Du weisst ja gar nicht, ob für den versendenden Server zum fraglichen Zeitpunkt Dein primärer MX a) erreichbar war (da kann es ja auch mal kurzzeitige Routingprobleme geben) und b) er die Mail nicht vielleicht aus irgend einem Grund (z.B Stress Mode) abgelehnt hat. Kurzer Sinn: Wenn man einen Backup MX publiziert, muss man damit rechnen, dass auf ihm auch Mails eingehen, deshalb sollten die beiden Systeme möglichst gleichwertig sein und weiterhin der Transport an die finale Destination in jedem Fall sichergestellt sein. Alles andere funktioniert nicht gut. Wenn Du Zugriff auf die TTL Deiner DNS-Zonen hast, könntest Du stattdessen nur einen Eintrag machen und den im Bedarfsfall ändern, das klappt aber halt nur bei kurzlebiger TTL für die MX Einträge oder die ganze Zone. Sowas kann man auch skripten, wenn der DNS Provider eine API anbietet (Mailserver 5 min nicht erreichbar => stelle auf Backup MX um).
Das ist interessant, da ich bei einem Mailserver-Umzug auch darüber nachgedacht habe, einen Backup MX zu verwenden, um dann den primären Mailserver einfach mal stoppen zu können, um zu sehen, inwiefern das funktioniert.
Naja, da ich das erst mache, wenn der zweite Mail-Server weitgehend identisch zum ersten eingerichtet ist, und dann auch Dovecot drauf läuft, komme ich ja in jedem Fall an die Mails dran. Es ist so oder so gut zu wissen. Danke für deine Zusammenfassung.
Ich hab bislang nie einen Backup-MX für meinen privaten Mailserver verwendet, da ich mir sagte: Naja, wenn das Ding mal kurzzeitig weg oder nicht erreichbar ist, dann versuchen es die anderen Mailserver eh erneut. Bis auf evtl. Spammer, aber entgangenen Spam-Mails weine ich keine Träne nach.
Wenn es nicht um einen Umzug, sondern um echtes Backup MX geht, würde ich das so machen, dass der Backup MX nur als reiner MX mit forwarding Regeln für alle Domains eingerichtet ist und die Mails einfach nur einsammelt und dann an den primären übergibt, wenn der wieder da ist. Man kann natürlich auch die dovecots mit dsync synchronisieren, das wird dann aber schon Arbeit, auch von der Überwachung her. JC
participants (4)
-
Florian Streibelt -
Jakob Curdes -
Marc Risse -
Martin Steigerwald