Darstelluingsprobleme bei übernommenen Mails

[Axel]

Hi,

ein Problem tritt allerdings bei der Übernahme der Mails in eine eigene DB (siehe http://www.atnotes.de/index.php?topic=24480.0) noch auf.

Ich habe ein Mail, in dem, im Body Bilder eingefügt wurden. Im Body-Feld finde ich aber keinen HTML-Text, sondern nur einen Hinweis auf das Mime-Format. Das Mail hat auch ein $File-Feld.

In der Übernahme-Routine habe ich eine Abfrage, ob Dateianhänge mit übernommen werden sollen oder nicht. Bei "Nein" werden alle Attachments im Body Feld gelöscht.

Code

...
If intAttachment = 0 Then  'Wenn Dateianhänge nicht übernommen werden sollen, werden sie hier gelöscht
  If docNew.HasEmbedded Then
    Set rtitem = docNew.GetFirstItem("Body")    
    If rtitem.Type = RICHTEXT Then
       If Not (Isempty(rtitem.EmbeddedObjects)) Then
         Forall objects In rtitem.EmbeddedObjects
           If objects.Type = EMBED_ATTACHMENT Then
	Call objects.Remove
           End If  'If objects.Type = EMBED_ATTACHMENT 
         End Forall  'Forall objects In rtitem.EmbeddedObjects
       End If  'If Not (rtitem.EmbeddedObjects Is Nothing) Then
     End If  'If rtitem.Type = RICHTEXT 			
  End If   'If refdoc.HasEmbedded
End If  'If intAttachment = 0 Then
...

Das Problem bei diesem speziellen Mail in nun folgendes: wird die Frage nach der Übernahme der Anhänge mit "Nein" beantwortet, werden die Bilder nun noch als [Image] und der Text nicht sauber formatiert angezeigt. Bei "Ja" wird das Mail sauber übernommen.

Ich habe mal ein paar Test gemacht und dabei festgestellt, dass er bei dieser Anweisung

Set rtitem = docNew.GetFirstItem("Body")   

die Formatierung zerrreißt.

Warum? Ich habe im moment keine Erklärung dafür?


Axel

[TMC]

Hi Axel,
nur ein Schuß ins blaue:
Wie ist rtitem deklariert, als NotesRichtextitem?
Ich hatte mal in R5 Probleme mit dieser Deklaration, nur zum Testen würde ich es mal als Variant deklarieren.
Wobei das natürlich nur ein Workaround wäre, ohne zu wissen woran das Verhalten liegt...

Matthias

[Semeaphoros]

[ot]
Oooops, da hab ich im zweiten Absats doch tatsächlich Body Builder gelesen statt Body Bilder ..... 
[/ot]

Das sind ja wie es scheint Internet-Mails im Mime-Format. Tatsächlich ist es so, dass eingebettete Bilder in dieser Situation als Anhänge zählen, heisst, das Verhalten ist damit, wenn man bei der Uebernahme Attachements nicht übernehmen will, eigentlich korrekt. Ob es einen Workaround dazu gibt, hab ich keine Ahnung.

[TMC]

Vielleicht ist auch der Body bebildert (Tätowierungen) 

Tatsächlich ist es so, dass eingebettete Bilder in dieser Situation als Anhänge zählen

Ah, ok, das erkärt das ganze Verhalten natürlich, ich denke dann bringt auch mein Tipp hier nichts. Workaround der mir hier noch einfällt wäre DXL.

[koehlerbv]

Ich bin mir auch ganz sicher, dass man da ganz tief eindringen muss. MIME-kodierte Mails haben ganz fix mal Bestandteile, die nicht im Body, sondern als $File(s) gespeichert werden.
Ich denke, das proprietäre Format von Notes (in diesem Zusammenhang sicherlich richtig gebraucht als Begriff, oder ?) fällt uns hier durchaus auf die Füsse.

Thema DXL: Auch hier wird es schwierig, ein "richtiges" von einem "falschen" Attachment zu trennen.

Vielleicht kann man es sich auch einfacher machen: Bei "fraglichen Mails" das Attachment-Löschen verhindern (nicht anbieten) und dies den User im FrontEnd machen lassen.

Bernhard

[Semeaphoros]

Oder Midas einsetzen, dort sind Mime-Funktionen vorhanden (wobei ich nicht auswendig weiss, ob gerade diese Anforderung direkt implementiert ist, aber das lässt sich bei Ben Langhinrichs einfach nachfragen).

http://www.geniisoft.com

[Axel]

Hi,

vielen Dank erstmal für die rege Diskussion

Das sind ja wie es scheint Internet-Mails im Mime-Format. Tatsächlich ist es so, dass eingebettete Bilder in dieser Situation als Anhänge zählen, heisst, das Verhalten ist damit, wenn man bei der Uebernahme Attachements nicht übernehmen will, eigentlich korrekt. Ob es einen Workaround dazu gibt, hab ich keine Ahnung.

Es ist ein Mail im Mime-Format. Das Problem dabei ist, dass es

a) keine Anhänge im klassischen Sinne gibt und

