Discussion:
Backup-MX: Exim4 wie konfigurieren?
(zu alt für eine Antwort)
Mark Trulmann
2006-05-28 07:00:47 UTC
Permalink
Hallo..

Ich benutze einen Server mit Postfix als Mailserver.

Ich habe einen zweiten Server wo Exim4 als MTA drauf ist und möchte den
gerne als Backup-MX für den Mailserver laufen lassen.

Ich hänge mich leider gerade ein bischen bei der Konfiguration bei Exim4
auf. Hat da jemand vielleicht einschlägige Erfahrungen gemacht, die er
mir mitteilen könnte?

Oder ist sonst jemand da, der mir bischen Licht ans Fahrrad basteln
kann? ;-)

Ich sehe in den Konfi-Dateien gerade den Wald vor lauter Bäumen nicht.


Gruß

Mark
Ilja Weis
2006-05-28 10:59:26 UTC
Permalink
Moin,
Post by Mark Trulmann
Ich habe einen zweiten Server wo Exim4 als MTA drauf ist und möchte den
gerne als Backup-MX für den Mailserver laufen lassen.
Ich hänge mich leider gerade ein bischen bei der Konfiguration bei Exim4
auf. Hat da jemand vielleicht einschlägige Erfahrungen gemacht, die er
mir mitteilen könnte?
Oder ist sonst jemand da, der mir bischen Licht ans Fahrrad basteln
kann? ;-)
Dazu sollte es reichen, die Domain(s) in der "acl_smtp_rcpt" einzutragen:

accept domains = domain.tld

Da Spam gerne an Backup-MXe verschickt wird, können sich folgende
Parameter lohnen:

accept domains = domain.tld
verify = sender
verify = recipient/callout=10s,defer_ok,use_sender
message = ...
Ilja Weis
2006-05-28 11:13:08 UTC
Permalink
Post by Ilja Weis
accept domains = domain.tld
Ich vergass:

Die Beispiel-exim.conf hat dafür auch schon eine Domainliste
vorbereitet. Ganz am Anfang die "relay_to_domains". Einfach dort eintragen.
Christian H. Kuhn
2006-05-28 11:37:05 UTC
Permalink
Post by Ilja Weis
Die Beispiel-exim.conf hat dafür auch schon eine Domainliste
vorbereitet. Ganz am Anfang die "relay_to_domains". Einfach dort eintragen.
Weil ich wohl auch demnächst mit sowas rummachen muss, ein paar
Verständnisfragen:

Das geht schon damit los, dass ich nicht genau weiss, was ein Backup-MX
können muss. Rein theoretisch soll er ja den Haupt-MX ersetzen, wenn der
mal down ist. Dazu muss er Mails an die Domain annehmen und den Usern zum
Abholen bereitstellen. Wenn der Haupt-MX aber wieder da ist, gibt er die
Mails an den weiter.

Wenn ich aber die Posts in letzter Zeit zu Backup-MX durchschaue, sieht das
für mich so aus, als ob der Backup-MX die Mails nur annehmen und halten und
später an den Haupt-MX weiterleiten soll, ohne sie zwischendurch lokal
bereitzustellen. Damit wäre der Backup-MX nichts anderes als
ein "Smarthost" für diese Domain. Und damit überflüssig, weil er ja auch
nichts anderes macht wie der einliefernde Mailserver: Er hält die Mails,
bis der Haupt-MX sich wieder meldet, und liefert sie dann aus; geschiet das
nicht in einer bestimmten Zeit, werden sie mit Fehlermeldung
zurückgeschickt. Damit sehe ich keinen Zusatznutzen für den User durch den
Backup-MX.

Ein Einrichten und regelmäßiges Aktualisieren der kompletten Userliste incl.
Aliases dürfte aber ein u.U. gewaltiger Verwaltungsaufwand werden. Auch
sehe ich nicht, wie der Backup-MX automatisiert lokal bereits zugestellte
Mails woandershin weiterschicken könnte.

