Bug: alterMIME corrupts UTF-8 multi-byte characters when adding disclaimer (Quoted-Printable related) #12
Description
Dear alterMIME Developers,
I'm reporting a persistent issue where alterMIME appears to corrupt multi-byte UTF-8 characters (specifically Ukrainian Cyrillic) when inserting a disclaimer into outgoing emails. This corruption manifests as a split UTF-8 character, often showing D0 followed by � or another part of the character, in the final received email. This occurs despite correct input file encoding and the --force-into-b64 flag being used.
Problem Description
When emails are sent through my mail server setup (iRedMail, Postfix, Amavisd-new) that utilizes alterMIME to insert a disclaimer, Ukrainian Cyrillic characters within the disclaimer text (and sometimes in the original email body near the insertion point) become corrupted. The corruption consistently involves Quoted-Printable encoding, where a multi-byte UTF-8 character is split across an apparent line break, leading to malformed output in the recipient's email client.
For instance, a character like 'к' (UTF-8: D0 BA) might appear in the email's source as =D0=BA after Amavisd processing, leading to display issues like "D 0�ідомлення". This artifact shifts its position if the email content length changes, strongly suggesting an issue with line-wrapping logic during alterMIME's internal processing.
Environment Details
Operating System: Debian GNU/Linux 12 (bookworm)
iRedMail Version: 1.7.3 (latest stable)
SOGoMail Version: 5.12.1 (latest stable, acting as webmail client)
Amavisd-new Version: amavis-2.13.0 (20230106)
alterMIME Version: v0.3.10 (November-2008) by Paul L Daniels - http://www.pldaniels.com/altermime
Configuration Snippets
- Amavisd-new Disclaimer Configuration (from amavisd.conf or included files):
Perl
@altermime_args_disclaimer = qw(
--disclaimer=/etc/postfix/disclaimer/OPTION.txt
--disclaimer-html=/etc/postfix/disclaimer/OPTION.html
--force-for-bad-html
--force-into-b64
--debug
);
@disclaimer_options_bysender_maps = ({
'example.com.ua' => 'example.com.ua',
'.' => 'default',
});
2. Disclaimer HTML file content (/etc/postfix/disclaimer/example.com.ua.html):
HTML
Це повідомлення містить конфіденційну інформацію, адвокатську таємницю, та інформацію, захищену від розголошення на підставі закону. Якщо Ви отримали його помилково, будь ласка, видаліть з Вашої системи це повідомлення та вкладення до нього, повідомте нас за електронною адресою: [email protected] або зателефонуйте за номером: +380 44 000-00-00. Ви не маєте права копіювати чи розголошувати зміст повідомлення та вкладень до нього.
3. Disclaimer file encoding verification:
Bash
$ file -i /etc/postfix/disclaimer/example.com.ua.html
/etc/postfix/disclaimer/example.com.ua.html: text/plain; charset=utf-8
(Note: Although file reports text/plain, the content is valid HTML as shown above, and alterMIME loads it using the --disclaimer-html flag.)
Observed Email Headers (from SOGo-sent email, after Amavisd processing):
User-Agent: SOGoMail 5.12.1
MIME-Version: 1.0
Date: Tue, 27 May 2025 13:44:29 +0300
Subject: test45
Message-ID: 1fd13f-68359780-35-fc1a130@xxxxxxxxxxxx
X-Forward: xxx.xxx.xxx.xxx
Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_org_NGMime-xxxxxxxxxx-xxxxxxxxxx-xx------"
------=_=-_OpenGroupware_org_NGMime-xxxxxxxxxx-xxxxxxxxxx-xx------
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Length: 1082
Note: The Content-Transfer-Encoding for the text/plain part remains quoted-printable, despite --force-into-b64 being configured for alterMIME. This indicates that alterMIME is either not applying force-into-b64 to text/plain parts, or it's re-encoding an already-QP part back into QP.
Relevant Debug Logs from Amavisd (/var/log/mail.log or syslog)
2025-05-27T13:33:19.360571+03:00 engserver3 amavis[3760551]: (3760551-01) run_command: [3760582] /usr/bin/altermime --input=/var/lib/amavis/tmp/amavis-20250527T133318-3760551-Nn1hoDDu/email-repl.txt --disclaimer=/etc/postfix/disclaimer/example.com.ua.txt --disclaimer-html=/etc/postfix/disclaimer/example.com.ua.html --force-for-bad-html --force-into-b64 --debug </dev/null 2>&1
...
2025-05-27T13:33:19.370312+03:00 engserver3 amavis[3760551]: (3760551-01) ...text:DEBUG: Disclaimer Loaded (/etc/postfix/disclaimer/example.com.ua.html:922):\n
Це повідомлення містить конфіденційну інформацію, адвокатську таємницю, та інформацію, захищену від розголошення на підставі закону. Якщо Ви отримали його помилково, будь ласка, видаліть з Вашої системи це повідомлення та вкладення до нього, повідомте нас за електронною адресою: [email protected] або зателефонуйте за номером: +380 44 000-00-00. Ви не маєте права копіювати чи розголошувати зміст повідомлення та в...
2025-05-27T13:33:19.370371+03:00 engserver3 amavis[3760551]: (3760551-01) ...ладень до нього.
Observation: The log snippet ... та в...ладень до нього. (where D0 BA is the UTF-8 for 'к') clearly shows alterMIME splitting a multi-byte UTF-8 character during its internal processing (likely during loading, buffering, or logging of the disclaimer). This corruption happens before any final encoding is applied.
Analysis and Hypothesis
alterMIME (v0.3.10) appears to have a bug in its internal handling of multi-byte UTF-8 characters when performing operations that involve text buffering, concatenation, or line wrapping, leading to their corruption. This is evident from the debug logs showing D0...BA split.
The --force-into-b64 flag, intended for text/html parts, seems ineffective when alterMIME processes a text/plain MIME part (even if it contains HTML tags, as seen in SOGo's output). Since SOGo often sends the primary content as text/plain, alterMIME re-encodes this already-corrupted text/plain part back into quoted-printable.
The issue is likely not with the input encoding or the final Content-Transfer-Encoding choice, but with the integrity of the data stream within alterMIME itself before re-encoding.
Steps to Reproduce
Set up iRedMail 1.7.3 with Amavisd-new 2.13.0 and SOGoMail 5.12.1 on Debian GNU/Linux 12 (bookworm).
Configure Amavisd to use alterMIME (v0.3.10) for disclaimers as per iRedMail documentation, with the provided @altermime_args_disclaimer and the Ukrainian HTML disclaimer file (saved as UTF-8).
Send an email with Ukrainian text from SOGo to a Gmail address.
Observe the corruption in the received email's source (specifically in the Content-Transfer-Encoding: quoted-printable part) and its display.
Expected Behavior
alterMIME should insert the disclaimer without corrupting multi-byte UTF-8 characters. Additionally, if --force-into-b64 is specified, the relevant MIME parts should be encoded using base64.
Thank you for your time and assistance in investigating this critical issue.
Sincerely,
Bondarenko Sergii
[email protected]