Now it gets clearer. I was falsely suspecting the plugin to insert wrong charset header but now it seems if the HTML body is already encoded to only low ascii characters, the us-latin is selected adequately. I was able to receive a mail with international latin body and us-ascii charset which displays correctly. The bug causing the mail body broken is revealed by newsletter subject having characters using diacritics. I have made multiple tests having identical email body, differing only in subject. In cases when subject contained international latin, the subject was still encoded correctly, but the body encoding was all broken.