chatmail
DeltaChat prefers text/html over text/plain in MIME multipart emails
- Operating System (Linux/Mac/Windows/iOS/Android): Fedora 36 and iOS 15.5 and Android 10 Go Edition
- Delta Chat Version: 1.28.2 (flatpak) and 1.30.1 (Testflight) and 1.30.1 (Play Store)
- Expected behavior: When receiving a multipart message, DeltaChat shows me the plaintext version of it with a button to either switch to HTML view or the current "Show whole message".
- Actual behavior: DeltaChat shows only the email title and a link "Show full message..." which seems to open the HTML view.
- Steps to reproduce the problem: Receive multipart message, I am not sure how to do that.
- Screenshots: to be taken if necessary
- Logs: N/A
Additional context:
- https://en.wikipedia.org/wiki/MIME#Multipart_messages
- Forum post: https://support.delta.chat/t/prefer-plaintext-over-html-or-other-rich-content/2012?u=aminda (which treats it as a feature request, while I consider it as a bug considering DeltaChat shows plaintext emails just fine across all platforms)
Update: I noticed that receiving multipart messages is as easy as receiving email from either GitHub or support.delta.chat. So to take the original report (with some cutting) as an example, if I had received it to DeltaChat I would hope to see the first part (text/plain) instead of having to "View full message" which would use in-app-browser to render the mess below.
----==_mimepart_629f3d4fcb0dc_7716d6d8310912
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
- Operating System (Linux/Mac/Windows/iOS/Android): Fedora 36 and iOS 15.5 and Android 10 Go Edition
- Delta Chat Version: 1.28.2 (flatpak) and 1.30.1 (Testflight) and 1.30.1 (Play Store)
- Expected behavior: When receiving a multipart message, DeltaChat shows me the plaintext version of it with a button to either switch to HTML view or the current "Show whole message".
- Actual behavior: DeltaChat shows only the email title and a link "Show full message..." which seems to open the HTML view.
- Steps to reproduce the problem: Receive multipart message, I am not sure how to do that.
- Screenshots: to be taken if necessary
- Logs: N/A
Additional context:
* https://en.wikipedia.org/wiki/MIME#Multipart_messages
* Forum post: https://support.delta.chat/t/prefer-plaintext-over-html-or-other-rich-content/2012?u=aminda (which treats it as a feature request, while I consider it as a bug considering DeltaChat shows plaintext emails just fine across all platforms)
--
Reply to this email directly or view it on GitHub:
https://github.com/deltachat/deltachat-core-rust/issues/3409
You are receiving this because you are subscribed to this thread.
Message ID: <deltachat/deltachat-core-rust/issues/[email protected]>
----==_mimepart_629f3d4fcb0dc_7716d6d8310912
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<p></p>
<ul dir="auto">
<li>Operating System (Linux/Mac/Windows/iOS/Android): Fedora 36 and iOS 15.5 and Android 10 Go Edition</li>
<li>Delta Chat Version: 1.28.2 (flatpak) and 1.30.1 (Testflight) and 1.30.1 (Play Store)</li>
<li>Expected behavior: When receiving a multipart message, DeltaChat shows me the plaintext version of it with a button to either switch to HTML view or the current "Show whole message".</li>
<li>Actual behavior: DeltaChat shows only the email title and a link "Show full message..." which seems to open the HTML view.</li>
<li>Steps to reproduce the problem: Receive multipart message, I am not sure how to do that.</li>
<li>Screenshots: to be taken if necessary</li>
<li>Logs: N/A</li>
</ul>
<p dir="auto">Additional context:</p>
<ul dir="auto">
<li><a href="https://en.wikipedia.org/wiki/MIME#Multipart_messages" rel="nofollow">https://en.wikipedia.org/wiki/MIME#Multipart_messages</a></li>
<li>Forum post: <a href="https://support.delta.chat/t/prefer-plaintext-over-html-or-other-rich-content/2012?u=aminda" rel="nofollow">https://support.delta.chat/t/prefer-plaintext-over-html-or-other-rich-content/2012?u=aminda</a> (which treats it as a feature request, while I consider it as a bug considering DeltaChat shows plaintext emails just fine across all platforms)</li>
</ul>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/deltachat/deltachat-core-rust/issues/3409">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAGK5UEDBP6O34C5OGRNIUTVN42M7ANCNFSM5YCVIBUA">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAGK5UECYM4VXE7GV3XLHGLVN42M7A5CNFSM5YCVIBUKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4S2KRPOQ.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><deltachat/deltachat-core-rust/issues/3409</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/deltachat/deltachat-core-rust/issues/3409",
"url": "https://github.com/deltachat/deltachat-core-rust/issues/3409",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_629f3d4fcb0dc_7716d6d8310912--
Thank you for your report, @Mikaela .
I believe your request has been categorized as a feature request because the developers maybe think that someone who sends a HTML formatted message might have valid reasons to do so. I can imagine that, when converted to text only, these messages will look awful in a bubble, and users might have a bad user experience. And things would become even worse showing a customized HTML in a bubble on the other hand. So, overall we should better be safe than sorry and use what I call "the webview" (link "Show full message"), but this is just my own humble opinion, of course.
As a workaround, you might want to tell your contact to send messages in text/plain MIME type, there are some classic mail apps (MUA) available that can save such preferences for the respective contact. (This naturally would have an influence on emails received in other apps.)
I think the issue is that this messages with html body are not cut short enough, I have some sites that write me html emails, and when there are several messages, it is really hard to find when one ends and the other starts in the mess of big bubbles with pretty long text with long URLs etc.
so if an email has an html part I would recommend to show an smaller summary instead of such big chunks of often messy markdown
so if an email has an html part I would recommend to show an smaller summary instead of such big chunks of often messy markdown
there is meanwhile also a dedicated issue for this point https://github.com/deltachat/deltachat-core-rust/issues/3478
Hi all.
Have you all thought about adding support for yaml instead of html in delta.chat?
example 1: datetime_message_user.yaml
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier
This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain
include: 'folder/text.yaml'
This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
include: '/folder/file.yaml'
example 1.1: folder/file.yaml
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
use case nichtich/xanadoc-demo:
# Adopted from https://xanadu.com/SampleEDL.txt
sources:
# - document: http://hyperland.com/xuCambDemo/WelcXu-D1y
# select:
# text: "char=25,535"
#- document: http://xanadu.com/xanadox/MoeJuste/sources/0-Moe.pscr.txt
# select:
# text: "char=7995,274"
#- document: http://xanadu.com/xanadox/MoeJuste/sources/2-DarwinDescentOfMan.txt
# select:
# text: "char=143522,213"
#- document: http://hyperland.com/xuCambDemo/WelcXu-D1y
# select:
# text: "char=630,55"
- document: http://hyperland.com/xuCambDemo/J.Ineffable.txt
select:
text: "char=299,343"
#- document: http://hyperland.com/xuCambDemo/WelcXu-D1y
# select:
# text: "char=687,51"
#- document: http://hyperland.com/xuCambDemo/J.Ineffable.txt
# select:
# text: "char=2879,376"
#- document: http://hyperland.com/xuCambDemo/WelcXu-D1y
# select:
# text: "char=740,115"
links:
- from:
document: http://hyperland.com/xuCambDemo/WelcXu-D1y
select:
text: "char=301,30"
to:
document: http://hyperland.com/xuCambDemo/McKinleyAssassination.txt
select:
text: "char=358,108"
- from:
document: http://hyperland.com/xuCambDemo/WelcXu-D1y
select:
text: "char=344,29"
to:
document: http://hyperland.com/xuCambDemo/Einstein'sFridge.txt
select:
text: "char=134,336"
- from:
document: http://hyperland.com/xuCambDemo/WelcXu-D1y
select:
text: "char=386,46"
to:
document: http://hyperland.com/xuCambDemo/HTdefOgl.txt
select:
text: "char=23,191"
code-description As we can see in this code snippet we can support MIME multipart emails with yaml through trans-inclusion.
@codehangen Delta Chat does not send HTML emails, there is only support for reception of HTML mails. Adding some yaml-based format would be just a dead code, because most users never receive such messages.
Currently Delta Chat already prefers plaintext to HTML: https://github.com/deltachat/deltachat-core-rust/blob/c41687586caa45086648a84a0a0b279b79efb3d9/src/mimeparser.rs#L885-L917
The logic is to first search for text/plain part. If it is not found, use the first part. And if there are multiple parts, add "Show full message" button that will parse the email again when pressed and search for HTML part to display.
Actual behavior: DeltaChat shows only the email title and a link "Show full message..." which seems to open the HTML view.
Delta Chat shows not the email title, but a plaintext part, sometimes cut if it is too long. If the plaintext part is cut, "Show full message" is always added, even if there is no HTML part.
So it seems everything already works as requested. Maybe the request is not to cut long plaintext messages so you don't need to open HTML? But this is not a solution as it means long text messages are never cut even if they span 100 screens.