[
http://issues.apache.org/jira/browse/JAMES-328?page=comments#action_12322961 ]
Stefano Bagnara commented on JAMES-328:
---------------------------------------
Here is the exception that is thrown:
java.io.IOException: Unknown encoding: plain
at
javax.mail.internet.MimePartDataSource.getInputStream(MimePartDataSource.java:82)
at javax.activation.DataHandler.getInputStream(DataHandler.java:220)
at javax.mail.internet.MimeMessage.getInputStream(MimeMessage.java:1242)
at
org.apache.james.core.MimeMessageWrapper.getInputStream(MimeMessageWrapper.java:652)
at org.apache.james.core.MailImpl.writeContentTo(MailImpl.java:500)
at org.apache.james.pop3server.POP3Handler.doTOP(POP3Handler.java:976)
at
org.apache.james.pop3server.POP3Handler.parseCommand(POP3Handler.java:491)
at
org.apache.james.pop3server.POP3Handler.handleConnection(POP3Handler.java:273)
at
org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run(ServerConnection.java:410)
at
org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55)
at
org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116)
do we really need to parse the message to get it as inputstream when we are
reading it from a streamrepository???
Maybe we have to convert 8bit messages to 7bit?
> TOP <msg> 0 does not return a terminator on error
> -------------------------------------------------
>
> Key: JAMES-328
> URL: http://issues.apache.org/jira/browse/JAMES-328
> Project: James
> Type: Bug
> Components: POP3Server
> Versions: 2.2.0
> Environment: James version 2.2.0 running on redhat 9, java version 1.4.2_03,
> mysql version 4.0.17 pc-linux-686
> Reporter: John Glorioso
> Assignee: Stefano Bagnara
> Priority: Minor
> Fix For: 2.3.0
> Attachments: top.diff
>
> I first noticed the problem using Java mail version 1.3.1 attempting to
> retrieve a malformed pop3 message from James. The message headers specify an
> invalid encoding type "Content-Transfer-Encoding: plain". When the command
> "TOP <msg> 0" is issued, James returns "+OK Message follows", then
> successfully returns all headers. Upon attempting to retrieve 0 lines of the
> message, it apparently encounters an error with that invalid encoding type
> and returns "-ERR Error while retrieving message." rather then the
> termination character of carriage return, period, carriage return. Javamail
> chokes on this waiting for the period termination character as it thinks that
> the "-ERR" text is a valid part of the message.
> The "RETR" command works properly however and returns the message without
> error. Looking into the source code for James, I found that even though the
> argument is to return 0 lines of the message, James still attempts to write
> the message to the output with the call "mc.writeContentTo(nouts, lines);"
> lines = 0 in this case and I put in a temporary work around to not do this
> unless lines was > 0, but if a TOP command was issued with 5 for example, it
> would still return the invalid response.
> Not sure what the best solution is, but it needs to either return -ERR up
> front, or to return the termination character regardless so that dumb mail
> clients can process it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
