Antwort: Erstellung der Mail-Liste xyz@socotec.de <-> foo.bar@canzler.de / zpp.de / socotec.de
Hola zusammen,
das es bei den vorhandenen Socotec.de Adressen kein technisches sondern (bei uns) eher ein organisatorisches Thema wird, wollte ich nicht unerwähnt lassen. Mir wurde nur gesagt dass sich ganz bewusst gegen eine Weiterleitung entschieden hat. Das nehm ich noch zur Klärung mit. Also erstmal Haken dran.
zu Jens Fragen: Einen Import per CSV kann es eigentlich nur beim Start einmalig geben. Sonst können wir nicht sicherstellen, dass es zu Duplikaten kommt. Wie man hier sinnvoll auf solche prüfen könnte, bin ich gerade überfragt. Wenn wir nur von Mitarbeiterpostfächern reden, dann könnte man die Adressen hoffentlich bald aus unserem MS Tenant ziehen. Wenn wir aber auch von Funktionspostfächern sprechen, dann muss es ein Automatismus sein, der auch hier auf Duplikate prüft, spontan fällt mir da cloud@ als Beispielabsender ein...
Wenn jeder von uns einen SSH Zugang zum Server bekommt, könnte man das vielleicht per Konsolen-Dialoge abfragen, dann sparen wir uns die Installation und Absicherung eines Webserversdienstes. Aktuell richten wir so mit selbst bzw. von Carsten geschrieben Skripten unsere Nutzer auf dem bestehenden Mailserver ein. Das Skript kann dann auch auf Duplikate hinweisen. Auch die Zuordnung wohin die socotec.de Adresse geroutet werden soll, könnten an per Checkboxen o.ä. realisieren.
Bei uns ist es ja bei den Personen eine 1:1 Umsetzung von vorname.nachname@canzler.de zu vorname.nachname@socotec.de, so wie wir es im letzten Meeting angesprochen haben. Bei ZPP wird es aufwändiger. Wie gehen wir denn nun mit dem Vorschlag von Patrick um, bei den Mailkonten zusätzlich durchgängig eine Zahl zu verwenden? Optisch unschön, aber technisch hilfreich.
Was wir auch besprechen müssten ist, wie wir mit den neuen Firmenkäufen umgehen. Bei uns die Firma Enco. Sollten diese 40 Personen erstmal noch Canzler.de Adressen bekommen, damit wir (bezugnehmend auf Jens Mail von 8:24 Uhr heute morgen) Vorschlag 2 umsetzen können? Ich halte diesen für den sinnvollsten. Sprich, zuerst möglichst wenig Anpassungen an der bestehenden Infrastruktur. Eingehende Mails an ZPP/Canzler sollen unbehandelt weitergereicht werden. Eingehende Socotec.de Mails werden entsprechend der Filter- bzw. Transformdateien umgeschrieben und dann an einen der drei bisherigen Mailserver übergeben. Ausgehende Mails sollen nur dann mit socotec.de umgeschrieben werden, wenn der Absender in der gerade benannten Filter-/Transformdatei vorhanden ist. So können beispielsweise Funktionspostfächer wie Projektadressen erstmal bestehen bleiben und Zug um Zug bei Bedarf umgestellt werden.
Github Zugang sollte nun jeder haben. Aktuell hat jeder noch Adminrechte. Wenn wir hier was tunen können, gern bescheid geben.
Freundliche Grüße i. A. Thomas Korus
T +49 208 4699-104
CANZLER GmbH - A COMPANY OF SOCOTEC Viehgasse 10 | 45481 Mülheim an der Ruhr | T +49 208 4699-0 Geschäftsführer: Andreas Masiorek, Michael Nolte, Holger Richter Handelsregister Amtsgericht Dresden - HRB 8883
www.canzler.de | Datenschutz
Von: "Jens Seiler" js@zpp.de An: thomas.korus@canzler.de, tr@zpp.de Datum: 02.05.2025 11:40 Betreff: Erstellung der Mail-Liste xyz@socotec.de <-> foo.bar@canzler.de / zpp.de / socotec.de
Hallo Kollegen,
ich habe mich gerade mit Patrick besprochen, wie die Listen für die Mailadressen aussehen muss. Technisch ist das keine Zauberkunst. Im wesentlichen eine CSV-Datei mit zwei Spalten: neue @socotec.de-Adresse in Spalte 1, vorhandenes Ziel/Quelle Spalte 2.
Das wir irgendwann dann auch dazu übergehen wollen, für z.B. neue Mitarbeiter gar keine @canzler.de / @zpp.de anzulegen, habe ich schon angemerkt. Das nimmt er mal mit.
Bezüglich Thomas' Anmerkungen zu vorhandenen @socotec.de-Adressen von Mitarbeitern bei Canzler/ZPP: da sind wir schnell drauf gekommen, dass das kein Problem ist. Sobald man z.B: jens.seiler@socotec.de -> js@zpp.de anlegt, landet das Zeugs einfach gar nicht mehr beim Holding-Microsoft-Tenant sondern halt direkt bei ZPP etc.
Wir haben auch darüber gesprochen, dass es Mailverteiler geben wird. Also z.B. für Ingenieurgesellschaften oder Funktionsadressen Neben den bekannten Mailverteilern hat Patrick auch noch Mailinglisten beworben. Können wir später mal drüber reden.
Frage jetzt an Thomas: wie wollen wir für Canzler die "@socotec.de <-> @canzler.de" generieren? Am Anfang klar manuell, einfach mir zusenden. Wie später? Wollt ihr Listen irgendwo hochladen, ich lasse einen Automatismus das Durchnudeln? Machen wir eine Weboberfläche, wo das jeder jederzeit bearbeiten kann? Das gleiche bei Tobias, mit hoffentlich weniger Fluktuationen.
Wie dem auch sei wird Patrick weiter Fragen notieren und uns dann zukommen lassen. Für mich legt er jetzt auch schon ein paar Issues im Github an. Tobias, hast Du schon einen GitHub-Account angelegt und an Thomas gegeben? (Danke für das Einrichten!)
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
¡Hola!
* thomas.korus@canzler.de thomas.korus@canzler.de:
Hola zusammen,
das es bei den vorhandenen Socotec.de Adressen kein technisches sondern (bei uns) eher ein organisatorisches Thema wird, wollte ich nicht unerwähnt lassen. Mir wurde nur gesagt dass sich ganz bewusst gegen eine Weiterleitung entschieden hat. Das nehm ich noch zur Klärung mit. Also erstmal Haken dran.
Ich brauche bitte Kontext: Du sprichst von den Mailboxen, die bei M$ gehostet werden und es wurde für diese Mailboxen entschieden von dieser Plattform aus keine Weiterleitungen an andere Mailboxen auf anderen Plattformen einzurichten, ja?
Wenn wir allen Traffic auf den neuen BF routen und dort dann die Routing-Entscheidung treffen ob Nachrichten an "wirkliche" socotec.de-EmpfängerInnen ins M$-Land sollen, dann können wir auf dem BF ebenso entscheiden Nachrichten für einige "wirkliche" socotec.de-EmpfängerInnen auch an andere Plattformen (lies: Alt-Systeme) zu routen. Technisch ist das möglich.
zu Jens Fragen: Einen Import per CSV kann es eigentlich nur beim Start einmalig geben. Sonst können wir nicht sicherstellen, dass es zu Duplikaten kommt. Wie man hier sinnvoll auf solche prüfen könnte, bin ich gerade überfragt. Wenn wir nur von Mitarbeiterpostfächern reden, dann könnte man die Adressen hoffentlich bald aus unserem MS Tenant ziehen. Wenn wir aber auch von Funktionspostfächern sprechen, dann muss es ein Automatismus sein, der auch hier auf Duplikate prüft, spontan fällt mir da cloud@ als Beispielabsender ein...
Wenn jeder von uns einen SSH Zugang zum Server bekommt, könnte man das
Welchen Server meinst Du mit "zum Server"? Den BF? Da kann / sollten IMO zwei MA jedes Standortes einen personenbezogenen Account mit root-Rechten haben, damit ihr z. B. eben Adress-Updates vornehmen könnt.
vielleicht per Konsolen-Dialoge abfragen, dann sparen wir uns die Installation und Absicherung eines Webserversdienstes.
Die fertigen, in Produktion genutzten Adress-Daten werden gecryptet im gitlab Eurer Wahl, in Plaintext auf dem BF und gecryptet auf all den Maschinen der Personen liegen, die Zugang zum gitlab haben. Wenn diese Personen dann noch den Key haben, um die (gecryptete) vault-Datei mit den Adressdaten zu lesen, dann könnt ihr dort nachsehen und mit den Daten arbeiten.
Das ist der file-basierte Ansatz. Für den scheint mir am besten zu sein, wir validieren die Daten bevor sie ins Ansible und von dort dann auf die Plattform kommen. Ansible ist dann was die Validierung angeht raus und nimmt (gitgläubig ;-) alles was es bekommt und rollt es auch.
Ein anderer Ansatz wäre ihr führt diese Listen in einem RDBMS wie PostgreSQL und der BF fragt live ab. Geht auch mit LDAP. Wir können z. B. einen read-only Secondary mit repl-Verfahren auf dem BF einsetzen und den füttert ihr von Euch aus. Auch in diesen Fällen obliegt Euch oder einem Skript / Programm die Aufgabe, die Daten zu validieren.
Randnotiz: So ein Programm muss nicht nur Kollisionen im Namensraum automatisch auflösen, es darf auch eine einmal getroffene Entscheidung nicht mehr ändern, damit thomas.korus01@socotec.de auch immer unter dieser Adresse erreichbar sein wird und die Adresse bei einer Kollisionsauflösung nicht plötzlich thomas.korus02@socotec.de wird und der neue Thomas dann unter thomas.korus01@socotec.de erreichbar wird.
Aktuell richten wir so mit selbst bzw. von Carsten geschrieben Skripten unsere Nutzer auf dem bestehenden Mailserver ein. Das Skript kann dann auch auf Duplikate hinweisen. Auch die Zuordnung wohin die socotec.de Adresse geroutet werden soll, könnten an per Checkboxen o.ä. realisieren.
Bei uns ist es ja bei den Personen eine 1:1 Umsetzung von vorname.nachname@canzler.de zu vorname.nachname@socotec.de, so wie wir es im letzten Meeting angesprochen haben. Bei ZPP wird es aufwändiger. Wie gehen wir denn nun mit dem Vorschlag von Patrick um, bei den Mailkonten zusätzlich durchgängig eine Zahl zu verwenden? Optisch unschön, aber technisch hilfreich.
Ich werfe mal in den Raum: Die Entscheidung solltet ihr einmalig und jetzt treffen, denn den Kunden draussen sind wiederholte Adressänderungen zwar zuzumuten, aber witzig finden sie das nicht.
Was wir auch besprechen müssten ist, wie wir mit den neuen Firmenkäufen umgehen. Bei uns die Firma Enco. Sollten diese 40 Personen erstmal noch Canzler.de Adressen bekommen, damit wir (bezugnehmend auf Jens Mail von 8:24 Uhr heute morgen) Vorschlag 2 umsetzen können?
Wann wird das sein? Haben wir ausreichend Zeit vorher einen neuen socotec.de-Mailbox-Server an den Start zu bringen?
Wie aufwändig wäre es, Eurem bestehenden Mailserver beizubringen er sei *auch* für socotec.de-Empfänger zuständig?
Ich halte diesen für den sinnvollsten. Sprich, zuerst möglichst wenig Anpassungen an der bestehenden Infrastruktur.
ACK
Eingehende Mails an ZPP/Canzler sollen unbehandelt weitergereicht werden.
Unbehandelt as in "keine Adressumschreibung" oder as in "ungefiltert"?
Eingehende Socotec.de Mails werden entsprechend der Filter- bzw. Transformdateien umgeschrieben und dann an einen der drei bisherigen Mailserver übergeben. Ausgehende Mails sollen nur dann mit socotec.de umgeschrieben werden, wenn der Absender in der gerade benannten Filter-/Transformdatei vorhanden ist. So können beispielsweise Funktionspostfächer wie Projektadressen erstmal bestehen bleiben und Zug um Zug bei Bedarf umgestellt werden.
ACK
Github Zugang sollte nun jeder haben. Aktuell hat jeder noch Adminrechte. Wenn wir hier was tunen können, gern bescheid geben.
Danke
Patrick
Freundliche Grüße i. A. Thomas Korus
T +49 208 4699-104
CANZLER GmbH - A COMPANY OF SOCOTEC Viehgasse 10 | 45481 Mülheim an der Ruhr | T +49 208 4699-0 Geschäftsführer: Andreas Masiorek, Michael Nolte, Holger Richter Handelsregister Amtsgericht Dresden - HRB 8883
www.canzler.de | Datenschutz
Von: "Jens Seiler" js@zpp.de An: thomas.korus@canzler.de, tr@zpp.de Datum: 02.05.2025 11:40 Betreff: Erstellung der Mail-Liste xyz@socotec.de <-> foo.bar@canzler.de / zpp.de / socotec.de
Hallo Kollegen,
ich habe mich gerade mit Patrick besprochen, wie die Listen für die Mailadressen aussehen muss. Technisch ist das keine Zauberkunst. Im wesentlichen eine CSV-Datei mit zwei Spalten: neue @socotec.de-Adresse in Spalte 1, vorhandenes Ziel/Quelle Spalte 2.
Das wir irgendwann dann auch dazu übergehen wollen, für z.B. neue Mitarbeiter gar keine @canzler.de / @zpp.de anzulegen, habe ich schon angemerkt. Das nimmt er mal mit.
Bezüglich Thomas' Anmerkungen zu vorhandenen @socotec.de-Adressen von Mitarbeitern bei Canzler/ZPP: da sind wir schnell drauf gekommen, dass das kein Problem ist. Sobald man z.B: jens.seiler@socotec.de -> js@zpp.de anlegt, landet das Zeugs einfach gar nicht mehr beim Holding-Microsoft-Tenant sondern halt direkt bei ZPP etc.
Wir haben auch darüber gesprochen, dass es Mailverteiler geben wird. Also z.B. für Ingenieurgesellschaften oder Funktionsadressen Neben den bekannten Mailverteilern hat Patrick auch noch Mailinglisten beworben. Können wir später mal drüber reden.
Frage jetzt an Thomas: wie wollen wir für Canzler die "@socotec.de <-> @canzler.de" generieren? Am Anfang klar manuell, einfach mir zusenden. Wie später? Wollt ihr Listen irgendwo hochladen, ich lasse einen Automatismus das Durchnudeln? Machen wir eine Weboberfläche, wo das jeder jederzeit bearbeiten kann? Das gleiche bei Tobias, mit hoffentlich weniger Fluktuationen.
Wie dem auch sei wird Patrick weiter Fragen notieren und uns dann zukommen lassen. Für mich legt er jetzt auch schon ein paar Issues im Github an. Tobias, hast Du schon einen GitHub-Account angelegt und an Thomas gegeben? (Danke für das Einrichten!)
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
Hallo,
zum Routing sehe ich das allgemein erstmal so:
Internet --> zu Socotec
Alles, egal ob @zpp.de, @canzler.de, @socotec.de geht in Zukunft (ab Mitte Juni) an den BF.
Alles was internetseitig auf dem Server mit Ziel @zpp.de, @canzler.de einschlägt wird so an die Alt-Server direkt weitergeleitet. Die Übersetzungslisten sind da irrelevant. Landet etwas mit Ziel @socotec.de auf dem BF, schaut der in unserer Tabelle nach, ob es sich um eine Adresse, die bei ZPP, Canzler oder Socotec verortet ist handelt. Dann transformiert er sie um, dass z.B. der Empfänger jens.seiler@socotec.de eigentlich der Empfänger js@zpp.de ist und leitet es an unseren Alt-Server bei ZPP weiter.
In der näheren Zukunft, aber nicht im Juni, sollten wir unsere Firmen-spezifischen Systeme dann soweit bringen, dass sie auch eine an sie weitergeleitete Mail jens.seiler@socotec.de ohne weitere Transformation in meine Mailbox schieben können.
Socotec --> Internet
Alle Firmen senden alle ausgehenden Mails an den neuen BF. Absenderadresse ist entweder z.B. meine js@zpp.de oder auch schon jens.seiler@socotec.de. Erhält der Server eine ausgehende Mail mit einer @socotec.de Adresse stellt er sie "unverändert" an die Empfänger zu. Erhält der Server eine ausgehende Mail von z.B. js@zpp.de stellt er sie mit Absender jens.seiler@socotec.de an die Empfänger zu, weil wir das so in der Übersetzungsliste gesagt haben.
Zu der Frage von bestehenden @socotec.de-Adressen, die bisher bei MS aufschlagen und dort ggf. per Weiterleitungsregel an @canzler.de / @zpp.de weitergeleitet werden. Diese werden in Zukunft nicht mehr an MS gehen, sondern in unserer Übersetzungsliste stehen. Und dann geht halt die auch tatsächlich bereits existierende jens.seiler@socotec.de eben nicht mehr an Microsoft, sondern an js@zpp.de. Das ist keine besondere Konfiguration sondern eine Folge des oben beschriebenen.
In fernerer Zukunft sollte in jeder einzelnen Firma der direkte Empfang von @socotec.de-Adressen vom BF aus möglich sein. Dann entfällt auf dem BF die Transformation der Empfänger-Mailadresse und die Übersetzungsliste wird nur noch gebraucht, um zu entscheiden, ob es denn jetzt an Canzler, ZPP, die Holding oder zukünftige Zukäufe geht. Die Transformation auf die Alt-Adressen wird dann zu individuellen Zeitpunkten je Firma beendet.
Verstehe ich das so richtig?
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
Von: "Patrick Ben Koetter" p@sys4.de An: socotec@list.sys4.de Datum: 07.05.2025 10:03 Betreff: [socotec] Re: Antwort: Erstellung der Mail-Liste xyz@socotec.de <-> foo.bar@canzler.de / zpp.de / socotec.de
¡Hola!
* thomas.korus@canzler.de thomas.korus@canzler.de:
Hola zusammen,
das es bei den vorhandenen Socotec.de Adressen kein technisches sondern (bei uns) eher ein organisatorisches Thema wird, wollte ich nicht unerwähnt lassen. Mir wurde nur gesagt dass sich ganz bewusst gegen eine
Weiterleitung entschieden hat. Das nehm ich noch zur Klärung mit. Also erstmal Haken dran.
Ich brauche bitte Kontext: Du sprichst von den Mailboxen, die bei M$ gehostet werden und es wurde für diese Mailboxen entschieden von dieser Plattform aus keine Weiterleitungen an andere Mailboxen auf anderen Plattformen einzurichten, ja?
Wenn wir allen Traffic auf den neuen BF routen und dort dann die Routing-Entscheidung treffen ob Nachrichten an "wirkliche" socotec.de-EmpfängerInnen ins M$-Land sollen, dann können wir auf dem BF ebenso entscheiden Nachrichten für einige "wirkliche" socotec.de-EmpfängerInnen auch an andere Plattformen (lies: Alt-Systeme) zu routen. Technisch ist das möglich.
zu Jens Fragen: Einen Import per CSV kann es eigentlich nur beim Start einmalig geben. Sonst können wir nicht sicherstellen, dass es zu Duplikaten kommt. Wie
man
hier sinnvoll auf solche prüfen könnte, bin ich gerade überfragt. Wenn wir nur von Mitarbeiterpostfächern reden, dann könnte man die Adressen hoffentlich bald aus unserem MS Tenant ziehen. Wenn wir aber auch von Funktionspostfächern sprechen, dann muss es ein Automatismus sein, der auch hier auf Duplikate prüft, spontan fällt mir
da
cloud@ als Beispielabsender ein...
Wenn jeder von uns einen SSH Zugang zum Server bekommt, könnte man das
Welchen Server meinst Du mit "zum Server"? Den BF? Da kann / sollten IMO zwei MA jedes Standortes einen personenbezogenen Account mit root-Rechten haben, damit ihr z. B. eben Adress-Updates vornehmen könnt.
vielleicht per Konsolen-Dialoge abfragen, dann sparen wir uns die Installation und Absicherung eines Webserversdienstes.
Die fertigen, in Produktion genutzten Adress-Daten werden gecryptet im gitlab Eurer Wahl, in Plaintext auf dem BF und gecryptet auf all den Maschinen der Personen liegen, die Zugang zum gitlab haben. Wenn diese Personen dann noch den Key haben, um die (gecryptete) vault-Datei mit den Adressdaten zu lesen, dann könnt ihr dort nachsehen und mit den Daten arbeiten.
Das ist der file-basierte Ansatz. Für den scheint mir am besten zu sein, wir validieren die Daten bevor sie ins Ansible und von dort dann auf die Plattform kommen. Ansible ist dann was die Validierung angeht raus und nimmt (gitgläubig ;-) alles was es bekommt und rollt es auch.
Ein anderer Ansatz wäre ihr führt diese Listen in einem RDBMS wie PostgreSQL und der BF fragt live ab. Geht auch mit LDAP. Wir können z. B. einen read-only Secondary mit repl-Verfahren auf dem BF einsetzen und den füttert ihr von Euch aus. Auch in diesen Fällen obliegt Euch oder einem Skript / Programm die Aufgabe, die Daten zu validieren.
Randnotiz: So ein Programm muss nicht nur Kollisionen im Namensraum automatisch auflösen, es darf auch eine einmal getroffene Entscheidung nicht mehr ändern, damit thomas.korus01@socotec.de auch immer unter dieser Adresse erreichbar sein wird und die Adresse bei einer Kollisionsauflösung nicht plötzlich thomas.korus02@socotec.de wird und der neue Thomas dann unter thomas.korus01@socotec.de erreichbar wird.
Aktuell richten wir so mit selbst bzw. von Carsten geschrieben Skripten unsere Nutzer auf dem bestehenden Mailserver ein. Das Skript kann dann auch auf Duplikate hinweisen. Auch die Zuordnung wohin die socotec.de Adresse geroutet werden soll, könnten an per Checkboxen o.ä. realisieren.
Bei uns ist es ja bei den Personen eine 1:1 Umsetzung von vorname.nachname@canzler.de zu vorname.nachname@socotec.de, so wie wir
es
im letzten Meeting angesprochen haben. Bei ZPP wird es aufwändiger. Wie gehen wir denn nun mit dem Vorschlag
von
Patrick um, bei den Mailkonten zusätzlich durchgängig eine Zahl zu verwenden? Optisch unschön, aber technisch hilfreich.
Ich werfe mal in den Raum: Die Entscheidung solltet ihr einmalig und jetzt treffen, denn den Kunden draussen sind wiederholte Adressänderungen zwar zuzumuten, aber witzig finden sie das nicht.
Was wir auch besprechen müssten ist, wie wir mit den neuen Firmenkäufen umgehen. Bei uns die Firma Enco. Sollten diese 40 Personen erstmal noch Canzler.de Adressen bekommen, damit wir (bezugnehmend auf Jens Mail von 8:24 Uhr heute morgen) Vorschlag 2 umsetzen können?
Wann wird das sein? Haben wir ausreichend Zeit vorher einen neuen socotec.de-Mailbox-Server an den Start zu bringen?
Wie aufwändig wäre es, Eurem bestehenden Mailserver beizubringen er sei *auch* für socotec.de-Empfänger zuständig?
Ich halte diesen für den sinnvollsten. Sprich, zuerst möglichst wenig Anpassungen an der bestehenden Infrastruktur.
ACK
Eingehende Mails an ZPP/Canzler sollen unbehandelt weitergereicht
werden.
Unbehandelt as in "keine Adressumschreibung" oder as in "ungefiltert"?
Eingehende Socotec.de Mails werden entsprechend der Filter- bzw. Transformdateien umgeschrieben und dann an einen der drei bisherigen Mailserver übergeben. Ausgehende Mails sollen nur dann mit socotec.de umgeschrieben werden,
wenn
der Absender in der gerade benannten Filter-/Transformdatei vorhanden
ist.
So können beispielsweise Funktionspostfächer wie Projektadressen erstmal
bestehen bleiben und Zug um Zug bei Bedarf umgestellt werden.
ACK
Github Zugang sollte nun jeder haben. Aktuell hat jeder noch
Adminrechte.
Wenn wir hier was tunen können, gern bescheid geben.
Danke
Patrick
Freundliche Grüße i. A. Thomas Korus
T +49 208 4699-104
CANZLER GmbH - A COMPANY OF SOCOTEC Viehgasse 10 | 45481 Mülheim an der Ruhr | T +49 208 4699-0 Geschäftsführer: Andreas Masiorek, Michael Nolte, Holger Richter Handelsregister Amtsgericht Dresden - HRB 8883
www.canzler.de | Datenschutz
Von: "Jens Seiler" js@zpp.de An: thomas.korus@canzler.de, tr@zpp.de Datum: 02.05.2025 11:40 Betreff: Erstellung der Mail-Liste xyz@socotec.de <-> foo.bar@canzler.de / zpp.de / socotec.de
Hallo Kollegen,
ich habe mich gerade mit Patrick besprochen, wie die Listen für die Mailadressen aussehen muss. Technisch ist das keine Zauberkunst. Im wesentlichen eine CSV-Datei mit zwei Spalten: neue @socotec.de-Adresse
in
Spalte 1, vorhandenes Ziel/Quelle Spalte 2.
Das wir irgendwann dann auch dazu übergehen wollen, für z.B. neue Mitarbeiter gar keine @canzler.de / @zpp.de anzulegen, habe ich schon angemerkt. Das nimmt er mal mit.
Bezüglich Thomas' Anmerkungen zu vorhandenen @socotec.de-Adressen von Mitarbeitern bei Canzler/ZPP: da sind wir schnell drauf gekommen, dass
das
kein Problem ist. Sobald man z.B: jens.seiler@socotec.de -> js@zpp.de anlegt, landet das Zeugs einfach gar nicht mehr beim Holding-Microsoft-Tenant sondern halt direkt bei ZPP etc.
Wir haben auch darüber gesprochen, dass es Mailverteiler geben wird.
Also
z.B. für Ingenieurgesellschaften oder Funktionsadressen Neben den bekannten Mailverteilern hat Patrick auch noch Mailinglisten beworben. Können wir später mal drüber reden.
Frage jetzt an Thomas: wie wollen wir für Canzler die "@socotec.de <-> @canzler.de" generieren? Am Anfang klar manuell, einfach mir zusenden.
Wie
später? Wollt ihr Listen irgendwo hochladen, ich lasse einen
Automatismus
das Durchnudeln? Machen wir eine Weboberfläche, wo das jeder jederzeit bearbeiten kann? Das gleiche bei Tobias, mit hoffentlich weniger Fluktuationen.
Wie dem auch sei wird Patrick weiter Fragen notieren und uns dann
zukommen
lassen. Für mich legt er jetzt auch schon ein paar Issues im Github an. Tobias, hast Du schon einen GitHub-Account angelegt und an Thomas
gegeben?
(Danke für das Einrichten!)
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
participants (3)
-
Jens Seiler -
Patrick Ben Koetter -
thomas.korus＠canzler.de