• Solved

  • grommunio-web korrumpiert Anzeige von Plaintextmails nach kopano-Import

Ich reihe mich mal hier ein. Nach dem LDAP geht habe ich Konten im Testsystem von Kopano importiert. Wie hier schon beschreiben habe ich viele Mails die so aussehen:

Ich habe mit Kopano immer nur das Webinterface genutzt und Mails gelangen auf die Server nur per SMTP. Die Kopano Version ist 8.7.20.

Schaue ich mir die Mails per IMAP an passt alles. Nur im Webinterface sind Sie kaputt. Outlook werde ich nicht verwenden ...

Die Mail hier im Screenshot kommt übrigens von einem Gromox-Server. Hier mal noch die relevanten Daten:

X-Mailer: gromox-oxcmail 2.0.0.9a01c75
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0005_AD282F70.D942857"

This is a multi-part message in MIME format.

------=_NextPart_000_0005_AD282F70.D942857
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="utf-8"

Auch wenn ich mir per Webmail die Mail als EML herunterlade passt alles. IMHO ein Bug in der Webmail.

Beim Kopano Update auf 8.7.0.0. musste man diese diese Befehle ausführen:

service kopano-server stop
kopano-dbadm usmp
service kopano-server restart

Beim Kopano Update 8.7.1.0 diese Befehle:

kopano-dbadm kc-1444 
kopano-admin --clear-cache=0x0020

wurde as gemacht?

    WalterH
    Keine Ahnung, das Setup ist alt. Zumindest in der Shell-History finde ich das nicht. Was das UCS Update implizit macht weiss ich ebenfalls nicht.

    Was ist da der Kontext, nur damit ich das verstehen kann. Warum passt alles per IMAP und das EML ist auch OK? Aus meiner Sicht ein reiner Darstellungsfehler 🙂

    Was mir gerade noch auffällt. Wenn man ganz frisch in die Webmail kommt und noch kein Mailinhalt angezeigt wird und klickt dann eine Mail die die nicht richtig dargestellt wird, dann wird die Mail erst ganz ganz kurz korrekt angezeigt und um dann kaput angezeigt zu werden.

      Es gibt ja noch /var/lib/gromox/user/X/eml/* nebst dem eigentlichen MAPI-Store. Aus /eml/ wird auch wieder opportunistisch gelesen, wenn vorhanden. Ich tippe also drauf, dass bei einem Import via IMAP-Protokoll (IMAP APPEND o.ä.) der Transfer zu /eml/ ok war, der zum MAPI-Store hingegen nicht. Das ließ sich aber diesseits bisher nicht reproduzieren.

      WalterH

      So, ich habe jetzt im Kopano die vorgeschlagenen Kommandos nachgeholt. Alles komplett neu installiert und neu Synchronisiert. Es beleibt bei den kaputten Mails.

          mahescho Dann waren es nicht die Änderungen an der Kopano Mail Struktur.

            Falls die mit mir sprechen wollen - und ich häng halt jetzt wieder 2 Tage 🙂

            Noch Ideen? So kann ich nicht produktiv gehen ...

            Wenn schon Jan sagt das man auf das System muss, hilft nichts anderes.

            Das werd sowieso ich sein, der draufschaut. Die Mail dient nur zum Transport etwaiger Zugangsdaten und/oder Rufnummern, die will man ja nicht unbedingt hier publik kundtun. Hier gibt's schonmal nen SSH-Key falls eine textbasierte Zugangsart genehm ist.

              jengelh

              Ja dann 🙂 SSH ist natürlich super, aber aufwändig (FW, etc ...) und ich würde gerne etwas lernen 🙂 Das Mittel der Wahl wird Telefon und Anydesk sein.

                  mahescho Schick mir ein Mail an walter [at] hofstaedtler.com mit deinen Kontaktdaten (Telefonnummer bevorzugt) und ich bringe euch zusammen.

                      Hi Walther,
                      neues Indizieren hat geholfen.
                      Suchergebnisse kommen jetzt.. Danke für den Befehl.. den richtigen Gedanken hatte ich schon mal :-)

                      Leider ist die Anzeige der Mails unverändert.. So als Info, da ja offensichtlich Weiteres im Gange ist dem Thread zu folge.
                      Wenn DAV wieder geht, dann komme ich mit Thunderbird und IMAP erstmal zurecht.

                      Tolles Forum und tolle Community hier :-)

                      Grüsse,
                      Christian

                      Trigger: Mails, die Plaintext-only sind, und non-ASCII beinhalten.
                      Was passiert: Die on-the-fly-Konversion zu HTML produziert windows-1252 statt UTF-8. Man könnte jetzt "h� was?" erwarten, aber wie im Screenshot zu sehen hat g-web andere Pläne.
                      Short option: Überhaupt ist das Default 1252 sinnfrei, da g-web/zcore ohnehin in UTF-8 arbeiten. Also gibt's jetzt nen Workaround in gromox-2.0-73-ge673ff387 .
                      Long option: g-web wird noch weiter untersucht.

                        jengelh
                        Cool.. Danke für das Update.
                        Schön zu sehen, dass man nun eine Ursache kennt.
                        Viel Erfolg :-)

                        Christian

                          © 2020-2024 grommunio GmbH. All rights reserved. | https://grommunio.com | Data Protection | Legal notice