Damit bleibt für mich als einzig erkennbarer Nutzen eines Backup-MX ein
Einsatz in wirklich großen Mailinstallationen, in denen ein von aussen
erreichbarer Eingangs-MX Mails auf verschiedene MXe verteilt, die dann
entweder ihrerseits weiter verteilen oder lokal zustellen. Diese eine
zentrale Maschine kann natürlich einen Backup vertragen.

Hab ich da jetzt was übersehen?

mfg
Christian
--
Mehr als 90% aller Gewaltverbrechen geschehen innerhalb von 24 Stunden nach
dem
Konsumieren von Brot.....
Ilja Weis
2006-05-28 12:09:33 UTC
Permalink
Post by Christian H. Kuhn
Weil ich wohl auch demnächst mit sowas rummachen muss, ein paar
Das geht schon damit los, dass ich nicht genau weiss, was ein Backup-MX
können muss. Rein theoretisch soll er ja den Haupt-MX ersetzen, wenn der
mal down ist. Dazu muss er Mails an die Domain annehmen und den Usern zum
Abholen bereitstellen. Wenn der Haupt-MX aber wieder da ist, gibt er die
Mails an den weiter.
Nein, nur annehmen. Normalerweise können die User sich die Mails dort
nicht abholen. Kann man natürlich so konfigurieren, aber dann wird es
interessant, wenn der Hauptserver wieder erreichbar ist...
Post by Christian H. Kuhn
Wenn ich aber die Posts in letzter Zeit zu Backup-MX durchschaue, sieht das
für mich so aus, als ob der Backup-MX die Mails nur annehmen und halten und
später an den Haupt-MX weiterleiten soll, ohne sie zwischendurch lokal
bereitzustellen. Damit wäre der Backup-MX nichts anderes als
ein "Smarthost" für diese Domain. Und damit überflüssig, weil er ja auch
nichts anderes macht wie der einliefernde Mailserver: Er hält die Mails,
bis der Haupt-MX sich wieder meldet, und liefert sie dann aus; geschiet das
nicht in einer bestimmten Zeit, werden sie mit Fehlermeldung
zurückgeschickt. Damit sehe ich keinen Zusatznutzen für den User durch den
Backup-MX.
Genau. Die Mails werden nicht lokal an irgendwelche Mailboxen
ausgeliefert, sondern bleiben in der Queue auf dem Backup.
Post by Christian H. Kuhn
Ein Einrichten und regelmäßiges Aktualisieren der kompletten Userliste incl.
Aliases dürfte aber ein u.U. gewaltiger Verwaltungsaufwand werden. Auch
sehe ich nicht, wie der Backup-MX automatisiert lokal bereits zugestellte
Mails woandershin weiterschicken könnte.
Die Mails sollten nicht lokal ausgeliefert werden. Das ist auch nicht
wirklich nötig, der Backup sollte aber wenn möglich eine Liste der für
die Domain gültigen Adressen haben, weil er sonst alles annehmen muss
und dann Bounces erzeugt, wenn der Hauptserver nicht erreichbar war
und jemand an den Backup-MX Schrott geschickt hat. Erreichen kann man
das z.B. indem man regelmässig die Userlisten überträgt oder diese aus
einem (replizierten) LDAP liest.
Post by Christian H. Kuhn
Damit bleibt für mich als einzig erkennbarer Nutzen eines Backup-MX ein
Einsatz in wirklich großen Mailinstallationen, in denen ein von aussen
erreichbarer Eingangs-MX Mails auf verschiedene MXe verteilt, die dann
entweder ihrerseits weiter verteilen oder lokal zustellen. Diese eine
zentrale Maschine kann natürlich einen Backup vertragen.
Hab ich da jetzt was übersehen?
Eigentlich nicht. In einer normalen "Backup-MX-Konstruktion" sammelt
dieser dann nur die Mails ein, die sonst in den Queues der
versendenden Mailserver liegen würden. Der Vorteil ist dann, dass man
die Mails beim Ausfall des Hauptservers schnell "unter eigener
Kontrolle" hat (man kommt bei Bedarf notfalls an die Mails heran), und
man ist nicht abhängig von möglicherweise ungeschickten
Retry-Konfigurationen der Versender.