b) der Code zum Löschen von Anhängen gar nicht ausgeführt wird.

Bei der Übernahme nehme ich erstmal alles mit was in dem Mail vorhanden ist, auch die Anhänge, soweit vorhanden. Wenn der User die Abfrage zur Übernahme der Anhänge mit "Nein" beantwortet hat, prüfe ich, ob im Body-Feld Attachments vorhanden sind. Wenn ja werden sie gelöscht.

Hier nochmal den passenden Code dazu:

If intAttachment = 0 Then  'Wenn Dateianhänge nicht übernommen werden sollen, werden sie hier gelöscht
  If docNew.HasEmbedded Then  'ist True
    Set rtitem = docNew.GetFirstItem("Body")   ' hier verreisst es das Format und es sind keine Bilder mehr vorhanden
    If rtitem.Type = RICHTEXT Then
       If Not (Isempty(rtitem.EmbeddedObjects)) Then
         Forall objects In rtitem.EmbeddedObjects
           If objects.Type = EMBED_ATTACHMENT Then
               Call objects.Remove
           End If  'If objects.Type = EMBED_ATTACHMENT
         End Forall  'Forall objects In rtitem.EmbeddedObjects
       End If  'If Not (rtitem.EmbeddedObjects Is Nothing) Then
     End If  'If rtitem.Type = RICHTEXT
  End If   'If refdoc.HasEmbedded
End If  'If intAttachment = 0 Then
...

Das Format wird bereits "verunstaltet" bevor er überhaupt dazu kommen können irgendwelche Anhänge zu löschen. In dem entsprechenden Mail ist rtitem.EmbeddedObjects leer.

Nach Ausführung dieser Zeile Set rtitem = docNew.GetFirstItem("Body") ist das Format kaputt, obwohl alle Infos aus dem Mail noch vorhanden sind.

Hi Axel,
nur ein Schuß ins blaue:
Wie ist rtitem deklariert, als NotesRichtextitem?
Ich hatte mal in R5 Probleme mit dieser Deklaration, nur zum Testen würde ich es mal als Variant deklarieren.
Wobei das natürlich nur ein Workaround wäre, ohne zu wissen woran das Verhalten liegt...

Matthias

Habe ich bereits probiert, ebenfalls mit dem gleichen Ergebnis.


Anscheinend betrifft es im Moment nur dieses eine Mail. Andere Mails die ebenfalls Bilder im Body-Feld enthalten werden sauber dargestellt. Da finde ich aber dann auch HTML im Body-Feld.

Sehr mysteriös das Ganze. Ich tippe auf einen Bug?



Axel

[Manfred Dillmann]

Hallo Axel,

ich habe jetzt nicht den gesamten Thread verfolgt, aber bei "MIME" Mails hätte ich folgendes anzumerken:

Sowohl "embedded pictures" als auch "attachtments" werden in MIME-codierten Mails komplett anders verwaltet und dürfen nach meinen Untersuchungen nicht mehr über die "normalen" RichtextItem Klassen angesprochen werden. Warum?

Wenn du Dir eine solche Mail anschaust, werden embeded pictures z.B. so:
--=_related 002B6D36C125704B_=
Content-Type: image/jpeg
Content-ID: <_2_0404D4140404D1EC002B6D36C125704B>
Content-Transfer-Encoding: base64
...

und attachments so:
--=_related 002B6D36C125704B_=--
--=_mixed 002B6D36C125704B_=
Content-Type: image/gif; name="notes6icon.gif"
Content-Disposition: attachment; filename="notes6icon.gif"
Content-Transfer-Encoding: base64
...

gespeichert. Einen sauberen Zugriff bekommt man nur noch mit der NotesMIMEEntity class bzw. der NotesMIMEHeader class. Ganz wichtig ist es, während der Bearbeitung der MIME-Entities die von Notes in LS sonst automatisch durchgeführte Konvertierung nach Richtext "abzuschalten" ->

ConvertMIME property
Read-write. Indicates whether items of type MIME_PART are converted to rich text upon NotesItem instantiation.

To get: flag = notesSession.ConvertMIME
To set: notesSession.ConvertMIME = flag

