Hallo alle zusammen. Wir setzen in unserer Umgebung iMedONE der Telekom ein und haben uns somit auch für die KIM Emails der Telekom entschieden. Die KIM Email Umgebung ist laut Telekom-Support richtig eingerichtet und könnte schon produktiv verwendet werden. Nun haben wir das Problem, dass Emails, die über unsere Telekom KIM verschickt werden komischerweise weder bei CGM TurboMed noch bei ISYNET ankommen. Wir haben hierzu 2 externe Arztpraxen kontaktiert, mit der Bitte um Prüfung des Email-Eingangs. Jedoch kamen und kommen bei diesen Arztpraxen keine unserer Emails an.
Emails, die z.B. über TurboMED an unsere Telekom KIM-Adresse geschickt werden, sind kurze Zeit später in unserem Posteingang. Das versenden innerhalb der Telekom KIM funktioniert ebenfalls ohne Probleme.
Wie gesagt.. laut Telekom sind der SecuNET Konnektor und der KIM-Client korrekt eingerichtet. Auch laut den LOGS ist für die Telekom kein Fehlverhalten der beiden Komponenten ersichtlich.
Hier nochmal kurz gefasst:
Telekom KIM -> Telekom KIM: Versenden ja, Empfang ja Telekom KIM -> ISYNET : Versenden ja, Empfang nein Telekom KIM -> TurboMED : Versenden ja, Empfang nein TurboMED -> Telekom KIM : Versenden ja, Empfang ja
Hat hier jemand eventuell das selbe Phänomen, oder schon was ähnliches gehabt / gehört?
prüfen sie die Portfreigabe der Firewall auf dem Server (Standard sollte 465, 995 und 8083 sein) und die E-Mailprüfung ausgehend mal abschalten, am Client und am Server und damit mal testen.
Wurden diese Testmails als Arztbrief versandt oder als normale Emails mittels eines Emailclients? Viele Systeme ignorieren solche Emails und zeigen daher auch den Eingang nicht an.
Haben sie eine Empfangsbestätigung beim Versand angefordert? Kam diese an?
Über die clientmodule.xml / log4j2.xml Config Dateien kann man das Logging des Telekom KIM Clientmoduls massiv erhöhen, dann kann man in den Logs auch sehen, ob die Mail erfolgreich an den SMTP Server der Telekom zugestellt wurde.
Mit freundlichen Grüßen, Reinhard Schürer nascom GmbH
Hallo. Guten Morgen :) Erst mal vielen Dank für die Antwort. Selbiger Lösungsvorschlag kam auch schon seitens T-Systems. Aber auf dem KIM-Client ist die Firewall ausgeschaltet. Komischerweise kam heute Morgen eine Test-Email in TurboMED an, die wir vor 4 Tagen aus iMedONE verschickt hatten...
wir verschicken direkt aus iMedONE heraus.. als eNachricht. Wenn wir von TurboMED an iMedONE schicken, muss der Empfang bestätigt werden. Aber auch diese Bestätigung, die dann quasi wieder aus iMedONE geschickt wird, kommt bei TurboMED nicht an. Wie bereits geschrieben, kam heute Morgen eine Test-Email an, die wir am 29.07.2022 von iMedONE aus an eine TurboMED KIM-Adresse geschickt hatten. Also mit 4 Tagen Verzögerung. Ist wirklich seltsam das Ganze.
Bezüglich der XML-Dateien, hatte der T-Systems Support bereits was daran geschraubt. Laut T-Systems gehen die Emails ordnungsgemäß raus. Irgendwie fühlt sich nun keiner so richtig zuständig. Ist schon traurig so was.
Eine Empfangsbestätigung kommt direkt vom Mailserver nicht vom Client. Nur eine Lesebestätigung würde der Client generieren.
Wir haben beim Kunden das seltsame Phänomen das eAUs zwar bei den Krankenkassen ankommen, aber die angeforderte Empfangsbestätigung nur von manchen Kassen zurückkommt.
Bei der Nachricht die 4 Tage unterwegs war wäre es natürlich interessant gewesen zu sehen an welchem Mailserver das hing, aber leider zeigen die meisten System ja keine Mailheader an, so dass man dies nur in den Tracelogs finden könnte.
Der T-Systems Support hatte sich das hier auch schon mehrfach angesehen aber der Versand bis zum Telekom Mailserver funktioniert ja (von einer Störung des Servers und dessen Load Balancers mal abgesehen). Und der Versand zwischen Telekom KIM Adressen funktioniert ja auch problemlos.
Das Problem scheint zwischen den Mailservern der verschiedenen KIM Anbieter / Krankenkassen zu liegen.
Grüße, Reinhard
1 Mitglied findet das Top!
1 Mitglied hat sich bedankt!
ja. Genau. Es kann ja folglich nur an den Mailservern der verschiedenen Anbietern liegen. Wie du schon sagtest.. T-Systems iMedONE zu iMedONE funktioniert ohne Probleme. Auch der Versand von CGM TurboMED zu T-Systems iMedONE macht keine Probleme, bis auf die Lese- / Empfangsbestätigung. Die kam noch nie in TurboMED oder iMedONE an. Supporttechnisch schiebt es der eine immer auf den anderen, was mittlerweile total abnervt. Auf jeden Fall ist hier noch ne Menge Verbesserungsbedarf.. dass das Ganze nicht in einem Desaster endet.
Hallo. Ich hatte am 12.08. eine Email vom T-Systems Support bekommen, dass wohl Interoperabilitätsprobleme (bei Antwort-Mails) auf KIM-Mailserver-Kommunikationsebene die Ursache waren. Diese wurden dann am 10.08. Nachmittags behoben. Nach ausgiebigem Testen kann ich nur eine geringfügige Verbesserung feststellen. Die KIM-Mails von iMedONE kommen nun nicht mehr mit 3 Tagen Verzögerung an.. die längste brauchte ca. 2 Stunden, bis sie in TurboMED zu sehen war, die kürzeste etwa 10 Minuten (was noch einigermaßen innerhalb der Toleranzgrenze liegt). Aber im allgemeinen gesehen, funktioniert das Ganze noch immer nicht wie es sollte.
Hallo. Aktuell funktioniert wieder nichts. Ich verschicke aus iMedONE an TurboMED, aber dort kommt nichts an. Auch keine Lese- und Empfangsbestätigungen.
die Telekom hatte vorgestern einen ausgiebigen Troubleshooting Tag remote bei uns eingelegt. Das Problem wurde fast vollständig analysiert. Das iMedONE KIM Modul hat wohl einen BUG, der, trotz der erhöhten 500MB Grenze, nicht mehr als max. 20MB zulässt. Uns wurde eine Nachricht mit einem Anhang von 23MB und zwei Nachrichten mit einem Anhang von je 8MB zugeschickt, die das KIM Modul einfach nicht abrufen konnte. Somit kamen auch keine nachfolgenden Nachrichten mehr durch. Die Telekom hatte das durch extremes hochsetzen des LOG-Levels analysiert. Zum Testen hat der Support einen Thunderbird eingerichtet, der die Nachrichten dann auch abrufen konnte. 48 waren in der Abrufschleife :/ Der Versender hatte wohl auch über Thunderbird verschickt und von daher auch keine Nachricht bekommen, dass die Email zu groß ist, da Thunderbird diese Größe handeln kann. Da soll man mal als Empfänger einer Nachricht erst mal dahinter kommen... Auf jeden Fall ist das Ganze an die iMedONE Entwicklung weitergegeben worden. Dann hoffen wir mal auf eine schnelle Lösung. Notfalls wird halt temporär erst mal Outlook oder Thunderbird eingesetzt.
LG Mirco
1 Mitglied findet das Top!
1 Mitglied hat sich bedankt!
Danke für die Rückmeldung. Hier sollte auf jeden Fall noch mal auf den KIM-Clientmodul-Hersteller des Absenders zugegangen werden. Das KIM-Clientmodul muss Nachrichten, mit mehr als 25 MB ablehnen - auch an Thunderbird. (Anforderung KOM-LE-A_2004) Es muss daher für den Absender deutlich werden, dass der Versand nicht geht. Wenn die Mail dennoch verschickt wurde, liegt scheinbar ein Fehler beim Absender vor.
Ausnahme: Wenn der Absender erkennt, dass der Empfänger (!!) bereits KIM 1.5. hat und somit Anhänge bis 500 MB empfangen kann, dann darf natürlich auch mehr verschickt werden. Aber das ist ja im Feld bislang noch nicht angekommen.
Zitat von MLangguth im Beitrag #13Das KIM-Clientmodul muss Nachrichten, mit mehr als 25 MB ablehnen - auch an Thunderbird. (Anforderung KOM-LE-A_2004)
Das gibt m. E. die Anforderung aber nicht her.
KOM-LE-A_2004 lautet wie folgt: Das KOM-LE-Clientmodul MUSS Nachrichten mit einer Nettogröße von bis zu 25 MB bearbeiten können. Dabei ist zu beachten, dass sich durch die base64-Kodierung der Nachricht die zu verarbeitende Bruttogröße um den Faktor 1,37 erhöht.
Meine Vermutung ist, dass der Hersteller, wer auch immer das ist, lediglich darauf geachtet hat, dass mindestens 25 MB nebst Zuschlag v. 1,37 vom KIM-Clientmodul verarbeitet werden können. Eigentlich hätte die Anforderung auch eine Größenbeschränkung, wie von Ihnen ja letztlich erwartet, beinhalten müssen - tut sie aber nicht. Auf Empfängerseite wurden die Mails ja auch (nach Umkonfiguration) abgeholt. Der T-Systems-Client hat da also auch mehr als die 25 MB verarbeitet (denn mit Thunderbird kann ja abgeholt werden), der Empfang ist dann aber bei iMedOne gescheitert.
Insofern wäre eine Anpassung der Anforderung wohl sinnvoll.
Ups, Sie haben Recht, der Umgang mit "zu großen" Anhängen kam erst in KIM 1.5 hinzu:
Zitat A_19356-04 - Prüfen der Version des Empfängers Das KOM-LE-Clientmodul MUSS die vom Empfänger verwendete KOM-LE-Version prüfen. Das KOM-LE-Clientmodul MUSS dazu die KOM-LE-Version mittels des LDAP-Directory Attributs: komLeData aus dem Verzeichnisdienst [gemSpec_VZD#5] abfragen. Ist das LDAP-Directory Attribut: komLeData für den Empfänger undefiniert, dann muss ein KOM- LE-Clientmodul mit einer Version 1.0 angenommen werden.
Wenn eine Mail größer als 25 MB an einen Empfänger mit KOM-LE-Version < 1.5 versendet werden soll, MUSS das KOM-LE-Clientmodul diesen Empfänger aus der Mail entfernen. Beim Entfernen eines Empfängers MUSS das KOM-LE-Clientmodul den Absender mit einer E-Mail über den Fehlerfall informieren. Aus dem Inhalt der Fehlernachricht müssen alle aus der Mail entfernten Empfänger hervorgehen. Die Fehlernachricht ist weder zu signieren noch zu verschlüsseln und entsprichtder Delivery Status Notification gemäß [RFC3461-3464]. Kann die Mail für keinen der Empfänger versendet werden, wird das Senden der Nachricht abgebrochen. Dabei wird dem MTA das RSET-Kommando gesendet und das Clientsystem wird mit dem SMTP-Antwortcode 451 über den Fehlerfall informiert.
Davor, sprich für KIM 1.0, sollte der Hersteller mitdenken, und nicht versuchen größere Anhänge zu verarbeiten...
TI-Community
»
TI-Nutzung und Nutzen aus Anwendersicht
»
sichere eMail (KIM)
»
KIM-Emails von Telekom KIM
Thema drucken
01.08.2022 14:34
Antworten
