[jira] Assigned: (GERONIMO-5326) Geronimo javamail does not work on non-ASCII platforms

["Rick McGuire (JIRA)" <ji...@apache.org>]

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

Rick McGuire reassigned GERONIMO-5326:
--------------------------------------

    Assignee: Rick McGuire

> Geronimo javamail does not work on non-ASCII platforms
> ------------------------------------------------------
>
>                 Key: GERONIMO-5326
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-5326
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: mail
>         Environment: z/OS
>            Reporter: Robin Fernandes
>            Assignee: Rick McGuire
>
> [RFC-1939|http://www.ietf.org/rfc/rfc1939.txt] 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 be EBCDIC.
> {code} 
> Index: POP3Connection.java
> ===================================================================
> --- POP3Connection.java	(revision 946178)
> +++ POP3Connection.java	(working copy)
> @@ -22,6 +22,7 @@
>  import java.net.Socket;
>  import java.net.SocketException;
>  import java.net.UnknownHostException;
> +import java.nio.charset.Charset;
>  import java.security.MessageDigest;
>  import java.security.NoSuchAlgorithmException;
>  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), iso88591));
>      }
>      
>      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.