Re: Antwort: Re: Antwort: Erstellung der Mail-Liste xyz@socotec.de <-> foo.bar@canzler.de / zpp.de / socotec.de
Hi!
* thomas.korus@canzler.de thomas.korus@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@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. 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@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.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@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. 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
Jetzt hab ichs. Mit "Weiterleiten im Internetstil" passt es mit der Maillinglist-Struktur auch aus Notes und ich muss nicht schreien ;).
"Patrick Ben Koetter" p@sys4.de schrieb am 07.05.2025 13:50:22:
Von: "Patrick Ben Koetter" p@sys4.de An: socotec@list.sys4.de Datum: 07.05.2025 13:50 Betreff: [socotec] Re: Antwort: Re: Antwort: Erstellung der Mail- Liste xyz@socotec.de <-> foo.bar@canzler.de / zpp.de / socotec.de
Hi!
- thomas.korus@canzler.de thomas.korus@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.)
Korrekt, der BF routet alle @socotec.de an die Alt-Systeme. Es folgt gleich noch eine andere Mail mit Hinweisen, weil es gerade bei uns auffällt.
Restliche Fragen waren auch von mir und die habe ich unten IN GROßBUCHSTABEN zur besseren Lesbarkeit beantwortet
Schrei nicht so... ;-)
pssst
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. 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
zusein, wir
validieren die Daten bevor sie ins Ansible und von dort dann auf die Plattform kommen. Ansible ist dann was die Validierung angeht rausund
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.
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@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. 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.
ja, aber was du wissen solltest ist, dass wir seit ein paar Monaten keine Postfächer mehr auf dem Mailserver haben um die eingehenden Mails zwischenzuspeichern. Die Mails werden direkt an das HCL Domino/Notes System gepusht, sofern die die ganzen Filterungen überstehen. Wie aufwändig das wäre, dies -sofern nötig- als Backup bei eventuellen Fehlkonfigurationen wieder einzurichten kann ich nicht abschätzen.
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
Socotec mailing list -- socotec@list.sys4.de To unsubscribe send an email to socotec-leave@list.sys4.de
participants (2)
-
Patrick Ben Koetter -
thomas.korus＠canzler.de