"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Thank you, I didn't think about that. You are right, I have LANG set to 'ja_JP'. If I set LANG to 'C' or 'de_DE' the default of buffer-file-coding-system becomes 'iso-2022-8', i.e. 21.1.10 behaves the same as 21.2.34 in that respect. If the default for 'buffer-file-coding-system' is set to 'iso-2022-8', Gnus works correctly for at least 8-bit German and Japanese. For other languages I can't tell. Probably not only with Gnus. I had a similar problem about 1 year ago with VM. Suddenly all German messages in my VM INBOX had been converted to iso-2022-jp. I didn't find out why back than, but now I think it was very likely the same problem with the value of 'buffer-file-coding-system'. With VM it is even worse, because it hits your whole INBOX at once. That may be difficult to reverse, if your INBOX contains many different languages. With Gnus and the nnml backend (1 file per message), changing the default value of 'buffer-file-coding-system' affects only the messages coming in after that. Maybe that would help for the nnml backend, but probably not for nnfolder or VM. Maybe this is the best solution. Is there any reason why this shouldn't work in all cases? If the message is saved unchanged, exactly as it came in, Gnus and VM should be able to use the MIME information to decode and display it correctly. But if the encoding of the message body has been changed to something else when XEmacs saved it, it is no wonder that Gnus displays garbage. -- Mike Fabian <mfabian(a)suse.de&gt;