Ob sich man dafür den Aufwand machen will...
Christoph Kliemt
2006-05-28 12:11:03 UTC
Permalink
"Christian H. Kuhn" <***@qno.de> writes:

[...]
Weil ich wohl auch demnächst mit sowas rummachen muss, ein paar
Das geht schon damit los, dass ich nicht genau weiss, was ein
Backup-MX koennen muss. Rein theoretisch soll er ja den Haupt-MX
ersetzen, wenn der mal down ist.
Jepp.
Dazu muss er Mails an die Domain annehmen und den Usern zum Abholen
bereitstellen.
Kann, muss aber nicht. Kommt drauf an wie du es haben willst. Je nach
Anforderung kann es reichen, die Mails einfach zu parken und dann an
den Haupt-MX weiterzureichen.

[...]
Damit waere der Backup-MX nichts anderes als ein "Smarthost" fuer
diese Domain. Und damit ueberfluessig, weil er ja auch nichts
anderes macht wie der einliefernde Mailserver: Er haelt die Mails,
bis der Haupt-MX sich wieder meldet,
Besser ist das. Es sind soviele schrottige "Mailserver" im Netz, die
sich schon beim ersten Fehler aufs Maul legen. Besser man "parkt" die
Mails selber, als sich auf "fremde" MTAs zu verlassen.

[...]
Damit sehe ich keinen Zusatznutzen fuer den User durch den
Backup-MX.
Versuche es bei geschäftskrititschem Mailverkehr mal ohne
Backup-MX. Viel Spass...
Ein Einrichten und regelmaeiges Aktualisieren der kompletten
Userliste incl. Aliases durrfte aber ein u.U. gewaltiger
Verwaltungsaufwand werden.
Ob man die Liste jetzt an einen oder zwei Hosts kopiert ist jetzt
nicht wirklich so der Aufwand...
Auch sehe ich nicht, wie der Backup-MX automatisiert lokal bereits
zugestellte Mails woandershin weiterschicken koennte.
Hae? Wass willst Du?

hth,

bis denne,

Christoph
Thomas Hochstein
2006-05-29 06:18:34 UTC
Permalink
Post by Christoph Kliemt
Damit sehe ich keinen Zusatznutzen fuer den User durch den
Backup-MX.
Versuche es bei geschäftskrititschem Mailverkehr mal ohne
Backup-MX. Viel Spass...
Nun ja.

Habe ich einen Backup-MX, gelangt die Mail in meinen Einflußbereich,
ist also - sobald ich nach dem üblichen Lauf der Dinge darauf Zugriff
erhalten, bei E-Mail im Geschäftsverkehr untertags also binnen
kürzester Frist - zugegangen, obwohl ich gar nicht drankomme.

Habe ich keinen Backup-MX, bleibt die Mail im Verantwortungsbereich
des Absenders liegen.

Letzteres wäre mir lieber ...

-thh
Joerg Hoh
2006-05-28 12:08:17 UTC
Permalink
Christian H. Kuhn schrieb
Post by Christian H. Kuhn
Post by Ilja Weis
Die Beispiel-exim.conf hat dafür auch schon eine Domainliste
vorbereitet. Ganz am Anfang die "relay_to_domains". Einfach dort eintragen.
Weil ich wohl auch demnächst mit sowas rummachen muss, ein paar
Wenn ich aber die Posts in letzter Zeit zu Backup-MX durchschaue, sieht das
für mich so aus, als ob der Backup-MX die Mails nur annehmen und halten und
später an den Haupt-MX weiterleiten soll, ohne sie zwischendurch lokal
bereitzustellen. Damit wäre der Backup-MX nichts anderes als
ein "Smarthost" für diese Domain. Und damit überflüssig, weil er ja auch
nichts anderes macht wie der einliefernde Mailserver: Er hält die Mails,
bis der Haupt-MX sich wieder meldet, und liefert sie dann aus; geschiet das
nicht in einer bestimmten Zeit, werden sie mit Fehlermeldung
zurückgeschickt. Damit sehe ich keinen Zusatznutzen für den User durch den
Backup-MX.
Jo, so ist's; allerdings gibt es ein paar kleinere Unterschiede:

