geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick McGuire (JIRA)" <>
Subject [jira] Resolved: (GERONIMO-5326) Geronimo javamail does not work on non-ASCII platforms
Date Wed, 19 May 2010 18:04:53 GMT


Rick McGuire resolved GERONIMO-5326.

    Resolution: Fixed

Committed revision 946312. and 946314.

I believe I found all the places where this might be an issue.  There were quite a few potential

> Geronimo javamail does not work on non-ASCII platforms
> ------------------------------------------------------
>                 Key: GERONIMO-5326
>                 URL:
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: mail
>         Environment: z/OS
>            Reporter: Robin Fernandes
>            Assignee: Rick McGuire
> [RFC-1939|] states that in the POP3 protocol, "Keywords
and arguments consist of printable ASCII characters."
> Geronimo javamail creates a PrintWriter to send messages down the line, but does not
specify a Charset. Therefore, Strings written to the PrintWriter will be converted to bytes
using the platform default encoding. On a non-ASCII platform, such as z/OS (which is an EBCDIC
platform), this means non-ASCII data will be sent down the line. Consequently, the POP3 protocol
is violated and the mail server will not understand the messages.
> In my context, this manifests as a javax.mail.AuthenticationFailedException, presumably
because the server fails to understand the login commands.
> The patch below at least gets past the auth step. However, I suspect there will be further
charset problems relating to decoding MIME etc... Essentially, a potential problem exists
wherever the library uses new String(bytes[]), String.getBytes(), InputStreamReaders, OuputStreamWriters
or any other entity that performs byte[]<->String conversions without explicitly specifying
which Charset to use.
> In some environments, a workaround may be to force the default encoding to ASCII by setting
system property file.encoding to an ASCII codepage (e.g. -Dfile.encoding=ISO8859-1), but this
is not satisfactory if other libraries in the same runtime expect the default encoding to
> {code} 
> Index:
> ===================================================================
> ---	(revision 946178)
> +++	(working copy)
> @@ -22,6 +22,7 @@
>  import;
>  import;
>  import;
> +import java.nio.charset.Charset;
>  import;
>  import;
>  import java.util.ArrayList;
> @@ -156,8 +157,9 @@
>          // The POp3 protocol is inherently a string-based protocol, so we get 
>          // string readers/writers for the connection streams 
> -        reader = new BufferedReader(new InputStreamReader(inputStream));
> -        writer = new PrintWriter(new BufferedOutputStream(outputStream));
> +        Charset iso88591 = Charset.forName("ISO8859-1");
> +        reader = new BufferedReader(new InputStreamReader(inputStream, iso88591));
> +        writer = new PrintWriter(new OutputStreamWriter(new BufferedOutputStream(outputStream),
>      }
>      protected void getWelcome() throws IOException {
> {code} 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message