Das ganze erscheint mir nicht trivial zu sein. Ich arbeite gerade an meinem neuen Tool madicon easyMail (Erstellung und Versand von personalisierten - also mit frei definierbaren Platzhaltern ausgestattete - Serienmails im MIME-Format mit nahezu vollständiger Unterstützung der im Notes Client verfügbaren Text-Formatierungsmöglichkeiten und Attachments) und träume mittlerweile schon von diesem MIME-Zeugs. 

Die MIME-Unterstützung via der o.g. LS-Klassen scheint zudem nicht ganz fehlerfrei zu sein.

Viel Glück!

Gruß
Manfred

[Axel]

Wenn du Dir eine solche Mail anschaust, werden embeded pictures z.B. so:
--=_related 002B6D36C125704B_=
Content-Type: image/jpeg
Content-ID: <_2_0404D4140404D1EC002B6D36C125704B>
Content-Transfer-Encoding: base64
...

und attachments so:
--=_related 002B6D36C125704B_=--
--=_mixed 002B6D36C125704B_=
Content-Type: image/gif; name="notes6icon.gif"
Content-Disposition: attachment; filename="notes6icon.gif"
Content-Transfer-Encoding: base64
...

Hi,

diese Daten habe ich in der Mail nicht gefunden. Es gibt einen "versteckten" Anhang in $File. Dort vermute ich den gesamten Text und die Grafiken. Warum der bei dem Zugriff mit Set rtitem = docNew.GetFirstItem("Body")  über den Jordan geht ist mir schleierhaft.

Da es sich aber scheinbar um seltene Einzelfälle handelt, werde ich keine größeren Klimmzüge machen. Der User soll in dem Fall dann halt mit Anhängen übernehmen.


Axel
 

[Manfred Dillmann]

Hallo Axel,

>>diese Daten habe ich in der Mail nicht gefunden.<<

Hatte ich nicht dazu geschrieben:
Wenn Du im 6er Notes-Client eine MIME-Mail geöffnet hast, kannst Du dir den "echten" MIME-Gehalt über das Menü 'View' -> 'Show' -> 'Page Source' anschauen.

Diese Infos findest Du i.d.T. nicht unbedingt, wenn Du dir die einzelnen Felder über den Dokument-Eigenschaften-Dialog anzeigen lässt.

>>Da es sich aber scheinbar um seltene Einzelfälle handelt, werde ich keine größeren Klimmzüge machen.<<

Eine weise Entscheidung.
Da wären tatsächlich größere Klimmzüge erforderlich...

Manfred

[Axel]

Wenn Du im 6er Notes-Client eine MIME-Mail geöffnet hast, kannst Du dir den "echten" MIME-Gehalt über das Menü 'View' -> 'Show' -> 'Page Source' anschauen.

Hi,

auch hier finde ich diese Zeilen nicht. Das Ganze sieht wie HTML-Code aus. Der steht aber, wie gesagt, nicht direkt im Body-Feld sondern in einer Datei im Feld $File. Diese Datei ist aber nicht als "normaler Dateianhang" sichtbar.

Ich denke wir sollten hier die Diskussion abbrechen. Es sein denn es hat jemand eine zündende Idee oder entwickelt detektivischen Ehrgeiz. Für Lösungsansätze bin ich weiterhin offen.

Unseren Anwendern werde ich empfehlen die Mail mit Anhängen zu übernehmen.


Axel
 

[Manfred Dillmann]

Hallo Axel,

keine Angst, ist mein letzer Beitrag zu diesem Thema:

>>Das Ganze sieht wie HTML-Code aus.<<

Das ist auch je nach Inhalt der MIME-Mail richtig so. Wenn in der Mail formatierter Text enthalten ist, wird der normalerweise so codiert:

--=_related 002B6D36C125704B_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
...

Hast Du aber einen Anhang, wird der nicht in einem klassischen Richtext-Item gespeichert. Wie zuvor geschrieben:

--=_related 002B6D36C125704B_=--
--=_mixed 002B6D36C125704B_=
Content-Type: image/gif; name="notes6icon.gif"
Content-Disposition: attachment; filename="notes6icon.gif"
Content-Transfer-Encoding: base64

Also nix mehr mit "Embedded/Attached object" im Sinne eines Notes-Richtext-Items. Base64 sieht dann z.B. so aus:

Code

/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwM
DAwMEAwODxAPDgwTExQUExMcGxsbHCAgICAgICAgICD/2wBDAQcHBw0MDRgQEBgaFREVGiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICD/wAARCACBALADAREA
AhEBAxEB/8QAHAAAAgIDAQEAAAAAAAAAAAAAAAUGBwIDBAEI/8QARhAAAQMDAQMHCAUKBQUAAAAA
AQACAwQFEQYSITEHEyJBUWFxFDIzUoGRobEjkrPBwhUXJTRCQ1RicqKCg7LR0hZEU3Pi/8QAGwEB
AAIDAQEAAAAAAAAAAAAAAAQFAgMGAQf/xAA3EQACAQMDAQUGBAYCAwAAAAAAAQIDBBEFEjEhEyIy
...

