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 important.
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 interpretations.
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 Javadoc.
Rich
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