1) Der ausliefernde Mailserver wird seine Mail los; es gibt keine
Rückmeldung an den Absender "Deine Mail liegt schon x Stunden bei mir in
der Queue und wurde nicht zugestellt." Das verwirrt meiner Erfahrung
nach sehr viele (vor allem weniger erfahrenere) Mail-Benutzer.

2) Die Mails liegen in deinem Zuständigkeitsbereich. Du hast Zugriff auf
die Queue und kannst die Mails zur Not woanders als zum Haupt-MX ausliefern
lassen. Ausserdem bestimmst du die Vorhaltezeiten, bis die Mails
gebounced werden.
Post by Christian H. Kuhn
Ein Einrichten und regelmäßiges Aktualisieren der kompletten Userliste incl.
Aliases dürfte aber ein u.U. gewaltiger Verwaltungsaufwand werden.
Lässt sich sehr gut in Grenzen halten. Entweder die Daten per rsync
abgleichen, alternativ LDAP oder Datenbank-Replikation benutzen.
Post by Christian H. Kuhn
Damit bleibt für mich als einzig erkennbarer Nutzen eines Backup-MX ein
Einsatz in wirklich großen Mailinstallationen, in denen ein von aussen
erreichbarer Eingangs-MX Mails auf verschiedene MXe verteilt, die dann
entweder ihrerseits weiter verteilen oder lokal zustellen. Diese eine
zentrale Maschine kann natürlich einen Backup vertragen.
Dann ist das ja auch ein relativ zustandsloses System, das nur
Regeln abarbeiten muss. Es ist natürlich per definition einfacher,
es zu ersetzen.

Gruß
Jörg
--
What did you do to the cat? It looks half-dead. -Schroedinger's wife
Sven Hartge
2006-05-28 16:49:24 UTC
Permalink
Post by Christian H. Kuhn
Das geht schon damit los, dass ich nicht genau weiss, was ein
Backup-MX können muss. Rein theoretisch soll er ja den Haupt-MX
ersetzen, wenn der mal down ist. Dazu muss er Mails an die Domain
annehmen und den Usern zum Abholen bereitstellen.
Nein. Der klassische Backup-MX nimmt die Mails nur an und puffert sie,
bis der Haupt-MX wider verfügbar ist. Benutzer haben da nichts abzuholen
und können dies auch nicht, da der klassische Backup-MX gar nicht weiss,
welche User gültig sind und welche nicht.
Post by Christian H. Kuhn
Wenn ich aber die Posts in letzter Zeit zu Backup-MX durchschaue,
sieht das für mich so aus, als ob der Backup-MX die Mails nur annehmen
und halten und später an den Haupt-MX weiterleiten soll, ohne sie
zwischendurch lokal bereitzustellen. Damit wäre der Backup-MX nichts
anderes als ein "Smarthost" für diese Domain. Und damit überflüssig,
Er hält die Mails, bis der Haupt-MX sich wieder meldet, und liefert
sie dann aus; geschiet das nicht in einer bestimmten Zeit, werden sie
mit Fehlermeldung zurückgeschickt. Damit sehe ich keinen Zusatznutzen
für den User durch den Backup-MX.
Der Backup-MX kann aber z.B. eine längere Haltezeit haben oder z.B. via
LDAP oder *SQL-Replikat _doch_ Kenntnis über die vorhandenen User haben
und somit Einlieferungen an ungültige User ablehnen.
Post by Christian H. Kuhn
Ein Einrichten und regelmäßiges Aktualisieren der kompletten Userliste incl.
Aliases dürfte aber ein u.U. gewaltiger Verwaltungsaufwand werden. Auch
sehe ich nicht, wie der Backup-MX automatisiert lokal bereits zugestellte
Mails woandershin weiterschicken könnte.
Konfigurationssache, das so hinzubekommen.


