backup MX 'e

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

backup MX 'e

stefanf
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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

stefanf
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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Jan Kesten-3
In reply to this post by stefanf
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 (284 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

stefanf
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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Marc Ch. Demierre
In reply to this post by Jan Kesten-3

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
*@irgendeinedomain.ch 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 [hidden email]
mit dem Subject "unsubscribe". Probleme? Mail an [hidden email] (engl)

Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Jan Kesten-3
In reply to this post by stefanf
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 (284 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Jan Kesten-3
In reply to this post by Marc Ch. Demierre
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 (284 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

stefanf
In reply to this post by Jan Kesten-3
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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Frank Evers-2
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

Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

stefanf
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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Jutta Wrage
In reply to this post by stefanf
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

stefanf
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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Jan Kesten-3
In reply to this post by stefanf
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
[hidden email] 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 (284 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Sven Hartge-5
In reply to this post by Jan Kesten-3
Jan Kesten <[hidden email]> 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.



--
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 [hidden email]
mit dem Subject "unsubscribe". Probleme? Mail an [hidden email] (engl)

Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Jan Kesten-3
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 (284 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Sven Hartge-5
Jan Kesten <[hidden email]> 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.



--
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 [hidden email]
mit dem Subject "unsubscribe". Probleme? Mail an [hidden email] (engl)

Reply | Threaded
Open this post in threaded view
|

Re: backup MX 'e

Christian Schmidt-2
In reply to this post by stefanf
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 (196 bytes) Download Attachment