Hmmm, in diesem Beispiel und in der vollständigen E-Mail-Quelle, die du mir gesendet hast (danke!), sollte das Attribut moz-do-not-send die Anzeige der \u003cimg\u003e- oder \u003ca\u003e-Tags, in denen dieses Attribut vorkommt, nicht beeinflussen. Der Mozfilter prüft nur Werte im class-Attribut, und ich kann im Moment nirgendwo sonst erkennen, wo er sonst noch gefiltert werden könnte.
Daher kann ich nicht herausfinden, warum der Inhalt und der href des Links mit Alias getrennt werden, es sei denn, der Discourse-Importer entscheidet sich plötzlich dafür, den plain/text-Teil der MIME-codierten E-Mail zu verwenden (der tatsächlich Text und URL getrennt enthält). Warum er das tun würde, weiß ich nicht.
Kannst du in deinem Test-Discourse-Setup versuchen, eine Thunderbird-HTML-E-Mail mit einem Link mit Alias und beispielsweise einem eingebetteten Bild oder etwas anderem zu importieren/versenden, das es als HTML-Teil der E-Mail kennzeichnet?
Ich denke immer noch, dass dies möglicherweise Discourse ist, das die anderen MIME-Teile verwendet (in diesem Fall ein plain/text-Teil, gefolgt von einem image/…-Teil der E-Mail, um seine Markdown-Version zu erstellen, obwohl ich nicht weiß, warum. Vielleicht lehnt ein HTML-Validator den text/html-Teil wegen streng nicht-validierender Attribute wie moz-do-not-send ab!?
Könntest du noch einen Test mit demselben Beitrag durchführen (einige Text mit einem Bild in der Mitte, aber mache auch einige – aber nicht alle – Textstellen fett, sogar nur ein einziges Wort. Ich denke, das wird entscheiden, ob der Textteil aus einem text/plain- oder text/html-Block stammt.
Und sorry, dass ich das frage, aber nur zur Sicherheit: Ist incoming_email_prefer_html auf true gesetzt (angehakt)?!
Danke, @Flominator. Ich sehe, dass der fette Text jetzt kursiv ist, also wird das HTML definitiv nicht direkt verwendet, aber die Betonung wird irgendwie erkannt. Ich frage mich, ob dem text/plain-Teil der E-Mail irgendeine Art von Markup hinzugefügt wird. Könntest du mir wie beim letzten Mal den E-Mail-Quelltext per PN schicken?
Hallo @Flominator, danke für die Roh-E-Mail. Beim Ansehen des text/plain-Alternativteils der E-Mail werden tatsächlich Sternchen um den Text gesetzt, der im text/html-Teil fett gedruckt ist. Die meisten Markdown-Renderer (wie der in Discourse) interpretieren dies als kursiv. Hier ist der text/plain-Abschnitt, einzeln kopiert und eingefügt:
Bild in die Mitte dann wieder Text von dem ein Teil sogar fett
geschrieben ist
Gruß
Flo
Das sieht exakt so aus wie dein Screenshot.
Meiner Einschätzung nach wird das text/html-Segment als ungültiges HTML abgelehnt (wahrscheinlich aufgrund des nicht standardkonformen Attributnamens moz-do-not-send in den a-Tags). Dafür wäre ein Patch erforderlich, der die Prüfung auf gültiges HTML ändert (möglicherweise durch einfaches Entfernen dieser Attribute). Ich bin weniger sicher, wie stabil das sein wird, ohne dass dies in den Kerncode integriert wird. Ich werde mir das ansehen, sobald ich etwas Zeit habe.
Dies bedeutet, dass der in einem obigen Kommentar angehängte Patch fehlschlägt (wahrscheinlich nicht “spektakulär”, aber er könnte dann einen Rebuild erfordern, um Upgrades wieder zum Laufen zu bringen), wenn Sie auf diesen neuen Commit aktualisieren (wahrscheinlich Ihr nächstes Upgrade).
Wenn Sie ihn automatisch anwenden lassen (z. B. mit einem git applycmd in Ihrer app.yml, wie oben beschrieben), sollten Sie ihn vor Ihrem nächsten Upgrade entfernen. Tatsächlich könnte ein Rebuild angebracht sein, da dieser Commit möglicherweise nicht angewendet werden kann, da die Stelle in receiver.rb, an der der Commit-Diff angewendet werden soll, durch den Patch bereits geändert wurde.
Ich werde 1) den git applycmd aus app.yml entfernen, 2) die App neu erstellen, 3) aktualisieren (falls dies nicht bereits beim Rebuild geschehen ist). Ich werde Sie auf dem Laufenden halten, wie das läuft…
[10 Minuten später…]
Am Ende habe ich stattdessen Folgendes getan, da es während des Rebuilds keine Ausfallzeiten erfordert.
Entfernen Sie den git apply für den Patch aus app.yml (muss nur vor Ihrem nächsten App-Container-Rebuild erfolgen)
Setzen Sie die gepatchte Datei zurück mit:
i) launcher enter app
ii) (jetzt im App-Container) cd /var/www/discourse git checkout ./lib/email/receiver.rb exit
Aktualisieren Sie Discourse über das Web-Admin-Update
