> This is probably a gmail bug: > http://dev.mutt.org/trac/ticket/2997
I knew about that bug, I've even experienced it, but I can't find the relation with the problem I'm describing now. The headers in question are correctly utf-8 or latin-1 encoded, there is no trace of rfc 2047 encoding, be it right o wrong done. If I edit the raw utf-8 email and my locale is also utf-8, the subject header looks as expected. If I edit the raw latin-1 email and my locale is also latin-1, the subject header looks as expected. I get the same results if I edit the raw mails from gmail and change the encoding of my browser. So my conclusion is that encoding is fine. Sure it's not rfc 2047 as it should, but it's perfectly legal utf-8 or latin-1 depending on case. And I remark that the effective encoding of both emails matches the one given by the Content-type header, in one case at the only part and in the other (the one that presents the problem) at one of its multiple parts (the text/plain one). Again, setting assumed_charset=iso-8859-1 and cleaning the header cache don't fix the issue. If it were to blame gmail, the only sensible explanation that comes to my mind is that their imap server has limitations to serve latin-1 encoded emails headers (only the headers, not the entire mail), and replacement with qmarks happens during some encoding conversion that takes place at their place. Sounds unlikely, but as I've not sniffed the actual contents of imap conversation I can't deny it for sure. Best regards -Carlos
