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 be EBCDIC.