You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Benoit Tellier (Jira)" <ji...@apache.org> on 2021/09/09 03:22:00 UTC

[jira] [Closed] (PROTOCOLS-106) CRLFTerminatedInputStream does not do what it is supposed to. Missing CR if last char is \n Outlook hangs forever DL messages

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

Benoit Tellier closed PROTOCOLS-106.
------------------------------------
    Resolution: Fixed

https://github.com/apache/james-project/pull/639 fixed this.

> 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
>            Priority: Major
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> 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 was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org