Backup MX -> Prio wird ignoriert

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Backup MX -> Prio wird ignoriert

Marc Risse
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


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Backup MX -> Prio wird ignoriert

Jakob Curdes
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



Reply | Threaded
Open this post in threaded view
|

Re: Backup MX -> Prio wird ignoriert

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.


Grüße,
  Florian
Reply | Threaded
Open this post in threaded view
|

Re: Backup MX -> Prio wird ignoriert

Martin Steigerwald
In reply to this post by Jakob Curdes
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,
--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Backup MX -> Prio wird ignoriert

Jakob Curdes
In reply to this post by Florian Streibelt

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
Reply | Threaded
Open this post in threaded view
|

Re: Backup MX -> Prio wird ignoriert

Jakob Curdes
In reply to this post by Martin Steigerwald

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