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

Dave Crocker <> Sat, 06 June 2020 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9810E3A0891; Sat, 6 Jun 2020 10:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8XAv9dsVQPAI; Sat, 6 Jun 2020 10:22:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78BD93A0884; Sat, 6 Jun 2020 10:22:36 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 056HOjD6027835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 6 Jun 2020 10:24:45 -0700
To: Leo Gaspard <>
References: <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Sat, 6 Jun 2020 10:22:29 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [ietf-smtp] Stray <LF> in the middle of messages
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\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Jun 2020 17:22:43 -0000

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.


Dave Crocker
Brandenburg InternetWorking