[
https://issues.apache.org/jira/browse/PROTOCOLS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve updated PROTOCOLS-106:
----------------------------
Description:
A message transfer to a pop3 client is finished when the server issues
CRLF DOT CRLF
However this is not always the case with the current implementation.
The method
private void calculateExtraData() {
109 if (last == '\n') {
110 extraData = null;
111 } else if (last == '\r') {
112 extraData = new byte[1];
113 extraData[0] = '\n';
114 } else {
115 extraData = new byte[2];
116 extraData[0] = '\r';
117 extraData[1] = '\n';
118 }
119
120 }
Does not factor in when the last byte is "\n" but the one before is NOT "\r" -
meaning the resulting output to the client is actually
LF DOT CRLF
Outlook will hang forever because it does not see a termination of the message.
(See POP3 RFC - it MUST be CRLF DOT CRLF - Thunderbird is not as strict tho)
A java MimeMessage is not guaranteed to be canoniclized by CRLF - see
http://www.oracle.com/technetwork/java/faq-135477.html#repres
The current workaround is to implement Mailbox and overwrite public
InputStream getMessage(String uid) to always make sure the message stream ends
with a CRLF.
was:
A message transfer to a pop3 client is finished when the server issues
CRLF DOT CRLF
However this is not always the case with the current implementation.
The method
private void calculateExtraData() {
109 if (last == '\n') {
110 extraData = null;
111 } else if (last == '\r') {
112 extraData = new byte[1];
113 extraData[0] = '\n';
114 } else {
115 extraData = new byte[2];
116 extraData[0] = '\r';
117 extraData[1] = '\n';
118 }
119
120 }
Does not factor in when the last byte is "\n" but the one before is NOT "\r" -
meaning the resulting output to the client is actually
CRLF DOT LF
Outlook will hang forever because it does not see a termination of the message.
(See POP3 RFC - it MUST be CRLF DOT LF - Thunderbird is not as strict tho)
A java MimeMessage is not guaranteed to be canoniclized by CRLF - see
http://www.oracle.com/technetwork/java/faq-135477.html#repres
The current workaround is to implement Mailbox and overwrite public
InputStream getMessage(String uid) to always make sure the message stream ends
with a CRLF.
> CRLFTerminatedInputStream does not do what it is supposed to. Missing CR if
> last char is \n Outlook hangs forever DL messages
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: PROTOCOLS-106
> URL: https://issues.apache.org/jira/browse/PROTOCOLS-106
> Project: James Protocols
> Issue Type: Bug
> Components: pop3
> Affects Versions: 1.6.2
> Reporter: Steve
> Assignee: Eric Charles
>
> A message transfer to a pop3 client is finished when the server issues
> CRLF DOT CRLF
> However this is not always the case with the current implementation.
> The method
> private void calculateExtraData() {
> 109 if (last == '\n') {
> 110 extraData = null;
> 111 } else if (last == '\r') {
> 112 extraData = new byte[1];
> 113 extraData[0] = '\n';
> 114 } else {
> 115 extraData = new byte[2];
> 116 extraData[0] = '\r';
> 117 extraData[1] = '\n';
> 118 }
> 119
> 120 }
> Does not factor in when the last byte is "\n" but the one before is NOT "\r"
> - meaning the resulting output to the client is actually
> LF DOT CRLF
> Outlook will hang forever because it does not see a termination of the
> message. (See POP3 RFC - it MUST be CRLF DOT CRLF - Thunderbird is not as
> strict tho)
> A java MimeMessage is not guaranteed to be canoniclized by CRLF - see
> http://www.oracle.com/technetwork/java/faq-135477.html#repres
> The current workaround is to implement Mailbox and overwrite public
> InputStream getMessage(String uid) to always make sure the message stream
> ends with a CRLF.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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]
