Mailadressierung Friendly Name ohne Hochkommas

  • Hallo zusammen,
    das Thema wurde ja schon ein paar mal angesprochen, es ist auch soweit alles richtig eingerichtet. Wir benutzen eine Lotus Domino 8.5.3 Umgebeung.


    Einige Mails, die von uns von extern empfangen werden, werden nicht korrekt (Hochkommas) dargestellt.
    Sobald in dem Friendly Name ein Sonderzeichen enthalten ist, sei es ein Umlaut, ein Komma oder ein Punkt, wird der Friendly Name vor der eigentlichen E-Mail-Adresse in Hochkommas gesetzt.
    Durch tagelanges experimentieren habe ich herausgefunden, dass wenn ein Umlaut UND ein Punkt in dem Frindly Name vorhanden sind, die Hochkommas nicht gesetzt werden.
    Das ist weitzer nicht so tragisch, solange nicht auch noch ein Komma vorhanden ist (Problematik mit der nicht funktionierenden "Antwort-Funktion).
    Genau diese Konstillation kommt bei uns in der letzten Zeit aber ziemlich oft vor.
    Kennt Jemand von Euch dieses Verhalten/Problem und weiß eine Lösung? (außer den Absender auf die RFC-Standards hinzuweisen X( )

  • Hi Torsten,
    ja, die Links kenne ich. Die Parameter hatte ich auch noch einmal in die notes.ini auf dem SMTP-Server eingetragen. (sollten eigentlich durch Fixe schon integriert sein).
    Grundsätzlich funktioniert dies auch, das erkenne ich daran, dass Leerzeichen entfernt werden.
    Aber bei meiner oben geschilderten Konstillation funktioniert es dann doch wieder nicht!
    Wahrscheinlich hat das noch keiner ausprobiert/gemerkt oder war davon betroffen.
    Kannst Du bei Dir ja mal ausprobieren, wenn man z.B. von einem Gmail-Account versendet, dann kann man den FrindlyName schnell verändern.
    Ich will dann aber auch kein großes Faß aufmachen, wollte nur wissen, ob es schon mal aufgefallen ist oder ob es evtl. bereits eine Lösung gibt.


    Gruß
    Thomas

  • Da hast Du was falsch verstanden:


    Der Parameter setzt einen Friendly- Name in "Hochkomma", wenn dieser keine enthält.


    Das hat in bestimmten Versionen nicht funktioniert, wenn der Friendly- Name zusätzlich ein Sonderzeichen enthalten hat, weil dann der Friendlyname iso-8859-1 kodiert war, und dadurch das Komma nicht sauber erkannt wurde.
    DAS wurde gefixt. Den Parameter braucht man aber trotzdem.

  • Den Parameter habe ich ja auf jeden Fall in der notes.ini gesetzt.
    Folgende Situationen habe ich:
    - Kommt ein normaler FrindlyName herein, werden vom Domino keine Anführungszeichen gesetzt, soweit gut.
    - Kommt ein Frindlyname mit Umlaut herein, werden vom Domino keine Anführungszeichen gesetzt, soweit gut.
    - Kommt ein Frindlyname mit Sonderzeichen wie ein Punkt oder ein Komma herein, setzt der Domino richtigerweise Hochkommas, soweit auch gut.
    - Kommt ein Frindlyname mit Umlaut und dem Sonderzeichen Komma herein, setzt der Domino richtigerweise Hochkommas, soweit auch gut.
    - Kommt aber ein Frindlyname mit Umlaut und dem Sonderzeichen "Punkt" herein, setzt der Domino die Hochkommas plötzlich nicht mehr! Nicht gut.
    Und wenn in diesem Fall auch noch ein Komma vorhanden ist, dann habe ich den Salat.


    Da fehlt mir jetzt die Systematik.

  • Wieso ist das mit dem Punkt ein Problem wenn es keine Hochkommas gibt ?


    Der Notes.ini Parameter setzt die Hochkommas nur bei Kommas und Strichpunkten, weil das die einzigen Zeichen sind, die Domino in diesem Fall als Trennzeichen interpretiert.
    Siehe Doku zu dem Parameter.


    Zur vollständigen Behebung der Fehler eines externen Systems ist der Parameter weder gedacht noch geeignet.


    Der Parameter behebt das Problem nur in dem Fall wenn Domino/NOtes damit ein Problem hat

  • Der Notes.ini Parameter setzt die Hochkommas nur bei Kommas und Strichpunkten, weil das die einzigen Zeichen sind, die Domino in diesem Fall als Trennzeichen interpretiert.
    Siehe Doku zu dem Parameter.

    Grundsätzlich macht der Parameter das auch, aber nicht, wenn auch noch ein Umlaut und ein Punkt vorhanden ist.
    Ist egal. In den Fällen wo es uns auffällt, werde ich die Absender über ihre "Inkompatibilität" aufklären.

  • Im Header kann ich ISO-8859-1 Kodierung erkennen.
    Aber: wenn Du das wirklich spasseshalber mal ausprobieren möchtest, dann nimm Dir einen GMail-Account und verändere hier die Konstillationen des Frindly Name Bereiches beim Senden.
    Im Notes kannst Du die Auswirkungen dann sofort erkennen (hoffentlich auch bei Dir).

  • Den Test habe ich auch gerade mal durchgeführt und wie bei Tode kommt der Absender korrekt an. Ebenfalls ohne daß der Domino Parameter gesetzt ist


    Habt ihr da evtl noch ein anderes Systems dazwischen (Spam/Virenscanner,...) wo da evtl dazwischenfunkt ?

  • Unsere Datenverarbeitungszentrale/Provider hat mehrere Spam und Virenscanner dazwischen ....
    Dann scheint es wohl eher mein Problem zu sein wenn es bei Euch funktioniert.
    Das wird doch hoffentlich nicht an meiner Domino-Version liegen?! Wir haben ja noch 8.5.3 FP6 ....
    Es gibt schlimmeres, als diesen "Umstand", es stört mich nur ein wenig, dass mich die Admins aus der Exchange-Fraktion (Absender) so komisch von der Seite anmachen (zwinker).

  • Nein an der Version liegt es nicht, da wir beide wie gesagt den Parameter gar nicht gesetzt haben, d.h. der Domino den Absender so behandelt wie er ankommt.


    Und wenn er bei euch anders ankommt dann deutet das eher auf eine Umkonvertierung vor dem Domino hin

  • Exchange ist jetzt genau das richtige Stichwort: WUSSTEST Du, dass Exchange/Outlook in seinen Mails, die einen nicht RFC- konformen Absender senden (und das scheint eine häufige Fehlkonfiguration im Exchange zu sein) ein WEITERES Item mitsendet, in dem der Absender nochmal anders kodiert drin steht, und das nur Outlook / Exchange versteht?


    Dadurch macht MS (natürlich vollkommenm unabsichtlich) allen Mailsystemen Probleme, die dieses zusätzliche Flag nicht verstehen, und zwingt diese zu Workarounds, um den nicht-RFC-konformen Mist doch korrekt zu interpretieren...


    ... Ein Schelm, der Böses dabei denkt...

  • Moin, Moin,


    vielen Dank für deine Vorarbeit. Wir haben sporadisch auch das gleiche Problem.
    Mit deinen Infos konnte ich den Fehler eingrenzen und nachstellen (einfach per Telnet / SMTP eine E-Mails selber zusammenbauen).
    NAchstellen per Google und co funktioniert nicht, da diesen die Friendly Name Funktion RFC konform implementiert haben.
    Eigentlich Ursache sind alte Exchange Systeme, die den Friendly Name nicht sauber implementiert haben. Bei einem Fall habe ich den Absender kontaktiert, er verwendet Exchange 2003....


    Einen PMR ist zu diesem Thema bei der IBM offen und der Fehler als solches bestätigt. Aktuell arbeitet der Support an einem Cutom Fix auf Basis 9.0.1 FP6.
    Wenn ich etwas konkretes habe (SPR Nummer o.ä.) lasse ich es euch wissen.

  • Moin, Moin zusammen,


    aus dem PMR wurde folgender SPR TPON949L2M
    LO73648: SOME INSTANCES OF DELIMITED ADDRESSES ARE NOT CORRECTED WITH FIX FOR APAR LO60875 / SPR TPON8GYCM8
    http://www-01.ibm.com/support/search.wss?q=TPON949L2M


    Ich habe einen Testfix erhalten und dieser funktioniert soweit einwandfrei. Allerdings wird der Fix es wohl nicht ins Fixpack 7 schaffen. Ob der Fix in einem späteren Fixpack od. Major-Release eingebaut wird, hänge laut Support u.a. auch vom Umfang des Kundenfeedbacks ab.


    Wer betroffen ist (oder sein könnte) möge unter o.g. SPR einen Fix beantragen.


    Beste Grüße aus dem Münsterland