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

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

In one sense we do see it: Binary SMTP (RFC 3030) doesn't have any such
restriction.

I'll also note that MIME explicitly allows text parts inside of a multipart
that don't end in CRLF. In practice the CRLF often ends up getting added
and the use case for such parts is no longer relevant, but the fact remains
they are allowed.

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

Agreed on all points.

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

Agreed as well. And as for whether or not these issues should be reopened,
if this is causing actual operational problems somewhere I for one am not
aware of it.

If we're going to worry about text handling issues in email, there are far
more pressing problems than this.

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