May 2025 - Socotec - list.sys4.de

Re: Antwort: Re: Antwort: Erstellung der Mail-Liste xyz@socotec.de <-> foo.bar@canzler.de / zpp.de / socotec.de
by Patrick Ben Koetter 07 May '25

07 May '25

Hi! * thomas.korus(a)canzler.de <thomas.korus(a)canzler.de>: > Guten Morgen allerseits! > > Ja ging um die bei MS angelegten Socotec.de Mailadressen. Hier hat wohl > jede Person für sich selbst entscheiden dürfen, ob eine Weiterleitung auf > die eigene Canzler/ZPP... Adresse angelegt wird oder nur ein Webmailzugang > ausreichend ist. > Jens schrieb es schon für ZPP und nun gibt es auch für Canzler Klarheit: > Hier müssen wir nichts gesondert beachten. > Nach den Veränderungen in der Geschäftsleitung ist es nur noch eine > Adresse und die dort eingehenden Mails sind bisher -sachlich formuliert- > irrelevant. > Es wird dann auch keine Sonderlösungen geben müssen. > Sprich: Dieses Thema als erledigt betrachten. Und wie ist jetzt die Lösung? Der BF routet alle @socotec.de direkt in die Mailboxen der Alt-Systeme? (Sorry, wenn ich so bohre, aber mir ist es immer noch nicht klar und spekulieren mag ich da nicht.) > Restliche Fragen waren auch von mir und die habe ich unten IN > GROßBUCHSTABEN zur besseren Lesbarkeit beantwortet Schrei nicht so... ;-) > Von: "Patrick Ben Koetter" <p(a)sys4.de> > An: socotec(a)list.sys4.de > Datum: 07.05.2025 10:03 > Betreff: [socotec] Re: Antwort: Erstellung der Mail-Liste > xyz(a)socotec.de <-> foo.bar(a)canzler.de / zpp.de / socotec.de > > > > ¡Hola! > > * thomas.korus(a)canzler.de <thomas.korus(a)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. > S.O. ERLEDIGT > > > 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. > JA ICH MEINTE DEN BF. > > > 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(a)socotec.de auch immer unter > dieser Adresse erreichbar sein wird und die Adresse bei einer > Kollisionsauflösung nicht plötzlich thomas.korus02(a)socotec.de wird und > der neue Thomas dann unter thomas.korus01(a)socotec.de erreichbar wird. > > DAS IST EIN GUTER HINWEIS, ANSONSTEN REST VERSTANDEN. > ICH GLAUBE DER FILEBASIERTE ANSATZ SOLLTE AUSREICHEN, > AUCH DER KOMPLEXITÄT / ANGREIFBARKEIT DES SERVERS WEGEN. Woran denkst Du wenn Du an Angreifbarkeit denkst? Die Verbindungen von / zu Services könnten wir sauber firewallen und wenn das lokale Secondaries sind, dann reissen viele Anfragen (DOS) den Betrieb hinten nicht runter. Postfix hat die Ergebnisse eh nach einer Abfrage im Cache (Memory). Also Last wäre auch kein Gegner. > HAST DU ODER JEMAND ANDERES EINE IDEE FÜR EINE MÖGLICHST AUTOMATISIERTE > VALIDIERUNGS & KOLLISIONSPRÜFUNG? Ich habe hier nichts rumliegen und ich bin kein Entwickler, deshalb würde ich da erst einmal intern fragen ob einer unserer Devs (oder auch Carsten) eine Strategie für solche Cases schon kennt *und* ich habe daran gedacht zusätzlich einen pre-commit hook ins Git mit aufzunehmen, der dann nochmal prüft ob das alles so raus soll. > > 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(a)canzler.de zu vorname.nachname(a)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. > EINE ENTSCHEIDUNG DAZU WIRD ES KURZFRISTIG GEBEN. TOBIAS HAT U.A. DIES > GESTERN DEN HERRSCHAFTEN PRÄSENTIERT DAMIT DIESE SICH GEDANKEN MACHEN > KÖNNEN. +1 > > 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? > JA HABEN WIR. DA SORGE ICH SCHON FÜR. +1 > ES WAR EHER EINE GRENERELLE FRAGE NACH DER SINNHAFTIGKEIT. > WIR SOLLTEN NACH UND NACH UNSERE INTERNEN SYSTEME ERTÜCHTIGEN (AUCH) MIT > SOCOTEC.DE ZU SENDEN Ja, das scheint mir auch der wünschenswerte nächste Schritt, damit da bald Konsistenz und Ruhe reinkommt und die Leute (zumindest da) nicht mehr mit Reorganisation beschäftigt sind und sich (wieder) auf den Inhalt ihrer Arbeit konzentrieren können. > Wie aufwändig wäre es, Eurem bestehenden Mailserver beizubringen er sei > *auch* für socotec.de-Empfänger zuständig? > LOKAL RECHT GERING + GANZER DNS-KRAM, CARSTEN KANN MEHR DAZU SAGEN Das klingt nach vertretbarem Aufwand und wir könnten das zur Not als Interimslösung verwenden falls wir nicht ab Start mit einem @socotec.de-Mailserver loslegen können. > > 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"? > NICHT UMGESCHRIEBEN, MACHT JA KEIN SINN. SPAMFILTERUNG LÄUFT FÜR ALLE > GLEICH +1 > > 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 p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

