Moin!
* Jens Seiler js@zpp.de:
Hallo zusammen und einen guten Wochenstart!
Da wir ja voraussichtlich (mit an Sicherheit grenzender Wahrscheinlichkeit?) zunächst mit Personen-Mail-Adressen beginnen und unsere zahlreichen Funktions-/Projekt-Adressen erstmal bei der jeweiligen @zpp.de/@canzler.de belassen wird es erforderlich sein, dass entweder
- ausgehende Mails der jeweiligen Firma regelbasiert entweder den
traditionellen Weg gehen oder über den neuen Boundary Filter
oder
- der Boundary Filter bekommt alles, transformiert aber bzgl.
Absender-/Empfänger-Adresse nur die in den zukünftigen Listen hinterlegten Adressen und lässt den Rest unverändert durch.
Ich glaube beide Varianten sind nicht unbedingt trivial. Bei 1) müssten wir uns unsere jeweiligen System anschauen und gucken, wie das dort verwaltet werden kann. Und halt bei jeder neuen Adresse auch am traditionellen System jeweils konfigurieren, wohin es gehen soll. Bei 2) müssten wir reibungslos unsere bestehenden Systeme umschalten auf das neue inkl. Anpassen der bestehenden Domänen-Einträge bzgl. SPF usw. aber hier sehe ich insgesamt Vorteile?
Reibungslos? Abgesehen davon, dass wir das mit ein wenig TTL-Spielerei bei den MXen auf ein 30 Sekunden Zeitfenster runterbringen könnten, verstehe ich noch nicht worin das "Reibungslos" besteht. Reibungslos, weil fehlerfrei oder weil sofort alt nicht mehr und nur noch neu oder...?
Wenn wir den neuen MX (BF) im DNS einer oder mehrere Domains announcen, dann können die Altsysteme ab dann alle Mails über den BF versenden und inbound traffic geht dann noch eine Weile über das neue und die Altsysteme ein. Irgendwann dann hat das INET im DNS geschnallt, dass nur noch der BF zuständig ist und aller inbound traffic - auch für die Alt-Domains (sorry) - wird dann zum BF geroutet.
Der hat dann Transport-Regeln, welche Empfänger der Alt-Domains zu den jeweilig, zuständigen Servern routet und zusätzlich für socotec.de-Empfänger annimmt, das Routing mit den Umschreibetabellen neu berechnet und dann auch wieder zu den Alt-Systemen durchschiebt.
Ich würde allein der Klarheit und Stoßrichtung halber die Variante 2 vorziehen. Das hilft uns im Fall der Fälle auch beim Debuggen, weil alles auf einer Maschine stattfinden (sollte) und wir nicht Daten aus mehreren Servern zusammentragen müssten. KISS und so… Weißt schon: "I was made for loving you..." (Gott, ich werde alt...).
Grüße
Patrick
Habe ich eine Variante übersehen / Wie ist Eure Einschätzung bzgl. der Vor-/Nachteile?
Gruß, Jens
Freundliche Grüße
i. V. Dipl.-Inform. Jens Seiler Operatives Management
T +49 234 92 04-1232
M +49 151 65 63 14 86 js@zpp.de
ZPP INGENIEURE AG - A SOCOTEC COMPANY Lise-Meitner-Allee 11 - 44801 Bochum zpp.de
Amtsgericht Bochum - HRB 16414 Vorstand: Dipl.-Ing. Martin Demmer, Dipl.-Ing. Martin Schmitz, Dr.-Ing. Ingo Spohr Aufsichtsratsvorsitzender: Prof. Dr.-Ing. Ludger Speier
Socotec mailing list -- socotec@list.sys4.de To unsubscribe send an email to socotec-leave@list.sys4.de