james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Schiessling...@rapi.com>
Subject dot bug fix
Date Thu, 14 Feb 2002 12:19:20 GMT

According to RFC1939 (I cite the related part of it, below),
there is a bug in dot-handling of pop3server.
(We discussed this in Thread: Odd behaviour in james-user mailing list).

Please change this in CVS:

The following changes are needed in
jakarta-james/src/java/org/apache/james/pop3server/POP3Handler.java :

1. In method
  private void doRETR(String command,String argument,String argument1)

  replace
    mc.writeMessageTo(nouts);
  by
    mc.writeMessageTo(new ExtraDotOutputStream(nouts));

2. In method
  private void doTOP(String command,String argument,String argument1)

  replace
    mc.writeContentTo(outs, lines);
  by
    mc.writeContentTo(new ExtraDotOutputStream(outs), lines);

  (Remark: I think the SchedulerNotifyOutputStream should be used in
  doTOP, too. Just like in doRETR).

3. Add the class
  
jakarta-james/src/java/org/apache/james/pop3server/ExtraDotOutputStream.java
  (which is in attachement)

  In this class, an extra dot is added, if necessary. But actually it 
did not work,
  to replace "0d 0a 2e" by "0d 0a 2e 2e", because sometimes "0a 0a 2e" 
occurs,
  and there some mail readers expect extra dots, too.
  So I treat 0a and 0d as equal to count and wait until 2 of them occur 
and then a dot,
  to add an extra dot.


Here I cite from rfc1939:
"   Responses to certain commands are multi-line.  In these cases, which
   are clearly indicated below, after sending the first line of the
   response and a CRLF, any additional lines are sent, each terminated
   by a CRLF pair.  When all lines of the response have been sent, a
   final line is sent, consisting of a termination octet (decimal code
   046, ".") and a CRLF pair.  If any line of the multi-line response
   begins with the termination octet, the line is "byte-stuffed" by
   pre-pending the termination octet to that line of the response.
   Hence a multi-line response is terminated with the five octets
   "CRLF.CRLF".  When examining a multi-line response, the client checks
   to see if the line begins with the termination octet.  If so and if
   octets other than CRLF follow, the first octet of the line (the
   termination octet) is stripped away.  If so and if CRLF immediately
   follows the termination character, then the response from the POP
   server is ended and the line containing ".CRLF" is not considered
   part of the multi-line response."





Mime
View raw message