... 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
