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 Tue, 15 Jul 2003 19:33:37 GMT
Noel J. Bergman wrote:
> ... as both Valdis and Keith pointed out,
[ in the thread starting at 
http://www.imc.org/ietf-smtp/mail-archive/msg00703.html ]
>  an empty data set isn't a valid message.

I disagree.  An empty data set can be a valid message.  I find support 
in RFC 2821 Section 4.1.1.4.  The second paragraph starts as follows:

"The mail data is terminated by a line containing only a period, that 
is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2).  This 
is the end of mail data indication.  Note that the first <CRLF> of 
this terminating sequence is also the <CRLF> that ends the final line 
of the data (message text) or, if there was no data, ends the DATA 
command itself."

The last sentence, as I understand it, says there can be no data.  It 
says that the first CRLF in the CRLF.CRLF sequence can be the CRLF at 
the end of the DATA command.

> ... 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.

The illustration given by Keith in 
<http://www.imc.org/ietf-smtp/mail-archive/msg00709.html> (in which he 
adds CRLF.CRLF to each outgoing message without checking to see if the 
last "line" of message data already concluded with CRLF)  violates the 
RFC as I understand it.  The paragraph from 4.1.1.4, started above, 
concludes:

"... An extra <CRLF> MUST NOT be added, as that would cause an empty 
line to be added to the message.  The only exception to this rule 
would arise if the message body were passed to the originating 
SMTP-sender with a final "line" that did not end in <CRLF>; in that 
case, the originating SMTP system MUST either reject the message as 
invalid or add <CRLF> in order to have the receiving SMTP server 
recognize the "end of data" condition."

Note the clause, "The only exception to this rule would arise if the 
message body were passed to the originating SMTP-sender with a final 
"line" that did not end in <CRLF>".  In order to pass this point, to 
go on to the clause which allows the addition of a CRLF, a program 
would have to test whether there was already a concluding CRLF present.

> Please note that JavaMail sends an explicit "\r\n.\r\n" to terminate the
> data stream.

In this case I believe JavaMail also violates the intent of that 
paragraph in 4.1.1.4.

I guess that this whole confusion originates in writing "CRLF.CRLF" as 
a way to indicate "a period alone in a line".
It is a darn good way to indicate a period alone in a line, because 
you need to indicate that the period in the line which you are talking 
about is the first and only character in that line.  First, before you 
start looking to see if you have a period alone, you need assurance 
that you are at the start of a line.  But once you have that assurance 
you need to set it aside and not confuse it with the thing you are 
looking for, which in this case is a period alone before CRLF.

Much of the time, for most of our purposes, we can substitute the 
indication of a thing for the thing itself and swear there is no 
difference.  The writers of RFC 2821 didn't notice the difference, as 
in this authoritative tomfoolery, quoted again from 4.1.1.4:
"The mail data is terminated by a line containing only a period, that 
is, the character sequence "<CRLF>.<CRLF>" ...."

This blithely equates a thing (a line containing only a period) with 
the indication of the thing (CRLF.CRLF).  But CRLF.CRLF is not a 
period alone in a line.  It is (assurance of the end of a preceding 
line) + (a period alone in a line).  A + B does not equal B, not so 
long as A amounts to anything, and in this case A does amount to 
something, to CRLF.

Sometimes, when you get down into the code, you need to know that 
there is a difference between, for instance, a pointer to a variable 
and the variable itself.  But much of the time, at a certain level, 
you can forget that too.  That's the sort of confusion under this 
debate, I believe.

Rich


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


Mime
View raw message