--
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/
Paul Muster
2006-05-28 18:40:22 UTC
Permalink
Post by Sven Hartge
Nein. Der klassische Backup-MX nimmt die Mails nur an und puffert sie,
bis der Haupt-MX wider verfügbar ist. Benutzer haben da nichts abzuholen
und können dies auch nicht, da der klassische Backup-MX gar nicht weiss,
welche User gültig sind und welche nicht.
Na, das will man aber heute lieber nicht mehr. Heutzutage sollte der
Backup-MX besser wissen, welche localparts in welcher Domain es gibt.


mfG Paul
Sven Hartge
2006-05-28 19:28:29 UTC
Permalink
Post by Paul Muster
Post by Sven Hartge
Nein. Der klassische Backup-MX nimmt die Mails nur an und puffert
sie, bis der Haupt-MX wider verfügbar ist. Benutzer haben da nichts
abzuholen und können dies auch nicht, da der klassische Backup-MX gar
nicht weiss, welche User gültig sind und welche nicht.
Na, das will man aber heute lieber nicht mehr. Heutzutage sollte der
Backup-MX besser wissen, welche localparts in welcher Domain es gibt.
Korrekt. Oder man betreibt gar keinen Backup-MX mehr, sollte sich dann
aber bewußt sein, dass manche Betreiber nur 24h Queuezeit auf ihren
Ausgangs-Mailservern haben und somit dann Mailverluste auftreten können.


--
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/
Christian H. Kuhn
2006-05-28 19:48:19 UTC
Permalink
Post by Sven Hartge
Korrekt. Oder man betreibt gar keinen Backup-MX mehr, sollte sich dann
aber bewußt sein, dass manche Betreiber nur 24h Queuezeit auf ihren
Ausgangs-Mailservern haben und somit dann Mailverluste auftreten können.
Aber nicht heimlich, still und leise, sondern mit passender Mail an
Absender.

Die Variante, für längere Zeit Mails auf dem Backup-MX liegen zu haben, will
mir nicht gefallen. Der Absender glaubt seine Mails längst angekommen,
dabei gammeln die auf einem Backup-MX rum; der Absender wird nicht über die
Verspätung benachrichtigt, und der Empfänger hat keinen Zugriff.

Ich denke schon, dass es Szenarien gibt, in denen das Sinn machen könnte,
aber ich denke, nach diesem Thread werde ich jemandem ausreden, für eine
(geschäftlich genutzte) Domain mit 8 Usern und 15 Mails am Tag nen
Backup-MX zu benutzen.
--
Ich kenne einige, die sich die Rehabilitierung ihrer Lieblingseröffnung
zur Lebensaufgabe gemacht haben. Sie versuchen laufend etwas zu beweisen,
was u.U. gar nicht bewiesen werden kann, weil es falsch ist. Damit haben
sie Wesentliches mit Wissenschaftlern gemeinsam. F. Volkmann in dags
Sven Hartge
2006-05-28 22:09:36 UTC
Permalink
Post by Christian H. Kuhn
Post by Sven Hartge
Korrekt. Oder man betreibt gar keinen Backup-MX mehr, sollte sich
dann aber bewußt sein, dass manche Betreiber nur 24h Queuezeit auf
ihren Ausgangs-Mailservern haben und somit dann Mailverluste
auftreten können.
Aber nicht heimlich, still und leise, sondern mit passender Mail an
Absender.
Die Variante, für längere Zeit Mails auf dem Backup-MX liegen zu
haben, will mir nicht gefallen. Der Absender glaubt seine Mails längst
angekommen, dabei gammeln die auf einem Backup-MX rum; der Absender
wird nicht über die Verspätung benachrichtigt, und der Empfänger hat
keinen Zugriff.
Also Exim in der Default-Konfiguration schickt Reminder über die
Verspätung an den jeweiligen Absender.
Post by Christian H. Kuhn
Ich denke schon, dass es Szenarien gibt, in denen das Sinn machen
könnte, aber ich denke, nach diesem Thread werde ich jemandem
ausreden, für eine (geschäftlich genutzte) Domain mit 8 Usern und 15
Mails am Tag nen Backup-MX zu benutzen.
Das ist wirklich mit Atombomen auf Mücken geschossen.


