Re: [ietf-smtp] [Editorial Errata Reported] RFC5322 (3400)

--On Tuesday, November 27, 2012 17:02 -0600 Pete Resnick
<[email protected]> wrote:

> [Bcc'ed to [email protected]; please discuss over on
> [email protected].]
> 
> Folks,
> 
> The following erratum was posted for 5322. I'm inclined to
> reject it since this discussion actually took place during
> DRUMS (17-18 March 1998 in a thread with a subject of "Small
> Clarification to msg-fmt-04" if you are inclined to look) and
> the consensus outcome as far as I could tell (as document
> editor) was that messages without a final CRLF were SMTP's
> problem. However, 5321 (and 2821) 4.1.1.4 says:
> 
>     The mail data are terminated by a line containing only a
> period, that
>     is, the character sequence "<CRLF>.<CRLF>", where the
> first <CRLF> is
>     actually the terminator of the previous line (see Section
> 4.5.2).
>     This is the end of mail data indication.  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 mail data,
> ends the DATA
>     command itself (the "no mail data" case does not conform
> to this
>     specification since it would require that neither the
> trace header
>     fields required by this specification nor the message
> header section
>     required by RFC 5322 [4] be transmitted).  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.
> 
> Allowing the originating SMTP system to reject the message as
> invalid seems in conflict with 5322 on this point. So my
> rejecting this erratum will simply end us up with an erratum
> against 5321.
> 
> I'm inclined to hear opinions.

Pete,

Historically, there was no requirement that SMTP transport only
Msg-Fmt (822/ 2822/ 3822) messages.  There is no such
requirement in 821 other than, implicitly, that whatever is
being transported not be screwed up by SMTP relay addition of
trace fields.  Insisting that only 822-compliant messages be
transported would have combined with the now-deprecated IM-ish
SEND (and possibly SAML and SOML) command(s) would have led to a
UI silly state.    There was a bit of a contradiction there
because an issue with trace fields and what the origin and
delivery SMTP servers were required to add, but that was
clarified in 2821 at the same time that SEND and friends were
deprecated (an additional reason for requiring that Msg-Fmt
messages be transmitted was to make MIME and its body part
description headers work).

Conversely and much more important, 822 and its successors have
never required that message bodies be transported over SMTP.  We
don't see non-SMTP transport as often as we did a few decades
ago, but it is still very much with it.  That is the reason why
5322 needs its own requirement for CRLF-terminated lines even
though "normal" SMTP can transmit nothing else.

So my impression is that 5322 is ok.  I personally don't like
it, but the current description is, as you point out, a design
decision, not a textual error.  There would be an error if 5322
got messed up with a headers-only message (empty content) that
reached end of data without a terminating CRLF (with or without
the trailing blank line), but I don't believe it does.

My impression is that 5321 is ok too because the requirement it
imposes doesn't contradict 5322 in any way.  First, while that
requirement of SMTP may not be required by 5322, nothing
prevents SMTP from imposing it.  Again, these are design
decisions made during the DRUMS period, not errors, and errata
are not an appropriate way to reopen those design decisions.   A
prohibition on SMTP rejecting a message that was valid under
5322 would also be pointless: SMTP servers are permitted to
reject messages for any reason at all and a prohibition on
rejecting for this reason would, at best, result in a
less-specific response message when an SMTP server did that.

I don't see the proposed clarification text as a real problem,
but don't see it as necessary either.   If you reject the
present erratum proposal and another one is generated against
5321, I will certainly recommend rejecting the latter as well
(or at least putting it into "hold for document revision".
However, I note that each "hold for document revision"
placeholder, especially the subset that involve earlier design
decisions, will bring us closer to the need for a WG to revise
5321 rather than allowing that to be an independent effort).

best,
    john

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822