> I disagree.  An empty data set can be a valid message.  I find support
> in RFC 2821 Section 4.1.1.4.

Not RFC 2821.  RFC 2822, section 3.6:

   The only required header fields are the origination date field and
   the originator address field(s).  All other header fields are
   syntactically optional.

> The illustration given by Keith (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.

Keep it in context.  An *extra* <CRLF> would be bad.  But since Keith (and
James) strip the <CRLF>.<CRLF>, when the <CRLF>.<CRLF> is put back during
transmission, there is no extra <CRLF>.  If James did not strip the entire
terminator, then there would be an extra <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.

Only the *originating* SMTP-sender is allowed to make that correction
because it is the only entity that receives the message in raw form.  That
is not the SMTP server.  It is the first thing that uses SMTP to transport
the message, e.g., Microsoft Outlook or the mail command.

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

If you compare RFC 821 with RFC 2821, you will find that the latter was
explicitly edited to declare that identity.  I understand why you have a
question about the terminator's leading edge, but real requirement is to be
consistent, so that transmission does not change the contents.

In any event, if you feel that your interpretation of the RFC is correct,
and that everyone else is wrong, please contact the IETF to explain where
they went wrong, and ask them to issue a correction.  The Area Directors in
question would be:

  Ned Freed <[EMAIL PROTECTED]>
  Ted Hardie <[EMAIL PROTECTED]>

Obviously, we want to be RFC compliant.

        --- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to