--
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/
Christian Schmidt
2006-05-28 22:05:14 UTC
Permalink
Hallo Christian,
Post by Christian H. Kuhn
Die Variante, für längere Zeit Mails auf dem Backup-MX liegen zu haben, will
mir nicht gefallen.
Als Admin liegt es ja in Deiner Hand, in welchen Zeitabstaenden der
MTA auf der Maschine versucht, die Mails beim Primary MX loszuwerden.

Gruss,
Christian
--
Christian Schmidt | Germany | ***@gmx.de
No HTML Mails, please!!
De eene hett 'n Rittergut, de annere ritt 'n Gitter rut.
Christian Schmidt
2006-05-28 22:03:17 UTC
Permalink
Hallo Christian,
Post by Christian H. Kuhn
Das geht schon damit los, dass ich nicht genau weiss, was ein Backup-MX
können muss. Rein theoretisch soll er ja den Haupt-MX ersetzen, wenn der
mal down ist. Dazu muss er Mails an die Domain annehmen und den Usern zum
Abholen bereitstellen. Wenn der Haupt-MX aber wieder da ist, gibt er die
Mails an den weiter.
Ganz genau.
Post by Christian H. Kuhn
Wenn ich aber die Posts in letzter Zeit zu Backup-MX durchschaue, sieht das
für mich so aus, als ob der Backup-MX die Mails nur annehmen und halten und
später an den Haupt-MX weiterleiten soll, ohne sie zwischendurch lokal
bereitzustellen.
Ja.
Post by Christian H. Kuhn
Damit wäre der Backup-MX nichts anderes als
ein "Smarthost" für diese Domain.
Nein, unter einem Smarthost versteht man i.a. ein System, das als
zentrales "outgoing Relay" fungiert, also ganz lax formuliert das
Gegenteil eines Secondary MX.
Post by Christian H. Kuhn
Und damit überflüssig, weil er ja auch
nichts anderes macht wie der einliefernde Mailserver: Er hält die Mails,
^^^als ;-)
Post by Christian H. Kuhn
bis der Haupt-MX sich wieder meldet, und liefert sie dann aus; geschiet das
nicht in einer bestimmten Zeit, werden sie mit Fehlermeldung
zurückgeschickt. Damit sehe ich keinen Zusatznutzen für den User durch den
Backup-MX.
Der Zusatznutzen besteht eben darin, dass waehrend einer Downtime des
Primary keine eMails als unzustellbar an den Absender zurueckgehen
("bouncen").
Post by Christian H. Kuhn
Ein Einrichten und regelmäßiges Aktualisieren der kompletten Userliste incl.
Aliases dürfte aber ein u.U. gewaltiger Verwaltungsaufwand werden.
Nein, das kann man bspw. mittels geeigneter Skripte zur Generierung
von Whitelists und dem Umherkopieren dieser Listen via SCP meines
Erachtens recht gut automatisieren.
Damit ist das einmalig etwas mehr Aufwand.
Post by Christian H. Kuhn
Auch
sehe ich nicht, wie der Backup-MX automatisiert lokal bereits zugestellte
Mails woandershin weiterschicken könnte.
Bei allen mir bekannten MTAs kann man das "Retry Time Interval"
manipulieren...
Post by Christian H. Kuhn
Damit bleibt für mich als einzig erkennbarer Nutzen eines Backup-MX ein
Einsatz in wirklich großen Mailinstallationen, in denen ein von aussen
erreichbarer Eingangs-MX Mails auf verschiedene MXe verteilt, die dann
entweder ihrerseits weiter verteilen oder lokal zustellen. Diese eine
zentrale Maschine kann natürlich einen Backup vertragen.
Das macht man nicht unbedingt via Backup-MX, sondern z.B. durch
mehrere, identisch priorisierte normale (also primary) MX-Eintraege,
die der Nameserver jeweils abwechselnd "herausgibt".
Passendes Stichwort dazu ist _AFAIK_ "Round Robin".

