You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-issues@apache.org by "Konstantin Preißer (JIRA)" <ji...@apache.org> on 2013/11/26 17:28:35 UTC

[jira] [Created] (INFRA-7052) Mailing List Software (e.g. used for Tomcat's mailing lists) can corrupt Base64 encoded text/plain messages

Konstantin Preißer created INFRA-7052:
-----------------------------------------

             Summary: Mailing List Software (e.g. used for Tomcat's mailing lists) can corrupt Base64 encoded text/plain messages
                 Key: INFRA-7052
                 URL: https://issues.apache.org/jira/browse/INFRA-7052
             Project: Infrastructure
          Issue Type: Bug
          Components: Mailing Lists
            Reporter: Konstantin Preißer


Hi,

When one sends a Base64 encoded text/plain message (using Header "Content-Transfer-Encoding: base64") to one of Tomcat's mailing lists (e.g. users@tomcat.apache.org), then the mailing list software which forwards the mail can corrupt the data. This also happens e.g. with mails from Buildbot to the Dev list (see below).

The problem is with the following lines, that are appended by the mailing list software to the inline text/plain content of each mail:

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org

The problem here is that if your client sends the mail content as Base64, the mailing list software adds these lines as a separate Base64 block which I think is wrong - it produces invalid Base64 data, which can cause junk characters on some mailing clients (and an empty mail on my client).

Note that this problem does not always appear - I think it happens only if (original_message_length_in_bytes % 3 != 0), because then the last 4 characters sequence does not represent 3 bytes, but only 1 or 2, and therefore has some "=" characters at the end. However, in the other case, the last 4 characters represent full 3 bytes, so another Base64 block can be added without corrupting the data.

E.g., if you look at this mail from Buildbot [1], you can see that the bottom contains the "To unsubscribe..." text added by the mailing list. This mail displayed correctly in my mail client. If you look at the raw message, you can see that the first Base64 block represents 429 bytes, and as 429 % 3 == 0 there isn't a problem.

If you look at this mail from Buildbot [2], then the bottom doesn't contain the "To unsubscribe" lines. In the raw message, you can see the first Base64 block represents 403 bytes (403 % 3 == 1), so it contains "==" at the end, and the added Base64 block makes the Base64 invalid. This email displayed blank in my client (and caused junk characters on other mail clients)

I'm not a mail expert, but I think the correct way to append these lines on a text/plain message using a Content-Transfer-Encoding of Base64, Quoted-Printable or others should be:
1) Decode the Base64 (or Quoted-Printable, etc) block to bytes; then decode the bytes (using the given charset in the Content-Type header) to a String.
2) Append the "To unsubscribe ..." lines to the existing String.
3) Re-Encode the String to bytes using the previously used charset; then re-encode the bytes to Base64 (or Quoted-Printable, etc).

In this case, Base64 messages should not get corrupted.

[1] http://mail-archives.apache.org/mod_mbox/tomcat-dev/201311.mbox/%3C20131118012335.AB0A6C04A4%40aegis.apache.org%3E
[2] http://mail-archives.apache.org/mod_mbox/tomcat-dev/201311.mbox/%3C20131118032322.48526C04A4%40aegis.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.1#6144)