2 1

WG: Your message to socotec@list.sys4.de awaits moderator approval
by Tobias Rahm 07 May '25

07 May '25

Na klasse... -----Ursprüngliche Nachricht----- Von: socotec-bounces(a)list.sys4.de <socotec-bounces(a)list.sys4.de> Gesendet: Mittwoch, 7. Mai 2025 13:11 An: Tobias Rahm <Tobias.Rahm(a)socotec.de> Betreff: Your message to socotec(a)list.sys4.de awaits moderator approval [Sie erhalten nicht h?ufig E-Mails von socotec-bounces(a)list.sys4.de. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] Your mail to 'socotec(a)list.sys4.de' with the subject Emails & Aufgaben Is being held until the list moderator can review it for approval. The message is being held because: The message is larger than the 40 KB maximum size Either the message will get posted to the list, or you will receive notification of the moderator's decision.

1 0

WG: Re: Antwort: Erstellung der Mail-Liste xyz@socotec.de <-> foo.bar@canzler.de / zpp.de / socotec.de
by thomas.korus＠canzler.de 07 May '25

07 May '25

und jetzt nochmal an die Maillingliste... das ist so ungewohnt ;) 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 ----- Weitergeleitet von Thomas Korus/canzler am 07.05.2025 11:43 ----- Von: Thomas Korus/canzler An: "Patrick Ben Koetter" <p(a)sys4.de> Datum: 07.05.2025 11:43 Betreff: Antwort: [socotec] Re: Antwort: Erstellung der Mail-Liste xyz(a)socotec.de <-> foo.bar(a)canzler.de / zpp.de / socotec.de Guten Morgen allerseits! Ja ging um die bei MS angelegten Socotec.de Mailadressen. Hier hat wohl jede Person für sich selbst entscheiden dürfen, ob eine Weiterleitung auf die eigene Canzler/ZPP... Adresse angelegt wird oder nur ein Webmailzugang ausreichend ist. Jens schrieb es schon für ZPP und nun gibt es auch für Canzler Klarheit: Hier müssen wir nichts gesondert beachten. Nach den Veränderungen in der Geschäftsleitung ist es nur noch eine Adresse und die dort eingehenden Mails sind bisher -sachlich formuliert- irrelevant. Es wird dann auch keine Sonderlösungen geben müssen. Sprich: Dieses Thema als erledigt betrachten. Restliche Fragen waren auch von mir und die habe ich unten IN GROßBUCHSTABEN zur besseren Lesbarkeit beantwortet 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: "Patrick Ben Koetter" <p(a)sys4.de> An: socotec(a)list.sys4.de Datum: 07.05.2025 10:03 Betreff: [socotec] Re: Antwort: Erstellung der Mail-Liste xyz(a)socotec.de <-> foo.bar(a)canzler.de / zpp.de / socotec.de ¡Hola! * thomas.korus(a)canzler.de <thomas.korus(a)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. S.O. ERLEDIGT > 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. JA ICH MEINTE DEN BF. > 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(a)socotec.de auch immer unter dieser Adresse erreichbar sein wird und die Adresse bei einer Kollisionsauflösung nicht plötzlich thomas.korus02(a)socotec.de wird und der neue Thomas dann unter thomas.korus01(a)socotec.de erreichbar wird. DAS IST EIN GUTER HINWEIS, ANSONSTEN REST VERSTANDEN. ICH GLAUBE DER FILEBASIERTE ANSATZ SOLLTE AUSREICHEN, AUCH DER KOMPLEXITÄT / ANGREIFBARKEIT DES SERVERS WEGEN. HAST DU ODER JEMAND ANDERES EINE IDEE FÜR EINE MÖGLICHST AUTOMATISIERTE VALIDIERUNGS & KOLLISIONSPRÜFUNG? > 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(a)canzler.de zu vorname.nachname(a)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. EINE ENTSCHEIDUNG DAZU WIRD ES KURZFRISTIG GEBEN. TOBIAS HAT U.A. DIES GESTERN DEN HERRSCHAFTEN PRÄSENTIERT DAMIT DIESE SICH GEDANKEN MACHEN KÖNNEN. > 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? JA HABEN WIR. DA SORGE ICH SCHON FÜR. ES WAR EHER EINE GRENERELLE FRAGE NACH DER SINNHAFTIGKEIT. WIR SOLLTEN NACH UND NACH UNSERE INTERNEN SYSTEME ERTÜCHTIGEN (AUCH) MIT SOCOTEC.DE ZU SENDEN Wie aufwändig wäre es, Eurem bestehenden Mailserver beizubringen er sei *auch* für socotec.de-Empfänger zuständig? LOKAL RECHT GERING + GANZER DNS-KRAM, CARSTEN KANN MEHR DAZU SAGEN > 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"? NICHT UMGESCHRIEBEN, MACHT JA KEIN SINN. SPAMFILTERUNG LÄUFT FÜR ALLE GLEICH > 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(a)zpp.de> > An: thomas.korus(a)canzler.de, tr(a)zpp.de > Datum: 02.05.2025 11:40 > Betreff: Erstellung der Mail-Liste xyz(a)socotec.de <-> > foo.bar(a)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(a)socotec.de -> js(a)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(a)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(a)list.sys4.de > To unsubscribe send an email to socotec-leave(a)list.sys4.de -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein _______________________________________________ Socotec mailing list -- socotec(a)list.sys4.de To unsubscribe send an email to socotec-leave(a)list.sys4.de

