.: Daniel Melanchthon :.

Banging your head against a wall uses 150 Calories an hour.

Threadingprobleme mit Outlook?

Threadingprobleme mit Outlook?

  • Comments 2
  • Likes

Email ist im Normalfall eine bidirektionale Angelegenheit. Man nennt so etwas auch Kommunikation. Dazu ist es ganz praktisch, wenn man im Mailclient die jeweils zu einem Thread gehörenden Nachrichten sauber untereinander chronologisch dargestellt bekommen kann. Outlook war in der Vergangenheit oft dafür kritisiert worden, dass es die dazu gehörenden Headereinträge In-Reply-To oder References nicht setzen würde, wie es RFC 2822 verlangt:

Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate, as described below.

Nun kann man über den Begriff SHOULD in RFCs hin und her diskutieren - es ändert jedoch nichts daran, dass man als Outlook-Benutzer sich sehr unbeliebt im Internet machen kann, wenn man zum Beispiel in Mailinglisten antwortet und die eigene Nachricht nicht richtig einsortiert werden kann. Das Problem ist jedoch, dass nicht wirklich Outlook der Übeltäter ist.

Outlook nutzt intern PR_CONVERSATION_INDEX und PR_CONVERSATION_TOPIC zum Threaden. Für Internet-Emails werden dagegen In-reply-to und References im Header benutzt. Outlook setzt diese Header richtig, wenn es als POP3/IMAP4/SMTP-Client benutzt wird. Nur wenn es als MAPI-Client an Exchange arbeitet (oder wenn man Outlook Web Access ohne S/MIME-Plugin benutzt), übergibt es an Exchange die Nachricht im MAPI-Format. Dieser konvertiert die Nachricht dann in MIME und dabei wird "In-reply-to" und "References" nicht gesetzt (bis Exchange 2003).

Dafür gibt es mit Exchange Server 2003 does not include the "In-reply-to" header field when you use Outlook or Outlook Web Access to reply to an e-mail message that originated from outside the organization schon seit fast einem Jahr einen Hotfix, der das Problem behebt. Anscheinend ist dieser Hotfix aber nicht sehr bekannt, daher hier der Hinweis für die Exchange-Administratoren, wie sie mit Exchange 2003 das Problem beheben können.

Eine weitere Möglichkeit ist natürlich auch die zukünftige Umstellung auf Exchange 2007, damit ist das Problem auch nicht mehr existent. Ich kann aber verstehen, wenn das allein für eine Migrationsentscheidung nicht wirklich ausreicht. Deshalb liefer ich auf der nächste Woche beginnenden LOVE-Launchtour sowie den drei Webcast-Teilen zu Exchange Server 2007 gern weitere Argumente :-)

