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 Stephan Schiessling <s...@rapi.com> on 2002/02/14 13:19:20 UTC

dot bug fix

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."





Re: dot bug fix

Posted by Serge Knystautas <se...@lokitech.com>.
Thanks, just applied this.

I put the ExtraDotOutputStream into the util class as I think it will be
useful if I ever get to writing an SMTP transport from scratch (rather than
relying on JavaMail like we do now).  Thanks again!

Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
----- Original Message -----
From: "Stephan Schiessling" <s...@rapi.com>
To: <ja...@jakarta.apache.org>
Sent: Thursday, February 14, 2002 7:19 AM
Subject: dot bug fix


>
> 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:


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: dot bug fix

Posted by Serge Knystautas <se...@lokitech.com>.
Stephan,

Great, thanks for the patch!  I knew SMTP required the dot-stuffing, and I
guess it makes sense that it's also necessary for POP.

Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
----- Original Message -----
From: "Stephan Schiessling" <s...@rapi.com>
To: <ja...@jakarta.apache.org>
Sent: Thursday, February 14, 2002 7:19 AM
Subject: dot bug fix


>
> 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."
>
>
>
>
>


----------------------------------------------------------------------------
----


> /*
>  * Copyright (C) The Apache Software Foundation. All rights reserved.
>  *
>  * This software is published under the terms of the Apache Software
License
>  * version 1.1, a copy of which has been included with this distribution
in
>  * the LICENSE file.
>  */
> package org.apache.james.pop3server;
>
> import java.io.FilterOutputStream;
> import java.io.IOException;
> import java.io.OutputStream;
>
> /**
>  * Adds extra dot if dot occurs in message body at beginning of line
(according to RFC1939)
>  * Compare also org.apache.james.smtpserver.SMTPInputStream
>  *
>  * @author Stephan Schiessling <s...@rapi.com>
>  */
> public class ExtraDotOutputStream extends FilterOutputStream {
>
>     /**
>      * Counter for number of last (0A or 0D).
>      */
>     protected int countLast0A0D;
>
>     public ExtraDotOutputStream(OutputStream out) {
>         super(out);
>         countLast0A0D = 2; // we already assume a CRLF at beginning
(otherwise TOP would not work correctly !)
>     }
>
>     public void write(int b) throws IOException {
>         out.write(b);
>         if (b == '.') {
>             if (countLast0A0D > 1) {
>                 // add extra dot
>                 out.write('.');
>             }
>             countLast0A0D = 0;
>         } else {
>             if (b == '\r' || b == '\n') {
>                 countLast0A0D++;
>             } else {
>                 countLast0A0D = 0;
>             }
>         }
>     }
>
> }
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>