james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: new InputStream class for mail data
Date Tue, 15 Jul 2003 17:35:08 GMT

The statement that "the character sequence <CRLF>.<CRLF> IS NOT a line
containing only a period" is wrong.  As you know from your own finite state
machine, the required sequence in the stream is precisely CR-LF-.-CR-LF,
which would be interpreted as

   CR       need-lf
   LF       newline
   .        line-containing-a-period-so-far
   CR       newline-dot-cr-need-lf
   LF       end-of-data

Recognizing .<CRLF> is not sufficient; that implies already being in the
newline state.  It is the initial <CRLF> that puts the dot on a line by
itself by putting your FSM into LINE_STARTING_STATE.

Yes, there is a bug in James because it separates the command and data
streams, and doesn't start the data stream in the NEWLINE state.  And that
should be fixed, although as both Valdis and Keith pointed out, an empty
data set isn't a valid message.

The <CRLF>.<CRLF> is written as a marker for another reason, and that is to
indicate that the entire sequence is the terminator.  That was the point of
apparent disagreement between Keith and Daniel Bernstein.  But they weren't
really disagreeing.  The RFC doesn't require you to store <CRLF> or any
other line terminator at all.  It only requires that whatever you use to
represent line separation internally, you must use <CRLF> to separate lines
in the stream when transmitting the data.  As Keith illustrated, code can
ensure the proper data terminator when delivering the message via SMTP or
POP3.  What you do internally is up to the program.

Right now, as you noted
(http://marc.theaimsgroup.com/?l=james-dev&m=105527214016488&w=2), James
strips the entire <CRLF>.<CRLF> sequence, which is precisely the behavior
that both Valdis ad Keith told you was correct.  Then the POP3 handler will
send the entire <CRLF>.<CRLF> sequence, as would the SMTP transport.

Please note that JavaMail sends an explicit "\r\n.\r\n" to terminate the
data stream.  I believe that you indicated that you plan to use JavaMail.

> I see that this submission makes work for you if you undertake to
> implement and test it.

Anything that deals with RFC compliance deserves special attention, and you
seem to have a different understanding of the RFC, e.g.,

 *   <li>When the end of mail data indicator is recognized in the input
 *    the CRLF which immediately preceded the period in the indicator is
 *    returned as part of the mail data as the CRLF which concludes the
 *    line of mail data, rather than being discarded as part of the end of
 *    data indicator.

None of this is to say that SMTPInputStream might not be useful, but if you
make different assumptions about the RFC, then we would have to adjust the
code in order to use it.

FilteredInputStream is the right thing to extend.  SMTPInputStream
implements read() based upon the real stream, which is the one
non-constructor method that is correct in the code.  The rest are wrong.
For example:

    public void close() throws IOException{

explicitly illustrates a problem that is implicit with all of the inherited
methods.  The code invokes the inherited implementation, often a NO-OP.  It
ought to be delegating to the real stream.  FilteredInputStream provides the
core wrapper for delegation, allowing you to override just those methods
that implement your unique behavior.

	--- Noel

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

View raw message