Gruss,
Christian
--
Christian Schmidt | Germany | ***@gmx.de
No HTML Mails, please!!
De eene hett 'n Rittergut, de annere ritt 'n Gitter rut.
Thomas Hochstein
2006-05-29 06:18:34 UTC
Permalink
Post by Christian Schmidt
Der Zusatznutzen besteht eben darin, dass waehrend einer Downtime des
Primary keine eMails als unzustellbar an den Absender zurueckgehen
("bouncen").
Aber auch nur, wenn man den Backup-MX entsprechend konfiguriert hat;
ansonsten bounced der auch ganz normal nach 4-5 Tagen, wenn der
primary nicht wieder da ist.
Post by Christian Schmidt
Post by Christian H. Kuhn
Auch
sehe ich nicht, wie der Backup-MX automatisiert lokal bereits zugestellte
Mails woandershin weiterschicken könnte.
Bei allen mir bekannten MTAs kann man das "Retry Time Interval"
manipulieren...
Aber nicht, wenn er die Mail schon angenommen und lokal zugestellt
hat, jetzt aber danach (bevor der User Mail holt) der primary wieder
hochkommt.

-thh
--
Informationsschnipsel rund um Mail und Mailserver:
<http://th-h.de/infos/email/>
Mark Trulmann
2006-05-30 11:46:45 UTC
Permalink
Post by Ilja Weis
Die Beispiel-exim.conf hat dafür auch schon eine Domainliste
vorbereitet. Ganz am Anfang die "relay_to_domains". Einfach dort eintragen.
Danke, das hat mir erstmal geholfen :)

Jetzt geht es bischen ans Feintuning.


Gruß

Mark
Thomas Hochstein
2006-05-29 06:18:30 UTC
Permalink
Post by Mark Trulmann
Ich habe einen zweiten Server wo Exim4 als MTA drauf ist und möchte den
gerne als Backup-MX für den Mailserver laufen lassen.
Vorausgesetzt, die DNS-Einträge sind richtig gesetzt, ist das trivial:
es genügt, ziemlich am Anfang der Muster-Konfiguration, die mit Exim
ausgeliefert wird, den Wert
| domainlist relay_to_domains =
zu setzen, und zwar auf die Domains, für die Exim den Backup-MX machen
soll. Der Rest der Konfiguration paßt dann schon.

Entweder kannst Du dort die Domains als Liste (mit ":" separiert)
einfügen, oder Du gibst einen Dateinamen an und schreibst die Domains
dort jeweils in eine eigene Zeile:

| domainlist relay_to_domains = eine.domain.example : nochne.domain.example : wiederwas.example

| domainlist relay_to_domains = /usr/exim/domains/backup-mx
Post by Mark Trulmann
Ich sehe in den Konfi-Dateien gerade den Wald vor lauter Bäumen nicht.
DateiEN? Uh-oh, das klingt jetzt sehr nach der Debian-spezifischen
Verhackstückselung in viele kleine Dateien. :) Falls ja - auch da muß
man im Zweifel nur irgendeinen vorbereiteten Parameter setzen, ich bin
nur völlig außerstande, Dir zu sagen, welchen und wo. [1]

-thh