Das decodiert dann der Notes-Client in Echtzeit beim Öffnen der Mail bzw. wenn man den Anhang speichert.


>>Der steht aber, wie gesagt, nicht direkt im Body-Feld sondern in einer Datei im Feld $File. Diese Datei ist aber nicht als "normaler Dateianhang" sichtbar.<<

Das glaubst Du aber auch nur... der Anhang ist nicht in diesem Feld gespeichert. Schau dir mal die Eigenschaften des Feldes "$File" an. Das ist kein Richtextfeld-Feld und hat die Flags: "ATTACH SIGN SEAL SUMMARY". Kein Richtext-Feld, sonst gäbe es kein "SUMMARY"

Da ist garantiert nicht der Anhang drin (schau mal auf die Größe des Feldes), sondern nur ein paar Infos zum Anhang. Der Anhang ist base64 encoded als MIME-Entity gespeichert. Du kannst in diesem Zusammenhang die Infos aus dem Dokument-Eigenschaften-Dialog vergessen.

>>Ich denke wir sollten hier die Diskussion abbrechen.<<

Mache ich auch mit diesem Post. Glaube mir, es gibt keinen einfachen Weg. Entweder Du gehts mit der NotesMIMEEntity class da ran, oder Du "zerschiesst" Dir die Mail:

Nach Ausführung dieser Zeile Set rtitem = docNew.GetFirstItem("Body") ist das Format kaputt, obwohl alle Infos aus dem Mail noch vorhanden sind.

Genau das meine ich.

Gruß
Manfred

[Axel]

Hi,

danke Manfred für deine Erklärungen. Scheint ein ziemlich komplexes Thema zu sein.

Eine letzte Frage (rein interessenhalber): gibt's dazu irgendwo Infos (Literatur, Links)?


Axel 

[Manfred Dillmann]

Hi,

>>danke Manfred für deine Erklärungen. Scheint ein ziemlich komplexes Thema zu sein.<<

Gerne. Ja, ist komplex. Die NotesDOM* und die NotesMIMEEntity-Klassen haben es in sich. Letztere sind IMHO auch nicht fehlerfrei. Was glaubst Du, wieviele Tage (Wochen) ich schon (in Nebenzeiten, muss ja auch was richtiges Arbeiten) an meinem Serien-Mailer arbeite...

>>Eine letzte Frage (rein interessenhalber): gibt's dazu irgendwo Infos (Literatur, Links)?<<

Ich habe mir das durch Anschauen von MIME-Mails, Referenzen zu MIME im Web (google is your friend) und aus der Designer-Hilfe (Code Beispiele) zusammengefriemelt. TMC könnte ggf. beantworten, ob dieses Thema in der "Domino Programmers Bible" behandelt wird - ich kenne sonst keine Literatur, die direkt dieses Thema behandelt.

Manfred

[Axel]

Hi,

danke nochmals.

Die Programmierbibel ("Domino Programmers Bible") habe ich auch im Regal stehen. Ich werde mal auf die Suche gehen.

Damit ist das Thema erstmal vom Tisch.


Axel

[Manfred Dillmann]

>>Die Programmierbibel ("Domino Programmers Bible") habe ich auch im Regal stehen. Ich werde mal auf die Suche gehen.<<

Schreibe doch bitte noch hier rein, ob in diesem Buch was zu diesem Thema enthalten ist. Wäre dann ein Grund, sich das ggf. mal anzuschaffen...

Manfred

[Axel]

Wird gemacht.


Axel

[koehlerbv]

>>Die Programmierbibel ("Domino Programmers Bible") habe ich auch im Regal stehen. Ich werde mal auf die Suche gehen.<<

Schreibe doch bitte noch hier rein, ob in diesem Buch was zu diesem Thema enthalten ist. Wäre dann ein Grund, sich das ggf. mal anzuschaffen...

Entweder ich bin blind, oder ich sehe nichts mehr: MIME wird dort nur erwähnt, aber als Thema enthalten - leider nein. Das deckt sich dann auch mit meiner Erinnerung ...

Bernhard

PS: Das Buch ist aber trotzdem Spitze. Und manchmal ist es ja auch so, dass 30 Seiten eines dicken Wälzers einem soviel wert sind, dass man trotzdem das ganze Buch kauft.

[Manfred Dillmann]

Hallo Bernhard,

danke für die Info. Schade...

Gruß
Manfred