james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 14396] - ExtraDotOutputStream doesn't properly implement dot stuffing
Date Wed, 12 Mar 2003 19:08:13 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14396>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14396

ExtraDotOutputStream doesn't properly implement dot stuffing

noel@devtech.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



------- Additional Comments From noel@devtech.com  2003-03-12 19:08 -------
It *appears* that FetchPOP relies upon the stream I/O and the web client to do 
RFC 2821 compliant line termination, rather than enforcing CRLF termination.  
Since FetchPOP mimics SMTP transport, RFC 2821 compliance is mandatory.  IF 
(and I stress the word IF) that is the actual problem, I don't know if it 
makes sense to fix it, or just push FetchMail into v2 branch.

As for the change in place, the issue is whether to attempt to preserve (and 
deliver) content that is in violation of the RFC, or attempt to bring it into 
compliance.  Ideally, this is one of those "this should never happen" cases, 
so we're only talking about what happens when it does.

>From RFC 2821, #2.3.7:

   Lines consist of zero or more data characters terminated by the
   sequence ASCII character "CR" (hex value 0D) followed immediately
   by ASCII character "LF" (hex value 0A).  This termination sequence
   is denoted as <CRLF> in this document. Conforming implementations
   MUST NOT recognize or generate any other character or character
   sequence as a line terminator.  

We must not recognize any other sequence, nor must we generate it.  We do not 
recognize anything other than CRLF in the SMTP handler.  In the POP3 Handler, 
where we use ExtraDotOutputStream, we try not to transmit defective content 
that we should not have in the first place.  ExtraDotOutputStream implements 
the "byte-stuffing" described in RFC 1939, #3.  The presence of a "bare" CR or 
LF is a problem, as noted further by RFC 2821, #2.3.7:

   In addition, the appearance of "bare" "CR" or "LF" characters in text
   (i.e., either without the other) has a long history of causing
   problems in mail implementations and applications that use the mail
   system as a tool.  SMTP client implementations MUST NOT transmit
   these characters except when they are intended as line terminators
   and then MUST, as indicated above, transmit them only as a <CRLF>
   sequence.

So, again, the issue is only what to do with content that violates the RFC.  
For the time being, I have errored on the side of delivering content that our 
users can read.

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


Mime
View raw message