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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
