Re: [art] not an erratum in RFC 6376, was Argh!!!! onto https://www.rfc-editor.org/errata.php

John C Klensin <john-ietf@jck.com> Thu, 21 March 2024 03:01 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21C6C14F6FE for <art@ietfa.amsl.com>; Wed, 20 Mar 2024 20:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB29PFmt3Qha for <art@ietfa.amsl.com>; Wed, 20 Mar 2024 20:01:31 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 BD415C14F6BA for <art@ietf.org>; Wed, 20 Mar 2024 20:01:31 -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 1rn8gG-0008qi-9l; Wed, 20 Mar 2024 23:01:24 -0400
Date: Wed, 20 Mar 2024 23:01:18 -0400
From: John C Klensin <john-ietf@jck.com>
To: Steffen Nurpmeso <steffen@sdaoden.eu>, art@ietf.org
Message-ID: <44387288FF0DB8BDCA823345@PSB>
In-Reply-To: <20240321010142.FBZ7WuUT@steffen%sdaoden.eu>
References: <20240320231817.ACF1585D06DE@ary.qy> <20240321010142.FBZ7WuUT@steffen%sdaoden.eu>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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/art/OlfDwfVLnnUGA2VSyZccsvtecs4>
Subject: Re: [art] not an erratum in RFC 6376, was Argh!!!! onto https://www.rfc-editor.org/errata.php
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2024 03:01:36 -0000


--On Thursday, March 21, 2024 02:01 +0100 Steffen Nurpmeso
<steffen@sdaoden.eu> wrote:

> John Levine wrote in
>  <20240320231817.ACF1585D06DE@ary.qy>:
>  |It appears that Steffen Nurpmeso  <steffen@sdaoden.eu> said:
>  |>Hello.
>  |>
>  |>(I take you off the address list since i now always seem to
> get  |>
>  |>  <johnl@taugh.com>: host mx1.taugh.com[64.57.183.56] said:
>  |>    554 5.6.0 Bare CR or LF not accepted. (in reply to end
> of DATA \  |>    command)
>  |>
>  |>even though i use postfix 3.9, .. and already before had
> those new  |>configuration settings.)
>  |
>  |That means there's something wrong in your mail setup that
> is sending  |bare carriage returns or line feeds. As the
> saying goes, Don't Do  |That. If you really can't figure it
> out, send me a message from some  |non-broken mail system and
> I can arrange to catch some of the  |offending messages and
> see what's in them.
>  |
>  |>|We quite deliberately did not speculate about what one
> might do with  |>|a block of text that is sort of like a 5322
> message but isn't one.  |>
>  |>But .. that is what happens in real life software? 
>  |
>  |The issue of what to do what bare CR and LF has been batted
> around for  |decades, and we have decided that there is no
> answer better than saying  |don't do that if you want to
> interoperate.
>  |
>  |See, for example, the last paragraph on page 13 of RFC 5321,
> published \  |in 2008.
> 
> What an old outdated thing, it even has page numbers.

> That is about domain names...

Apparently a typo on John's part.  Try the bottom of Page 14.
To save time, the paragraph, at the end of Section 2.3.8, says:

	"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." 

To put both John's comment and the statement about a long
history in better perspective, exactly the same paragraph
appears at the end of Section 2.3.7 of RFC 2821 (April 2001).
While RFC 821 does not say things that explicitly, it makes it
quite clear that both commands and lines are terminated in CRLF
and only CRLF, so these things have been clear for at least 20
years and actually more like over 40.    If those documents, all
of which have page numbers, are outdated, we probably don't mean
the same thing when we talk about Internet email.  And, btw, the
same paragraph appears in draft-ietf-emailcore-rfc5321bis-27
(with page numbers in the text form).  If you find that
objectionable, this would be a good time to try to convince that
WG.

If the "real life software" to which you refer violates those
rules about CRLF, interoperability difficulties are to be
predicted.  It seems to me that the issues you are having just
demonstrate that point because you are having what sounds like
interoperability problems.

best,
   john