Actually, the comment in his last paragraph notwithstanding and
other histories of disagreement, I completely agree with Dave.
I would add one additional cautionary note: we now have several
security-related tools, in difference degrees of active use,
that digitally sign message bodies, headers, or both. If
something sees a bare LF and converts it after those signatures
are computed. testing them will typically fail. That is just
one more reason for observing Dave's (and Postel's) advice: be
really careful that what you send (or allow to be sent) out
conforms to a narrow reading of the standard. How much
deviation you want to accept in something you receive depends on
your circumstances.
john
--On Saturday, June 6, 2020 10:22 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:
On 6/6/2020 10:06 AM, Leo Gaspard wrote:
In addition, the appearance of "bare" "CR" or "LF"
characters in text (i.e., either without the other) has a
long history of causing problems in mail implementations and
applications that use the mail system as a tool. SMTP
client implementations MUST NOT transmit these characters
except when they are intended as line terminators and then
MUST, as indicated above, transmit them only as a <CRLF>
sequence.
Should I understand this paragraph as meaning that if I ever
receive such an ill-formed message, I… can? should? must?
accept it and… can? should? must? convert the <LF> into
proper <CRLF>?
Encountering practice that differs from theory -- or, in this
case, specification -- can be an excellent teachable moment.
I think your opportunity, here, is to appreciate the
pragmatics of Postel's Law. It is often taken to mean that
one can send whatever one wants, but Jon was never that
sloppy. You should try to generate only according to the
strictest interpretation of the spec.
But there are realities of different interpretations and some
tolerable sloppiness that apply to this case, given a long
history of systems that do use LF as line terminator and
network software that fails to map it to the network standard
CRLF.
I believe systems still vary on how they respond to an
incoming LF. I even suspect there are arguments for treating
it only as data and arguments for treating it as newline. I
suspect, therefore, the answer to your question will be how
you assess the benefits and detriments of each choice.
This being an IETF list, we should expect strong, differing
comments from others.
d/
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp