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

Leo Gaspard <ietf@leo.gaspard.io> Sat, 06 June 2020 17:06 UTC

Return-Path: <leo@gaspard.io>
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 508DA3A0ED0 for <ietf-smtp@ietfa.amsl.com>; Sat, 6 Jun 2020 10:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.io
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 eR8NWwjxhpxN for <ietf-smtp@ietfa.amsl.com>; Sat, 6 Jun 2020 10:06:38 -0700 (PDT)
Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140123A0ECF for <ietf-smtp@ietf.org>; Sat, 6 Jun 2020 10:06:37 -0700 (PDT)
Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 1b9d87ea for <ietf-smtp@ietf.org>; Sat, 6 Jun 2020 17:06:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.io; h= from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=grym-20170528; bh=ELD8/hUT688i+o7J jKU0hAEXxVg=; b=CSXgxBBmk1fKcmYBzbDrObqKLe6iB1Ry6eKNrElKNqOR8A2W D1qp2FZZVpwhdblwfB0UF/x0/nwlmURcJ/4XF55v0Jilz8Wnfb774E9M7Gva0R9E SLd1LzKZKLoTw00bjrofTwexnNc9lU1lP4s56liY9OSLN+9TnmHeZqsSgFE=
Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPS id 87d18353 (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO) for <ietf-smtp@ietf.org>; Sat, 6 Jun 2020 17:06:29 +0000 (UTC)
Received: from localhost (llwynog [local]) by llwynog (OpenSMTPD) with ESMTPA id 1fc90f53 for <ietf-smtp@ietf.org>; Sat, 6 Jun 2020 17:06:29 +0000 (UTC)
From: Leo Gaspard <ietf@leo.gaspard.io>
To: ietf-smtp@ietf.org
Date: Sat, 06 Jun 2020 19:06:29 +0200
Message-ID: <87ftb8p1ii.fsf@llwynog.ekleog.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/nBL842C8Zb2HeevHWJ4l6RmbmgQ>
Subject: [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 17:06:41 -0000

Hello world,

I am in the process of writing an SMTP server, which obviously is going
to be the best of all SMTP servers ever written and that will ever be
written in our eon.

However, in the process of taking over the world, I am facing something
that surprises me.

I read, in RFC5321, §2.3.8, this paragraph:

> Lines consist of zero or more data characters terminated by the
> sequence ASCII character "CR" (hex value 0D) followed immediately by
> ASCII character "LF" (hex value 0A).  This termination sequence is
> denoted as <CRLF> in this document.  Conforming implementations MUST
> NOT recognize or generate any other character or character sequence
> as a line terminator.  Limits MAY be imposed on line lengths by
> servers (see Section 4).

Which appear to clearly indicate that <LF> is not a valid line
terminator.

However, I notice that every single time I have tried to use `netcat` to
send emails for demo purposes, it succeeded *without* sending <CRLF> and
by sending only <LF>. While `telnet` does appear to convert typed <LF>
into <CRLF>, it looks like (my version of) `netcat` does not. So most of
the SMTP servers I have met with appear to consider <LF> as a valid line
ending.

This, in most cases, is not a big deal, because <LF> is not a valid
character in SMTP commands, so saying that receiving an <LF> is
equivalent to receiving a <CRLF> is not that big a problem.

However, there is one case where the semantics is important: should one
escape the <LF>. sequence while in a DATA block?

I would guess that the fact that other SMTP servers appear to usually
accept <LF>.<LF> as a terminator indicates that <LF>. should be escaped
even though it is not strictly conforming with the RFC, but… I wanted to
have the opinion of other people on this, before diving too deep in the
implementation?

The following paragraph also makes me wonder:

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

Thank you in advance for any thoughts you may have!
  Leo


PS: If you really want to, you can find the current code of said SMTP
server here, but it's still quite far from completion and I'm a hopeless
perfectionist, so don't hold your hopes too high even if the design
described in the book appeals to you — even though I'd be happy to hear
your thoughts about it too!

  https://github.com/Ekleog/yuubind