Comments
  • Ich finde es fürchterlich, wie Exchange und Outlook mit MIME-Mails umgehen: Da werden ständig Inhalte vernichtet.

    Neustes Beispiel für den Wahnsinn:

    BCC-Header verschwinden: (Entdeckt, beim Versuch Journaling-Nachrichten mit BCC-Regkey per POP3 abzuholen)

    Man schreibe mit Outlook Express eine Mail mit BCC drin. In den Headern taucht BCC auf, man kann in seinen Gesendeten Objekten gut nachverfolgen, wem man wann etwas per BCC gesendet hat.

    Dann schiebe man diese Mail per IMAP in einen Ordner eines Exchangekontos.

    Exchange speichert es in der STM-Datenbank für MIME-Streams. Holt man es ab, sieht man den BCC-Header, alles okay.

    Benutzt man jetzt einen MAPI (Würg)-Client wie Outlook und verschiebt diese Mail in dem Exchangekonto in den Posteingang oder sonstwohin und holt es per POP3 oder IMAP ab, so ist der BCC-Header vernichtet.

    Genauso wenn man per Outlook eine Mail mit BCC sendet und dann per IMAP in die gesendeten Objekte guckt.

    Desweiteren zerstört Outlook wenn es per POP3 abholt NDRs. Oft enthalten diese noch einen Teil der Nachricht, was ja nicht uninteressant ist, insbesondere zur Spamverfolgung. Abholen mit Outlook ändert die SChriftart und macht einen Dummy-NDR im MAPIFormat draus. Alle Informationen die vorher da waren sind unwiderruflich vernichtet.

    Nächstes:

    Oft sehe ich mit Exchange/Outlook Mail Header, wo Received-ZEilen komplett in eine Zeile gequetscht werden.

    Noch ein Problem:

    Leitet mir jemand mit GMX eine HTML-Mail weiter, so ist es eine Textmail mit HTML-Files als Anhang. Ich habe ein Zeit parallele Mailsysteme benutzt: Outlook holt es per POP3 ab, und der Text der Person, die weiterleitet ist WEG. Das HTML-Attachement hingegen wird auf einmal zum Body. Sieht dann so aus, als hätte die Person garkeine Kommentare zum WEiterleiten dazugeschrieben.

    Gleiches Spiel parallel mit IMAP (Ein Linuxrechnre zieht die Mails von einem POP3-Rechner und SCHIEBT sie per IMAP in den Exchangeordner): Alles okay.

    Wieso um alles in der WElt gibt es dieses MAPI überhaupt. Wieso kann Outlook nicht einfach direkt mit MIME arbeiten? Ich verstehe ja, dass man diesen ganzen alten bewährten Code nicht einfach rauswerfen und neuschreiben kann, aber es wäre so schön, wenn nur Formulare und BEsprechungsanfragen mit MAPI umgesetzt würden und ansonsten der richtungsweisende STM-Store des Exchangeservers die Top-Priorität wäre und MIME-Mails durch den ganzen Exchangeserver hindurch (und durch Outlook hindurch) und auch durch EXMerge hindurch immer, immer, immer, immer MIME-Mails blieben ohne die ganzen ZErstörungen beim Konvertieren.

    Wenn ich das richtig sehe konvertiert Exchange eine Mail vom STM-STore (Stream-Store, enthält MIME Mails) in den MAPI-Store (EDB-Files, enthält MAPI-Datenbank), sobald ein Client wie Outlook (Coole Oberfläche, mieserabelste MIME-Implementierung) drauf zugreift. :-(((

    Ich habe so Angst um meine 6 GB Mails (Nutze privat einen Exchangeserver nachdem ich etliche Linux-IMAP-Server probiert habe): Sobald Outlook sie in die Finger kriegt sind sie nicht mehr, was sie einst waren. Greife ich hingegen NUR mit Thunderbird per IMAP auf Exchange zu, dann bleibt ja immer alles erhalten. Bloß ist das ja nicht Sinn der Übung, ich will ja Kalender, Offlinefunktionen, etc.

    Um aus diesem ganzen Gedankenstrom/Frust mal eine Frage abzuleiten:

    Ist das im Posting genannte Verhalten nur eine kleine Verbesserung/Hotfix in Exchange 2007 oder hat sich das Team mal hingesetzt und an allen möglichen Stellen "Fidelity-Verluste" beim MIME-Konverter und bei der Behandlung von Kopfzeilen aufgeräumt??

    So toll Exchange und Outlook auch ist: Hätte ich dies früher gewußt hätte ich es privat nie eingesetzt. (Meine Tests mit Thunderbird zeigten ja erstmal, dass alles geht).

    Wobei ich natürlich zugeben muß, dass mir das in der Firma alles irgendwie egal ist: Hauptsache die Leute sehen ihre Mails *irgendwie* Ist ja nicht jeder ein Admin, der Kopfzeilen durchforsten will. Aber traurig ist es schon...

    Ist "MIME-Fidelity" eigentlich überhaupt ein Designziel von Exchange und Outlook? Ist es darauf designed, dass alles, was man mit MIME unf RFC822 darstellen kann auch einen perfekt "round-trip" durch das System machen kann? Also in beide Richtungen SAUBER konvertiert werden kann?

  • Hallo Christian,

    Outlook ist kein primärer MIME-Client. Exchange und Outlook arbeiten mittels MAPI zusammen. Das ist für diverse Dinge notwendig, zum Beispiel ist darüber der Single Instance Store von Exchange implementiert. Wenn Nachrichten das System via SMTP/POP/IMAP verlassen, dann werden sie von Exchange in MIME konvertiert. Dabei werden die in den RFCs als verpflichtend festgelegten Informationen sauber rekodiert.

    Dein "Problem" mit dem NDR-Reformatting ist übrigens ein Feature. Erstens erhält der Benutzer konsistente Informationen im NDR und nicht je nach Absendemailsystem unterschiedliche NDRs in möglicherweise unterschiedlichen Sprachen. Zweitens ist die Orginalmail angehängt. Somit kann der Benutzer die Mail sehr einfach neu versenden.

    Falls Dich das stört, kannst Du das Rendern eines custom NDR in Exchange abschalten:

    Exchange user unexpectedly receives a standard NDR instead of a custom NDR
    http://support.microsoft.com/kb/812806/en-us

    Viele Grüße!
    Daniel

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment