james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard O. Hammer" <ROHam...@EarthLink.net>
Subject Re: new InputStream class for mail data
Date Wed, 16 Jul 2003 20:07:47 GMT
Noel J. Bergman wrote:
> It all depends upon the RFC compliance.

To summarize this question in my view, RFC 2821 clearly offers two 
interpretations (that the end of data indicator is a period alone in a 
line; that the end of data indicator is CRLF.CRLF) which lead to two 
different sets of behavior in a few cases which probably are not very 

This confusion originates in the wording of the RFC.  I think the 
RFC's writers did not understand the difference between "a period 
alone in a line" and "CRLF.CRLF", a difference which may be noticed by 
only a few writers of parsers.

Because the RFC offers these two interpretations, I expect that each 
interpretation has been expressed in some presently working code. 
Each interpretation probably has people who would fight for it.  As 
such, if we assume that the writers of a future revision to the RFC 
become conscious of the confusion possible on this issue, I expect 
they will deliberately adopt wording which continues to allow both 

As such, I suppose James is safely RFC compliant on this issue as it 
is now.

But, between the two interpretations, both of which I believe must 
ultimately be acceptable, I sort of like the "a period alone in a 
line" interpretation better, because I suppose that was first 
historically.  The first idea was probably to put "a period alone in a 
line" as a way to signal the end of data.

A subsequent, later idea, probably thought up by programmers who 
needed to implement "a period alone in a line"  was to scan for 
"CRLF.CRLF" (as I am guessing the history).  In fact "CRLF.CRLF" was 
probably favored by many programmers as the way to indicate "a period 
alone in a line" because it is easier to search for than "a period 
alone in a line".

But, as I continue to insist, the two interpretations lead to 
different behavior in a few minor ways in programs which attempt to 
comply with RFC 2821.

The SMTPDataInputStream class which I have written expresses the "a 
period alone in a line" interpretation, and thus behaves differently 
from the present James classes in two small ways, as described in its 


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

View raw message