[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Greek in email
Re: Greek in email
Fri, 24 Mar 2023 16:31:03 +0000
Thanks for passing on the original email. It's as I suggested:
- the text/html in the multipart/alternative got axed by the mailing
- the multipart/alternative was left with a sole text/plain which got
promoted into the multipart/alternative's place.
The text/plain part is truncated mid-quote. It doesn't even end in a
linefeed. Let's blame Kmail. :-)
$ mhlist -nov -file greek-email
msg part type/subtype size description
0 multipart/mixed 55K
1 multipart/alternative 37K
1.1 text/html 22K
1.2 text/plain 5689
2 application/pdf 13K
$ mhcat -file greek-email -part 1.2 | tail -3; echo
> What is happening is that letters with the acute accent (Greek: tonos)
> are getting dropped. preconv(1) produces them in precomposed form
$ mhcat -file greek-email -part 1.1 | tail -3
<br /><br /></body>
> When I view my GMail inbox via IMAP with NeoMutt, I don't have two
> copies of the message, but one.
So you're seeing different results with Gmail web interface and Gmail's
IMAP through NeoMutt? If so then I think one is showing you the
text/html part and the other the text/plain part.
Traditionally, an MUA should show the first alternative it can handle.
This will be the ‘best’ quality because they're ordered best to worst.
But many decent MUAs allow that to be overridden to say text/plain is
preferred to text/html.
> When I look at the headers in NeoMutt, it appears to be the
> directly-delivered copy (since I was CCed), not the one to the list.
$ received <greek-email
Fri 24 Mar 2023
01:48:01 +00:00:00 from [18.104.22.168] (helo=pip.localnet)
with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope- from <firstname.lastname@example.org>)
01:48:15 +00:00:14 from smarthost01c.sbp.mail.zen.net.uk
for <email@example.com> (version=TLS1_2
01:48:16 +00:00:15 by 2002:a05:6358:9211:b0:110:644f:f37b