www-infrastructure-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Stevenson (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (INFRA-7052) Mailing List Software (e.g. used for Tomcat's mailing lists) can corrupt Base64 encoded text/plain messages
Date Mon, 28 Jul 2014 20:25:39 GMT

     [ https://issues.apache.org/jira/browse/INFRA-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Tony Stevenson resolved INFRA-7052.

    Resolution: Won't Fix
      Assignee: Tony Stevenson


Thanks for your detailed feedback. However the issue we have is that our mail setup is quite
fragile right now, and unpicking that is not going to happen in the very near future.  However
the Infra team are looking to the future for how we can improve our mail service.  

Until then, we cannot realistically look into this further.  


> 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
>            Assignee: Tony Stevenson
>              Labels: #bugbash
> 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

View raw message