Re: backup MX 'e
Hallo stefan, stefan, 08.04.2006 (d.m.y): > Am Samstag, 8. April 2006 16:48 schrieb Jan Kesten: > > > > Alternative ist, alles incl. User-Check zustellen zulassen und manuell > > einen Transfer zu bauen wenn der MX wieder online ist. > > Okay, Wie läuft das dann, wenn ich den Server nicht unter Kontrolle hab? Muss > ich dann dem Mailadmin dort user credentials übermitteln? Eine Variante waere, dem Secondary MX eine Art "Whitelist" zur Verfuegung zu stellen. In dieser Whitelist fuehrst Du beispielsweise alle auf Deinem Haupt-Mailserver existierenden Adressen auf. Der Secondary MX kann dann vor Annahme einer Mail diese Whitelist konsultieren und die Mail dann je nach Ergebnis annehmen oder ablehnen. Ihr muesstet das dann zum einen auf dem Secondary MX einrichten und zum anderen fuer eine regelmaessige Aktualisierung der Whitelist sorgen. Gruss, Christian Schmidt -- An Kindern gefällt mir der Produktionsprozeß am besten. -- Zarko Petan signature.asc Description: Digital signature
Re: backup MX 'e
Jan Kesten <[EMAIL PROTECTED]> wrote: > Sven Hartge schrieb: >> Userverwaltung via LDAP oder MySQL oder durch eine andere >> Datenbank-Methode (pam-userdb?), welche auf dem Backup-MX synchron >> gehalten wird, so daß dieser dann Zugriff auf die gültigen Localparts >> hat. > Die Idee hatte ich auch (jetzt wo ich vor einigen Tagen meinen exim > 'virtuell' gemacht hab). Bin noch am verstehen von exim an diesem > Punkt, ob und wie er als Relay auch prüfen kann. Du musst entsprechende ACLs haben, die eine Mail nur dann zulassen, wenn die Domain eine ist, für die er relayen soll und der localpart in deiner Datenbank zu dieser relay_to_domain vorkommt. S° -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://www.svenhartge.de/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: backup MX 'e
Sven Hartge schrieb: > Userverwaltung via LDAP oder MySQL oder durch eine andere > Datenbank-Methode (pam-userdb?), welche auf dem Backup-MX synchron > gehalten wird, so daß dieser dann Zugriff auf die gültigen Localparts > hat. Die Idee hatte ich auch (jetzt wo ich vor einigen Tagen meinen exim 'virtuell' gemacht hab). Bin noch am verstehen von exim an diesem Punkt, ob und wie er als Relay auch prüfen kann. Wenn ich den Backup-MX einfach die Mails akzeptieren lassen würde dann hab ich ja kein Problem, ab mit der Domain in die local_domains und gut. Nur dann sind die Mails ja zugestellt (und ich muss sie wieder einsammeln, was ich auch schon gemacht hab - nur das bekommt halt keinen Schönheitspreis). Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: backup MX 'e
Jan Kesten <[EMAIL PROTECTED]> wrote: > Was ich immer noch suche ist eine einfache Lösung, so dass der Backup-MX > auch die localparts prüfen kann. Userverwaltung via LDAP oder MySQL oder durch eine andere Datenbank-Methode (pam-userdb?), welche auf dem Backup-MX synchron gehalten wird, so daß dieser dann Zugriff auf die gültigen Localparts hat. S° -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://www.svenhartge.de/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: backup MX 'e
Hallo, Stefan :-) > okay, bis hierhin kann ich folgen, aber dass würde ja bedeuten das > jeder backup MX auch ein open- relay darstellt. Das kann doch nicht > sein?! Also der Backup-MX ist ein Relay für deine Domain und dort ein offenes in Bezug auf alle localparts deiner Domain, d.h. alles was [EMAIL PROTECTED] als Empfänger hat, wird angenommen. > Auch hier muss es ja einen Schutz geben. Oder muss ich das so verstehen, > dass der Backup MX nur für die domains für die er zuständig ist die > mails zwischenspeichert, dann aber nur an mx1 relayed also dann auch > kein versenden über mx2 funktioniert? Genau so, der Backup-MX sammelt alles ein was er in die Finger bekommt, da er keinen Zugriff auf deine Benutzerdatenbank hat, kann er auch nicht weiter prüfen. Er ist aber nur ein Relay, d.h. er packt alles in seinen Spool und muss sie dann an den normalen MX zustellen sobald dieser wieder erreichbar ist. Problem mit den Spammern ist nun folgendes: Dein normaler MX prüft die localparts ob sie auch wirklich vorhanden sind und weist bei nicht vorhandenen Mails die Einlieferung ab. Nicht so der Backup-MX der erstmal alles annimmt. Was ein Spammer nun tut ist, er schickt seinen Müll mit Millionen von verschiedenen localparts an den Backup-MX, der ihn nicht abweist und die Mail annimmt. Will nun der Backup-MX die Mail an den normalen MX weiterreichen und er stellt fest, dass dieser ihn wegen eines falschen localparts abweist (no such user, relaying denied), dann generiert er eine Mail an den Absender, das die Zustellung fehlgeschlagen ist. Die landen dann aber bei dem unglücklichen, dessen Mailadresse misbraucht wurde. An der Stelle bastele ich noch, so dass man exim vielleicht beibringen kann als Relay die Mails anzunehmen (wo mein Backup-MX schon etwas unter meiner Kontrolle sein sollte) und sie dort ebenfalls abweist, wenn der Localpart ungültig ist. Abhilfe ist ein catchall nach /dev/null oder eine Skript-Lösung mittels fetchmail vom Backup-MX etc. Aber das hat halt leider den Nachteil, dass auch Unzustellbarkeitsmails die ich eventuell ja haben will weil sich ein echter Nutzer vertippt hat ebenfalls im Nirvana landen. > Na gut , mann muss ja nicht zwangsläufig NFS verwenden. drbd sollte > eigentlich reichen Hatte damals auch daran gedacht einen IMAP zu implementieren, der seine Mails in einer Datenbank hält, die repliziert wird (ala DBBalancer). Nur ein vollständiges IMAP ist schon ein größeres Projekt.. > Wär ein schönes Projekt!!! Also 2 MAilcluster mit drbd, je einer auf > einer seite und datensynchronisation per VPN. NA, wer hat Lust? Ja :-) Das ganze müsste nur auch hinreichend performant sein, wenns zwei Rechner sind würde ja auch ein einfacher Tunnel reichen. Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: backup MX 'e
Am Samstag, 8. April 2006 21:52 schrieb Jutta Wrage: > Am 08.04.2006 um 21:23 schrieb stefan: > > backup MX auch ein open- relay darstellt. Das kann doch nicht > > sein?! Auch > > Die Definition eines offenen Relays sagt, daß es Mail für Domains > annimmt, für die es nicht zuständig ist. Wenn Mail für alle User, > egal, ob sie existieren (für UUCP-Domains läuft das meist so) einer > Domain angenommen wird und ein MX auf den Rechner zeigt, dann ist das > zwar Relaying, ober kein _offenes_ Relay. naja, also das ist zwar schon richtig, aber wenn ein relaying für eine komplette domain möglich ist und nichts überprüft wird dann ist das auch ein open relay. Wenn ich mich recht entsinne wird das auch abgeprüft: http://www.abuse.net/relay.html Gruß stefan pgp1G6T64CVXt.pgp Description: PGP signature
Re: backup MX 'e
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.04.2006 um 21:23 schrieb stefan: backup MX auch ein open- relay darstellt. Das kann doch nicht sein?! Auch Die Definition eines offenen Relays sagt, daß es Mail für Domains annimmt, für die es nicht zuständig ist. Wenn Mail für alle User, egal, ob sie existieren (für UUCP-Domains läuft das meist so) einer Domain angenommen wird und ein MX auf den Rechner zeigt, dann ist das zwar Relaying, ober kein _offenes_ Relay. Gruß Jutta - -- http://www.witch.westfalen.de http://witch.muensterland.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iEYEARECAAYFAkQ4FIUACgkQOgZ5N97kHkceqACgsKnlYiOZC65/DXHapJqUt6cC omIAoMgCC9ermREx+Iy8WkrIGHQtXPez =qKu7 -END PGP SIGNATURE-
Re: backup MX 'e
Am Samstag, 8. April 2006 21:35 schrieb Frank Evers: > Am Samstag, 8. April 2006 21:23 schrieb stefan: > > okay, bis hierhin kann ich folgen, aber dass würde ja bedeuten das > > jeder backup MX auch ein open- relay darstellt. Das kann doch nicht > > sein?! Auch hier muss es ja einen Schutz geben. Oder muss ich das > > so verstehen, dass der Backup MX nur für die domains für die er > > zuständig ist die mails zwischenspeichert, dann aber nur an mx1 > > relayed also dann auch kein versenden über mx2 funktioniert? > > genau. Dennoch wird dein mx1 Fehlermeldungen für alle nicht > existierenden Nutzerkennungen (local part) an die Versender schicken. > Da die Versender aber gefälscht sind, meist aber echte (unschuldige) > Addressaten darstellen kriegen die deine Fehlermeldungen ohne jemals > was gesendet zu haben. aha, verstehe. Was oder wie sollte man dann den BAckup MX einrichten? Ist es tatsächlich möglich das per user zu machen? Wobei mir aber nicht klar ist, wie das abgeglichen oder gesynced werden kann. Oder gibt es eine bessere Lösung? tia stefan pgpFVjTReOIn2.pgp Description: PGP signature
Re: backup MX 'e
Am Samstag, 8. April 2006 21:23 schrieb stefan: > okay, bis hierhin kann ich folgen, aber dass würde ja bedeuten das > jeder backup MX auch ein open- relay darstellt. Das kann doch nicht > sein?! Auch hier muss es ja einen Schutz geben. Oder muss ich das > so verstehen, dass der Backup MX nur für die domains für die er > zuständig ist die mails zwischenspeichert, dann aber nur an mx1 > relayed also dann auch kein versenden über mx2 funktioniert? genau. Dennoch wird dein mx1 Fehlermeldungen für alle nicht existierenden Nutzerkennungen (local part) an die Versender schicken. Da die Versender aber gefälscht sind, meist aber echte (unschuldige) Addressaten darstellen kriegen die deine Fehlermeldungen ohne jemals was gesendet zu haben. -- Gruß Frank
Re: backup MX 'e
Am Samstag, 8. April 2006 19:58 schrieb Jan Kesten: > Hallo, Stefan! > > > Okay, Wie läuft das dann, wenn ich den Server nicht unter Kontrolle > > hab? Muss ich dann dem Mailadmin dort user credentials übermitteln? > > Oder mailserver2 synchronisiert die User wenn mailserver1 wieder > > online? Wie geht das rein technisch vonstatten? > > Ich habe mich bisher davor immer gehütet. Technisch müsste das so laufen: > > - jemand schickt dir eine Mail über seinen MTA > - der MTA des Absenders holt sich die MX-Einträge vom DNS > - probiert den mit der höchsten Priorität aus > - das schlägt fehl, so sollte der nächste probiert werden > - der Backup MX erlaubt Relaying für deine Domain, also > nimmt er die Mail ohne weitere Prüfung an und versucht sie > seinerseits zuzustellen okay, bis hierhin kann ich folgen, aber dass würde ja bedeuten das jeder backup MX auch ein open- relay darstellt. Das kann doch nicht sein?! Auch hier muss es ja einen Schutz geben. Oder muss ich das so verstehen, dass der Backup MX nur für die domains für die er zuständig ist die mails zwischenspeichert, dann aber nur an mx1 relayed also dann auch kein versenden über mx2 funktioniert? > - dein primärer MTA läuft nicht und an sich selbst wird > nicht zugestellt (wäre eine Loop) > - sobald der primäre MTA wieder da ist, sollten beim Queue-Run > die Mails vom Backup an den primären MX zugestellt werden > > Also synchronisieren in der Form eigentlich nicht. Weil die Mails werden > zwar angenommen, aber der User bei Dir hat in dem Moment noch keinen > Zugriff (weil die Mail noch beim Backup MX liegt). > > Das Problem ist folgendes, wenn der Backup MX nur anhand der Domain das > Relay überprüft, kann man Mails an alle localparts der Domain absetzen. > Dein primärer MTA würde diese jedoch gleich als unroutable zurückweisen > (mein exim macht das zumindest). Problem ist nun folgendes, hat ein > Spammer angefangen alle localparts zu beliefern landen die alle im > Spool. Und wenn sie dann zu gestellt werden bekommt der Spammer tausende > von "Mailer-Daemon-Mails" - da er aber nie seine eigene Adresse nimmt, > kann das sehr ärgerlich sein. > > Was ich immer noch suche ist eine einfache Lösung, so dass der Backup-MX > auch die localparts prüfen kann. > > > Hmm auch gut, Was gibt es da für Szenarien? Ausser einem Mail- > > CLuster und reduntante Anbindung fällt mir da nichts ein. > > Ideen hab ich da genug - einfach ist nichts davon. Eine Idee sind zwei > redundante Mailserver, ein zentraler Mailstore und drdb. Hat nur einen > Haken, die meisten Mailsysteme vertragen kein NFS. Na gut , mann muss ja nicht zwangsläufig NFS verwenden. drbd sollte eigentlich reichen > Das hängt auch vom > Anwendungsfall ab, was man genau mit welchem Aufwand erreichen will. > > Wenn mal wieder die totale Langeweile durchkommt wollte ich immer > schonmal 'meinen IMAP' Server haben der als Mailspool eine Datenbank > verwendet und online replizieren kann. Tja , dass würd ich auch gern mal machen, also ein Grid. Leider findet sich da keiner der das mal mitmacht. Einen Cluster mit drbd hab ich schonmal aufgesetzt, wer Lust hat kann ja mal bescheid geben. Wär ein schönes Projekt!!! Also 2 MAilcluster mit drbd, je einer auf einer seite und datensynchronisation per VPN. NA, wer hat Lust? bis dann stefan pgpENINhH6BF4.pgp Description: PGP signature
Re: backup MX 'e
Marc Ch. Demierre schrieb: > Eine einfache Variante kenne ich leider auch nicht, *g* > koenntest Du was mit Fetchmail & einem Shell Script machen? Vor einer > Weile haben wir auf diese Art und Weise ca 4GB Mail per Script gemoved..? Sicher das ist kein Thema - hatte auch einfach mal einen catchall account auf eine Domain gesetzt und alles in eine mbox bzw. ein maildir zustellen lassen. Wenn alles wieder online war, dann per Skript die Mailbox nehmen und die Mails wieder in den primären MX einfüttern. Aufwand damals ein paar Stunden fürs Programmieren und dann halt die Zeit für's manuelle Anwerfen des ganzen Krams (hatte den Vorteil, dass der Absender eine Mail bekam, dass seine Mail verspätet zugestellt werden wird). Nur das ist halt relativ 'dumm' und man bekommt schnell eine Menge Müll zusammen. Ausserdem ist das ja nicht ein Backup-MX im eigentlichen Sinne. Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: backup MX 'e
Hallo, Stefan! > Okay, Wie läuft das dann, wenn ich den Server nicht unter Kontrolle > hab? Muss ich dann dem Mailadmin dort user credentials übermitteln? > Oder mailserver2 synchronisiert die User wenn mailserver1 wieder > online? Wie geht das rein technisch vonstatten? Ich habe mich bisher davor immer gehütet. Technisch müsste das so laufen: - jemand schickt dir eine Mail über seinen MTA - der MTA des Absenders holt sich die MX-Einträge vom DNS - probiert den mit der höchsten Priorität aus - das schlägt fehl, so sollte der nächste probiert werden - der Backup MX erlaubt Relaying für deine Domain, also nimmt er die Mail ohne weitere Prüfung an und versucht sie seinerseits zuzustellen - dein primärer MTA läuft nicht und an sich selbst wird nicht zugestellt (wäre eine Loop) - sobald der primäre MTA wieder da ist, sollten beim Queue-Run die Mails vom Backup an den primären MX zugestellt werden Also synchronisieren in der Form eigentlich nicht. Weil die Mails werden zwar angenommen, aber der User bei Dir hat in dem Moment noch keinen Zugriff (weil die Mail noch beim Backup MX liegt). Das Problem ist folgendes, wenn der Backup MX nur anhand der Domain das Relay überprüft, kann man Mails an alle localparts der Domain absetzen. Dein primärer MTA würde diese jedoch gleich als unroutable zurückweisen (mein exim macht das zumindest). Problem ist nun folgendes, hat ein Spammer angefangen alle localparts zu beliefern landen die alle im Spool. Und wenn sie dann zu gestellt werden bekommt der Spammer tausende von "Mailer-Daemon-Mails" - da er aber nie seine eigene Adresse nimmt, kann das sehr ärgerlich sein. Was ich immer noch suche ist eine einfache Lösung, so dass der Backup-MX auch die localparts prüfen kann. > Hmm auch gut, Was gibt es da für Szenarien? Ausser einem Mail- > CLuster und reduntante Anbindung fällt mir da nichts ein. Ideen hab ich da genug - einfach ist nichts davon. Eine Idee sind zwei redundante Mailserver, ein zentraler Mailstore und drdb. Hat nur einen Haken, die meisten Mailsysteme vertragen kein NFS. Das hängt auch vom Anwendungsfall ab, was man genau mit welchem Aufwand erreichen will. Wenn mal wieder die totale Langeweile durchkommt wollte ich immer schonmal 'meinen IMAP' Server haben der als Mailspool eine Datenbank verwendet und online replizieren kann. Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: backup MX 'e
Hallo Stefan >> Wenn nun auf dem 2 Server die mails eintrudeln, wie gelangen die dann >> zum client? Wird dann synchronisiert wenn mailserver1 wieder online >> ist? Wie funktioniert das? Eine einfache Variante kenne ich leider auch nicht, aber hast ggf. koenntest Du was mit Fetchmail & einem Shell Script machen? Vor einer Weile haben wir auf diese Art und Weise ca 4GB Mail per Script gemoved..? Der Vorteil von Fetchmail ist klar, dass Du jede Mail Box einzeln handlen kannst, dafuer den Aufwand auf der User Verwaltungsseite eindeutig erhoeht... Denkbar waere ja auch auf dem sekundaeren MX alles zu empfangen [EMAIL PROTECTED] und den Input dann per Fetchmail zu verteilen... nur mal laut vor mich hingedacht .-) Gruss. Marc -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: backup MX 'e
Am Samstag, 8. April 2006 16:48 schrieb Jan Kesten: > stefan schrieb: > > Wenn ich nun einen 2. MAilserver im DNS mit einer höheren Priorität > > eintrage dann landen ja alle Mails auf einem zweiten Mailsystems, > > wenn mailserver1 mit niedrieger Prio ausfällt. DH. wenn ich backup MX > > nutzen will brauch ich auch dort einen 2. Mailserver, Richtig? > > Exakt. > > > Wenn nun auf dem 2 Server die mails eintrudeln, wie gelangen die dann > > zum client? Wird dann synchronisiert wenn mailserver1 wieder online > > ist? Wie funktioniert das? > > Die einfachste Variante ist, dem Backup-Server im Falle von exim (und > sicher jedem anderen MTA auch), als Option > > relay_to_domains = primary.domain.tld > > mitzugeben. Aber Vorsicht, das nimmt alle Mails für die Domain entgegen > und wird von Spammern gerne genutzt. unschön, Und man is wahrscheinlich auch gleich blacklistet. Also keine gute Lösung. > Da braucht es dann entweder ein > dickes Fell oder auf dem Backup-MX entsprechende Test. Die Mails sollten > dann nachdem der echte MX wieder da ist automatisch zugestellt werden. > > Alternative ist, alles incl. User-Check zustellen zulassen und manuell > einen Transfer zu bauen wenn der MX wieder online ist. Okay, Wie läuft das dann, wenn ich den Server nicht unter Kontrolle hab? Muss ich dann dem Mailadmin dort user credentials übermitteln? Oder mailserver2 synchronisiert die User wenn mailserver1 wieder online? Wie geht das rein technisch vonstatten? Gibt es da ein ein entsprechendes Stichwort nach dem ich suchen kann? > Willst Du hingegen, dass dir ruhig ein Server ausfallen kann und alle > User mit SMTP und POP/IMAP weiterarbeiten können, ist etwas mehr Aufwand > nötig. Hmm auch gut, Was gibt es da für Szenarien? Ausser einem Mail- CLuster und reduntante Anbindung fällt mir da nichts ein. tia stefan pgpWGc8mCyLgM.pgp Description: PGP signature
Re: backup MX 'e
stefan schrieb: > Wenn ich nun einen 2. MAilserver im DNS mit einer höheren Priorität > eintrage dann landen ja alle Mails auf einem zweiten Mailsystems, > wenn mailserver1 mit niedrieger Prio ausfällt. DH. wenn ich backup MX > nutzen will brauch ich auch dort einen 2. Mailserver, Richtig? Exakt. > Wenn nun auf dem 2 Server die mails eintrudeln, wie gelangen die dann > zum client? Wird dann synchronisiert wenn mailserver1 wieder online > ist? Wie funktioniert das? Die einfachste Variante ist, dem Backup-Server im Falle von exim (und sicher jedem anderen MTA auch), als Option relay_to_domains = primary.domain.tld mitzugeben. Aber Vorsicht, das nimmt alle Mails für die Domain entgegen und wird von Spammern gerne genutzt. Da braucht es dann entweder ein dickes Fell oder auf dem Backup-MX entsprechende Test. Die Mails sollten dann nachdem der echte MX wieder da ist automatisch zugestellt werden. Alternative ist, alles incl. User-Check zustellen zulassen und manuell einen Transfer zu bauen wenn der MX wieder online ist. Willst Du hingegen, dass dir ruhig ein Server ausfallen kann und alle User mit SMTP und POP/IMAP weiterarbeiten können, ist etwas mehr Aufwand nötig. Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: backup MX 'e
Am Samstag, 8. April 2006 15:49 schrieb stefan: > Hallo zusammen, > ich hab da mal ne Verständnisfrage zu BAckup MXen. > Wenn ich nun einen 2. MAilserver im DNS mit einer höheren Priorität > eintrage dann landen ja alle Mails auf einem zweiten Mailsystems, wenn > mailserver1 mit niedrieger Prio ausfällt. DH. wenn ich backup MX nutzen > will brauch ich auch dort einen 2. Mailserver, Richtig? > Wenn nun auf dem 2 Server die mails eintrudeln, wie gelangen die dann zum > client? Wird dann synchronisiert wenn mailserver1 wieder online ist? okay hab was gefunden: http://www.postfix.org/VIRTUAL_README.html > Wie funktioniert das? > Ist das dann auf dem 2 mailserver ein relayen der kompletten domain, wie > siehts hier mit den Usern aus? aber wie siehts mit den usern aus, wird einfach alles für die domain angenommen? > Ich hab hier zwar ein schlaues bind Buch und ich hab im Internet gestöbert, > konnte aber nichts brauchbares zu dem Thema finden. > > > Kanns jemand erklären oder ein paar gute links? > > tia > stefan pgp6mDgEYmLdn.pgp Description: PGP signature
backup MX 'e
Hallo zusammen, ich hab da mal ne Verständnisfrage zu BAckup MXen. Wenn ich nun einen 2. MAilserver im DNS mit einer höheren Priorität eintrage dann landen ja alle Mails auf einem zweiten Mailsystems, wenn mailserver1 mit niedrieger Prio ausfällt. DH. wenn ich backup MX nutzen will brauch ich auch dort einen 2. Mailserver, Richtig? Wenn nun auf dem 2 Server die mails eintrudeln, wie gelangen die dann zum client? Wird dann synchronisiert wenn mailserver1 wieder online ist? Wie funktioniert das? Ist das dann auf dem 2 mailserver ein relayen der kompletten domain, wie siehts hier mit den Usern aus? Ich hab hier zwar ein schlaues bind Buch und ich hab im Internet gestöbert, konnte aber nichts brauchbares zu dem Thema finden. Kanns jemand erklären oder ein paar gute links? tia stefan pgpiownsdtgju.pgp Description: PGP signature