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

Paul Smith <> Sat, 06 June 2020 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F0ECE3A0933 for <>; Sat, 6 Jun 2020 11:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 81IgHS2CVMBP for <>; Sat, 6 Jun 2020 11:41:40 -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 1EBEB3A092E for <>; Sat, 6 Jun 2020 11:41:39 -0700 (PDT)
Authentication-Results:; spf=none; auth=pass (cram-md5) smtp.auth=pscs
Received: from ([]) by ([] running VPOP3) with ESMTPSA (TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384) for <>; Sat, 6 Jun 2020 19:41:35 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; q=dns/txt; s=lmail; h=Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To :Content-Type:Content-Transfer-Encoding:Cc:Reply-to:Sender; t=1591468582; x=1592073382; bh=yb7OqptY1AiH2PbcnYia4r2omy5Ej4xIaYTmUzbZBZA=; b=SAuUDUTS3t4pXTZTVbHym5EkRjEl+sUPQFOeDTJELjRbPCgezX718vPCzCvcWHqwUWSBLvtz Yp+CtGYzliP28uR7piZYFG6JMMuJGBFb69E02gQPMZ3/rPKxF8loyBbrN6nsRR7/0RIqpyED2h tMZa74gspKKQkcN3MltdYnLzg=
Authentication-Results:; spf=none; auth=pass (cram-md5) smtp.auth=paul
Received: from [] ([] ( by ([] running VPOP3) with ESMTPSA (TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384) for <>; Sat, 6 Jun 2020 19:36:21 +0100
References: <> <>
From: Paul Smith <>
Message-ID: <>
Date: Sat, 6 Jun 2020 19:36:19 +0100
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-Transfer-Encoding: 8bit
Content-Language: en-GB
X-Authenticated-Sender: paul
X-Server: VPOP3 Enterprise V7.10 - Registered
X-Organisation: Paul Smith Computer Services
X-VPOP3Tester: 12 345
X-Authenticated-Sender: pscs
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 18:41:43 -0000

On 06/06/2020 18:22, Dave Crocker wrote:
> 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. 

 From personal experience - the mail server we publish *used* to treat 
either LF or CRLF as a line ending. That stopped over 20 years ago 
because of the unending problems it caused. Now LF is just a character 
line any other if it's not preceded by a CR (similarly with a lone CR)

The problem is that if someone sends a message with LF.LF, and you treat 
LF as a line ending, you've got a message terminator in the middle of a 
message, causing all sorts of grief.

You can't expect a previous MTA to have dot-padded it, because the RFCs 
don't say they should, so you end up with a situation where your mail 
server behaves counter to what the user expects, and the RFCs say its 
behaviour is wrong, so users are right to complain.

OTOH Treating ONLY CRLF as a line break is what the RFCs say, so it's 
perfectly defensible behaviour.

I suppose with a submission server you could be more flexible, but, to 
be honest, I've *never* come across a case where not treating a lone LF 
as a line break has been a problem.

(To be honest, I'd be tempted to treat a lone LF as a 99.9999% reliable 
indicator of spam. Similarly with a NULL (0x00) character in the middle 
of an (RFC5322) message. Legitimate mail will just never have it unless 
it was generated by something very dodgy).



Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at