1 0

selektives ausgehendes Mailrouting
by Jens Seiler 07 May '25

07 May '25

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 1) ausgehende Mails der jeweiligen Firma regelbasiert entweder den traditionellen Weg gehen oder über den neuen Boundary Filter oder 2) 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? 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(a)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

2 1

Whitelist für externe Clients (hier Scanner)
by thomas.korus＠canzler.de 07 May '25

07 May '25

Falls relevant bei der Betrachtung: Wir haben einige Projektbüros wo wir Konica Multifunktionsdrucker haben. Diese nutzen die Kollegen in Massen für die Scan2Mail Funktion mit bis zu 50 MB PDF Anhängen. Da vor Ort kein weiterer Server (möglich bzw.) vorhanden ist, wird direkt unser Mailserver angesprochen. Das ist immer ein ziemliches Gefummel mit der Filterung und dem Whitelisten. Schön wäre, wenn wir hier eine Konfiguration bauen, die problemlos mit diesen Geräten funktioniert und deren Mails auch bei Angriffen durchgelassen werden (ggf. mit Authentifizierung mailen?). 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

2 1

Mailrouting: Wer macht was wann wo?
by Patrick Ben Koetter 02 May '25

02 May '25

Hi! Ich möchte das etwas komplexere Thema Mailrouting auf dem Boundary Filter (BF) bald in den Griff bekommen, damit uns da in der Umsetzung nichts fieses erwartet. Je nachdem welche wir Anforderungen wir haben, kann das durchaus negative Auswirkungen auf DKIM-Signaturen im internen Mailaustausch zwischen den Töchtern der Holding nach sich ziehen. Also lieber bald eine Runde Hirnschmalz einsetzen. :) Mein Verständnis ist aktuell: Alle Mails - ein- wie ausgehend - für alle Töchter der Holding laufen in Zukunft über das Boundary Filter. Wir werden bis Ende Mai nicht alle Töchter auf das BF ziehen, aber mittelfristig ist das unser Ziel. Boundary Filter - Das BF schreibt jede eingehende @socotec.de-Empfängeradresse auf die (alte) Adresse in der Zieldomain der Tochter um - mit Ausnahme der Adressen, welche bereits @socotec.de sind. - Das BF schreibt jeder ausgehende Senderadresse auf @socotec.de um - mit Ausnahme der Adressen, welche bereits @socotec.de sind. Cancler - Cancler sendet bis auf weiteres von seinem Standort als cancler.de - Cancler empfängt bis auf weiteres an seinem Standort für cancler.de - Alle Mails, die von @cancler.de über das BF gehen - auch jene an Töchter der Holding - werden auf @socotec.de umgeschrieben. ZPP - ZPP sendet bis auf weiteres von seinem Standort als zpp.de - Zpp empfängt bis auf weiteres an seinem Standort für zpp.de - Alle Mails, die von @zpp.de über das BF gehen - auch jene an Töchter der Holding - werden auf @socotec.de umgeschrieben. Socotec - Alle Mails für die 20 socotecs werden am BF angenommen und zu MS geroutet - Alle Mails von den 20 socotecs werden von MS zum BF geroutet und von dort aus dann weiter transportiert. Ist es das, was wir wollen? p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

2 2