[1] Auf die Gefahr hin, daß Marc mich erschlägt: mit das erste, das
ich bei der Einrichtung eines Debian-Systems mache, ist den
mitgelieferten Exim durch einen eigenen zu ersetzen ...
--
Informationsschnipsel rund um Mail und Mailserver:
<http://th-h.de/infos/email/>
Ilja Weis
2006-05-29 08:44:15 UTC
Permalink
Post by Thomas Hochstein
[1] Auf die Gefahr hin, daß Marc mich erschlägt: mit das erste, das
ich bei der Einrichtung eines Debian-Systems mache, ist den
mitgelieferten Exim durch einen eigenen zu ersetzen ...
Wieso das? Wenn man dem eine /etc/exim4/exim4.conf unterschiebt, ist
der eigentlich ganz friedlich...
Christian Schmidt
2006-05-29 09:58:58 UTC
Permalink
Hallo Thomas,
Post by Thomas Hochstein
[1] Auf die Gefahr hin, daß Marc mich erschlägt: mit das erste, das
ich bei der Einrichtung eines Debian-Systems mache, ist den
mitgelieferten Exim durch einen eigenen zu ersetzen ...
Dabei wuerde es ausreichen, dem mitgelieferten exim eine
"Monolithische" Konfigurationsdatei zu spendieren.

Gruss,
Christian
--
Christian Schmidt | Germany | ***@gmx.de
No HTML Mails, please!!
De eene hett 'n Rittergut, de annere ritt 'n Gitter rut.
Marc Haber
2006-05-29 11:31:42 UTC
Permalink
Post by Christian Schmidt
Post by Thomas Hochstein
[1] Auf die Gefahr hin, daß Marc mich erschlägt: mit das erste, das
ich bei der Einrichtung eines Debian-Systems mache, ist den
mitgelieferten Exim durch einen eigenen zu ersetzen ...
Dabei wuerde es ausreichen, dem mitgelieferten exim eine
"Monolithische" Konfigurationsdatei zu spendieren.
Ich benutze selbst auf einigen Systemen einen exim4-daemon-custom,
weil mir die Dependencies von exim4-daemon-heavy zu heftig sind.

Die Debian-Konfiguration benutze ich natürlich trotzdem.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Thomas Hochstein
2006-05-29 19:18:48 UTC
Permalink
Post by Christian Schmidt
Post by Thomas Hochstein
[1] Auf die Gefahr hin, daß Marc mich erschlägt: mit das erste, das
ich bei der Einrichtung eines Debian-Systems mache, ist den
mitgelieferten Exim durch einen eigenen zu ersetzen ...
Dabei wuerde es ausreichen, dem mitgelieferten exim eine
"Monolithische" Konfigurationsdatei zu spendieren.
Ich weiß ja, aber da ich dann sowieso ohne die Debian-"Magie" arbeite,
kann ich auch direkt (a) die allerneueste Version mir (weniger
wichtig) (b) dorthin installieren, wo sie auch bei meinen anderen
Systemen liegt (und das finde ich ganz angenehm, FHS hin oder her).

Und mit Exim meine ich mich hinreichend gut auszukennen, um die
(seltenst notwendigen und dann bisher immer problemlosen) Updates
manuell einpflegen zu können und auf die Annehmlichkeiten eines
Paketmanagements zu verzichten.

-thh
Mark Trulmann
2006-05-30 11:51:45 UTC
Permalink
Post by Thomas Hochstein
DateiEN? Uh-oh, das klingt jetzt sehr nach der Debian-spezifischen
Verhackstückselung in viele kleine Dateien. :) Falls ja - auch da muß
man im Zweifel nur irgendeinen vorbereiteten Parameter setzen, ich bin
nur völlig außerstande, Dir zu sagen, welchen und wo. [1]
Ja, danke für die Infos.

Es ist ein verhackstückeltes Debian. War bisher immer nur Postfix
gewohnt und habe aus Faulheit einfach nen Image Serverhoster eingespielt.
Leider war da Exim 4 drin.

Es läuft jetzt aber. Müssen aber noch paar Schönheitskorrekturen
gemacht werden :)

Danke & Gruß

Mark

Loading...