Re: [ietf-smtp] Stray <LF> in the middle of messages

John C Klensin <john-ietf@jck.com> Sat, 06 June 2020 18:16 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497873A095F; Sat, 6 Jun 2020 11:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgjIY2i1qTvj; Sat, 6 Jun 2020 11:16:03 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A8E3A095D; Sat, 6 Jun 2020 11:15:58 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jhdMI-000Lo0-T4; Sat, 06 Jun 2020 14:15:54 -0400
Date: Sat, 06 Jun 2020 14:15:49 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, Leo Gaspard <ietf=40leo.gaspard.io@dmarc.ietf.org>
cc: ietf-smtp@ietf.org
Message-ID: <CECAD420DF51202689DE4E81@PSB>
In-Reply-To: <1bf01c85-3276-270b-a517-70bf15e09043@dcrocker.net>
References: <87ftb8p1ii.fsf@llwynog.ekleog.org> <1bf01c85-3276-270b-a517-70bf15e09043@dcrocker.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/WMR9HhBl3tPFHsWUqmF9a9arAWc>
Subject: Re: [ietf-smtp] Stray <LF> in the middle of messages
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2020 18:16:06 -0000

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@dcrocker.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/