Open samhh opened 4 years ago
Might be a bug. But ProtonMail only keeps the text/html part when an email contains both text/plain and text/html, so maybe that's related too.
ah, that's my issue as well, the one from the aerc-list
changing the default from "text/html"
to "text/plain"
"fixed" it for me:
https://github.com/emersion/hydroxide/blob/86db01792a9ca03fc06c67a973c5ba35be878736/imap/message.go#L110
of course, that's probably not completely satisfactory a solution as Proton's default seems to be text/html
.
perhaps we could leave the "list message" code as is (so, leaving msg.MIMEType==""
and a body structure with "text/html"
) but then, when protonmail.Client.GetMessage(id)
comes along, update the MIMEType
field with the correct value in the db
?
or perhaps there's a way to tell the Proton server to give more informations?
circling back to this. I've been using the patch from #129 since Jan 2021. it's working ok for some messages but not for all.
perhaps a better course of action would be to escalate this to Proton?
What happens when it doesn't work? Is it showing HTML content with the text/plain
MIME type, or the other way around? Or maybe it's just showing HTML content with text/html
?
In my case, in aerc, both text/plain
and text/html
(as described in the web UI headers) are detected/rendered as text/html
.
ditto. kind of.
for example, "even with my patch" (for whatever value one may want to attach to this :P), mails from the lists.sr.ht lists get still labeled as text/html
.
Worth noting that I don't see this issue with a Migadu account so this is probably a Hydroxide/PM issue rather than an aerc issue.
I still have this problem, text/plain emails are being treated as text/html, which is screwing with the formatting. Any update on a fix?
I finally figured out a workaround, so I figure I should document it here (and some other workarounds I've thought of, but dismissed).
Currently, when hydroxide does not know a part's MIME type, it guesses text/html: https://github.com/emersion/hydroxide/blob/c964219ad4996d90b34d730b98a8c736b9bc9921/imap/message.go#L116-L120
One could replace inlineSubType := "html"
with inlineSubType := "plain"
to make it treat unknown types as text/plain, but this would cause HTML emails to be treated as plain text.
If you then use a filter that reformats text/html emails as plain text, this would cause the message to be displayed raw. Perhaps good enough for those who don't use such filters or who rarely receive HTML mail, but they're unfortunately too common for me to accept.
The reason why text/plain is lost is because Protonmail doesn't send the MIME type when emails are being listed, but it is sent when a specific message is fetched. Hydroxide could be set up to fetch all messages when listing before they are handled, and Hydroxide does in fact do this for emails with attachments: https://github.com/emersion/hydroxide/blob/c964219ad4996d90b34d730b98a8c736b9bc9921/imap/message.go#L108-L114
Someone could simply remove the if case to make it fetch all emails. However, this would, well, cause every message to be fetched when listing all emails, which can be slow. Perhaps there could be a local cache for this so it becomes less slow in future runs, but I'm too lazy to figure out how to implement that.
Additionally, at least when using aerc, this causes Non-multipart body part doesn't have 7 fields
errors on certain multipart/mixed emails. (I've looked at the traffic via Wireshark, and apparently the MIME type sent to the client in the BodyStructure is "mixed" NIL
? I'm not familiar with IMAP so I don't know if I use the proper terminology, and I am, again, too lazy to figure out a proper fix).
<html
Personally, the symptom I face with this bug are plain text emails being fed through an HTML renderer, which collapses whitespace (including newlines!), causing emails to be unreadable.
I eventually decided to make my text/html filter use file
for the first 1024 bytes of the email to check that it is an HTML email. If so, it runs it through what I would use to process HTML emails. If not, it runs it through what would've been done for plaintext emails:
#!/bin/sh
# Workaround Hydroxide returning text/html for plain text emails
TEMPFILE=$(mktemp)
cat > "$TEMPFILE"
if [ "$(head -c 1024 $TEMPFILE | file --brief --mime-type -)" = text/html ]; then
# Replace this block with code that is run for text/html emails
# aerc filter which runs w3m using socksify (from the dante package) to prevent
# any phoning home by rendered emails
export SOCKS_SERVER="127.0.0.1:1"
socksify w3m \
-I UTF-8 \
-T text/html \
-cols "$(tput cols)" \
-dump \
-o display_image=false \
-o display_link_number=true \
"$TEMPFILE"
EXIT=$?
else
# Replace this block with code that is run for text/* emails
awk -f /usr/lib/aerc/filters/plaintext < "$TEMPFILE"
EXIT=$?
fi
rm "$TEMPFILE"
exit $EXIT
I saved the above script to ~/.config/aerc/html-filter, and changed my text/html filter from /usr/lib/aerc/filters/html
to ~/.config/aerc/html-filter
. So far, works flawlessly well enough.
Edit: Of course, just as I said that scanning the first 1024 bytes for <html
"works flawlessly", I find out that Github emails do not contains that substring. At least it contains <script>
, which is handled by file(1)
. I've updated this section to now use file
.
I'm using Hydroxide with aerc and noticed that none of the emails I read are coming through as
text/plain
, even if the header in the ProtonMail web UI saysContent-Type: text/plain
. I've run Hydroxide with-debug
and am seeing the following:Is this a bug or am I missing something obvious? :slightly_smiling_face: Cheers.