Something in amavisd-new chain converts iso-8859-1 message parts to UTF-8
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
amavisd-new (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: amavisd-new
I'm running feisty, and after a reboot suddenly amavisd-new started mangling the charset of mails. I'm guessing an update had changed something and I hadn't restarted the services.
I'm running postfix with the content_filter parameter passing mails to amavis. If I comment out content_filter, mails are delivered in the right charset.
A mail arriving as iso-8859-1, with these headers:
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-
Content-ID: <Pine.LNX.
..will keep the headers, but the content will have changed from iso-8859-1 encoding to UTF-8. The subject, with RFC2047 encoding, is preserved.
This breaks mail for all my users.
I've tried to find references to character sets in the amavisd-new documentation and configuration files, but failed. My system-wide locale is en_US, not en_US.UTF8.
Help! :)
Followup:
May 27 16:59:48 3jane.ashpool.org /usr/sbin/ amavisd- new[23244] : (23244-01) Extracting mime components amavisd- new[23244] : (23244-01) Issued a new file name: p001 amavisd- new[23244] : (23244-01) Issued a new pseudo part: p002 amavisd- new[23244] : (23244-01) p002 1 Content-Type: multipart/mixed amavisd- new[23244] : (23244-01) Charging 54 bytes to remaining quota 874000 (out of 874000, (0%)) - by mime_decode amavisd- new[23244] : (23244-01) p001 1/1 Content-Type: text/plain, size: 54 B, name: amavisd- new[23244] : (23244-01) reparenting p001 from p000 to p002 amavisd- new[23244] : (23244-01) prolong_timer mime_decode-1: remaining time = 480 s amavisd- new[23244] : (23244-01) decode_parts: level=1, #parts=2 : p001, p002 amavisd- new[23246] : (23244-01) open_on_ specific_ fd: target fd0 closing, to become < /dev/null amavisd- new[23246] : (23244-01) open_on_ specific_ fd: target fd2 closing, to become > &1 amavisd- new[23244] : (23244-01) run_command: [23246] /usr/bin/file p001 </dev/null 2>&1 amavisd- new[23244] : (23244-01) result line from file(1): p001: ISO-8859 text amavisd- new[23244] : (23244-01) lookup_re("ISO-8859 text") matches key "(?i-xsm: ^ISO-8859. *\btext\ b)", result="txt" amavisd- new[23244] : (23244-01) lookup (map_full_ type_to_ short_type) => true, "ISO-8859 text" matches, result="txt", matching_ key="(? i-xsm:^ ISO-8859. *\\btext\ \b)" amavisd- new[23244] : (23244-01) File-type of p001: ISO-8859 text; (txt)
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
May 27 16:59:48 3jane.ashpool.org /usr/sbin/
..and the content of email.txt is indeed iso-8859-1. What comes out of amavis, however, is not. Somewhere in the process (even with spam and antivirus disabled) the text gets converted to UTF-8.