Sandy Drobic schrieb:
Stefan König wrote:
Hallo zusammen,
ich möchte einen postfix server als backup MX für eine Domain benutzen. Sprich, wenn der erste MX der Domain ausgefallen ist, soll Postfix alles annehmen und sobald der MX wieder da ist, alles ausliefern. Ich habe bereits etwas gegoogelt, bin mir aber nicht sicher ob das nun eine Art Relay oder vielmehr ein Proxy ist....
Vielleicht wäre es am besten, wenn du noch einmal genau überlegst, ob ein Backup-MX wirklich eine gute Idee ist. Im allgemeinen ist es kaum noch notwendig.
Wie funktioniert Backup-MX: ------------------------------------------
- die zuständigen Mailserver für eine Domain werden mit einer Priorität im DNS eingetragen. Ein normaler einliefernder Server versucht der Reihe nach, diese Server anzusprechen, angefangen mit dem MX mit der höchsten Priorität (der niedrigsten Zahl:
in MX 10 mail.example.com in MX 20 backup-mx.example.com
- Wenn ein Client eine Mail beim Backup-MX einliefert, nimmt dieser die Mail (sofern die Policy auf dem Backup-MX dies erlaubt) erst an. Er hat damit die Verantwortung für die Mail. Danach versucht er, die Mail gemäß den normalen Regeln (suche nach dem höchsten MX-Eintrag) an den ersten MX zuzustellen.
- Sobald der erste MX wieder online ist und der Backup-MX dies im Zuge seiner Zustellversuche merkt, werden die Mails an den primären MX zugestellt.
------------------------------------------
Soweit die Theorie, jetzt kommen wir zur Realität und zu "Best practise for Mailservers".
1. Ein Mailserver sollte nur die Mails annehmen, die er auch zustellen kann (sonst werden die Mails nur an den meist gefälschten Absender gebounced und landen als Backscatter bei genervten Dritten). Im Klartext: es dürfen keine Mails an ungültige Empfänger angenommen werden.
2. Die Abweisung von ungültigen Empfängern muss während des SMTP-Dialoges stattfinden in der RCPT TO Anweisung, später kann nicht mehr REJECTed werden, dann wird gebounced, und Bouncen ist böse.
3. Die Prüfungen, welche Emails angenommen und welche abgewiesen werden, müssen auf beiden Servern die gleichen sein. Eine Email, welche der Backup-MX angenommen hat, darf vom ersten MX nicht mehr abgewiesen werden, sonst haben wir wieder Backscatter: Bouncen ist böse.
Nur, wenn du alle drei Punkte erfüllen kannst, solltest du einen Backup-MX in Erwägung ziehen. PHBs verkünden oft, dass ein Backup-MX zur "Steigerung der Verfügbarkeit" Pflicht sei, aber in Wirklichkeit leidet die Qualität meistens, wenn ein Backup-MX eingeführt wird.
Bedenke immer, dass eine Mail auch von den externen einliefernden Servern solange gespeichert wird, bis der primäre (oder einzige MX) wieder online ist.
Erst, wenn die Downtime des Servers länger als ein Tag ist, gehen die ersten Mails als nicht zustellbar an den Absender zurück. Und auch dies ist gegen die RFCs, die verlangen, dass die Zustellung mehrere Tage versucht wird.
Danke für den Beitrag. Ich persönlich halte das ja auch für unnötig, da normalerweise bei Ausfall eines MX die Mail dann eben später zugestellt wird. Aber "da das schon immer so war, soll das jetzt auch zukünftig so gemacht werden!". Dass in der Q mal eben 30.000 bounce mails festhängen, interessiert da keinen. Wenn der Server neu gemacht wird, sind die ja weg ;) Natürlich sollen alle Einstellungen übernommen werden. Ahja. Nun denn, wir sind uns einig, das ist meist Unsinn, zumal die Haupt-MXe von Kunden betrieben werden und man auf deren Einstellungen keinen Zugriff hat. D.h. der Backup-MX muss erstmal allen Schrott annehmen. Was wieder zu einem SPAM/Bounce/etc Problem führt... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org