IETF Logo Mail Archive

Re: [ietf-822] Question about line folding and maximum line length

Paul Smith <paul@pscs.co.uk> Thu, 06 May 2021 14:39 UTC

Return-Path: <paul@pscs.co.uk>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9484E3A224D for <ietf-822@ietfa.amsl.com>; Thu, 6 May 2021 07:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=pscs.co.uk
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 cpxQPDjTX_4i for <ietf-822@ietfa.amsl.com>; Thu, 6 May 2021 07:39:20 -0700 (PDT)
Received: from mail.pscs.co.uk (mail.pscs.co.uk [195.224.19.137]) (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 635993A2474 for <ietf-822@ietf.org>; Thu, 6 May 2021 07:39:19 -0700 (PDT)
Authentication-Results: mail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=pscs
Received: from lmail.pscs.co.uk ([192.168.66.70]) by mail.pscs.co.uk ([10.224.19.137] running VPOP3) with ESMTPSA (TLSv1.3 TLS_AES_256_GCM_SHA384) for <ietf-822@ietf.org>; Thu, 6 May 2021 15:39:16 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pscs.co.uk; 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=1620311601; x=1620916401; bh=9m4VygIKNbV3s0CqlclR3kXj5zevWtaybDM7/VCOYmM=; b=OI0cwqwM5ewAALdZUf3W8MXiD1CgEtY5PA2QcHUHBq8B1Y2CkkKUtUakxoCNq2BzKG4EMRB7 hLPaCG4ztEgyi6ZWsd4FU0AdHfaJEC7B8tpttCUKyUwcQ7hH2oTHm8FlrftOY1ocqyUo/bKdw+ 035VgZJUksIhB4u/FHI5jvs1g=
Authentication-Results: lmail.pscs.co.uk; spf=none; auth=pass (cram-md5) smtp.auth=paul
Received: from [192.168.57.138] ([82.68.48.206] (82-68-48-206.dsl.in-addr.zen.co.uk)) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTPSA (TLSv1.3 TLS_AES_256_GCM_SHA384); Thu, 6 May 2021 15:33:19 +0100
To: ietf-822@ietf.org
References: <87eeekq8af.fsf@workstation.frimin.fr>
From: Paul Smith <paul@pscs.co.uk>
Message-ID: <964ff057-7aa4-ceb5-cc13-f544a0dd5671@pscs.co.uk>
Date: Thu, 06 May 2021 15:33:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <87eeekq8af.fsf@workstation.frimin.fr>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-Authenticated-Sender: paul
X-Server: VPOP3 Enterprise V8.1 - Registered to: PSCS
X-Organisation: Paul Smith Computer Services
X-VPOP3Tester: 12 345
X-Authenticated-Sender: pscs
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-822/GqJSb1YKBBDx-YOEdtbw1Nt5FBQ>
Subject: Re: [ietf-822] Question about line folding and maximum line length
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2021 14:39:26 -0000

On 06/05/2021 14:52, Bryan Frimin wrote:
> 1. The maximum line length.
> RFC 5322 section 2.1.1[2] describes two possible line length limits. The
> historical one, 78 characters, and the new one, 998 characters. Is the
> historical limit still relevant for an email client in 2021, or can I
> just use the new one?

998 is a MUST (to avoid possibly breaking something, although it's 
unlikely nowadays)

78 is a SHOULD (to make it easier for users to read).

The 78 character limit is not 'historical'; it's a recommendation, not a 
requirement. In fact in RFC 822, there are no line length limits defined 
at all, just a suggestion not to make them too long. The limits were 
first introduced in RFC 2822 as far as I can see, and that uses the same 
wording as RFC 5322

When reading RFCs it's very important to know the difference between 
MUST and SHOULD (in capitals) as they have a strict meaning.


So, you should try to make lines no longer than 78 characters, but if 
they're longer (but no longer than 998) it's not going to break anything.


> 2. The long line folding mechanism.
> RFC 5322 section 2.2.3[3] defines a folding mechanism for long header
> fields. But it does define whether it is possible to fold a header field
> name longer than the limit (yes it is an edge case, but it could
> happen). And folding can only be done if a lexical token or a space is
> present. So what about values without any separator ?

Don't fold them if you can't. I don't think you'd fold a header field 
name (we don't) - as you say it's an edge-case, and I've never come 
across it.

It is very possible to have header lines where the data does not contain 
any spaces and is longer than 78 characters. That's exactly why the 78 
character line-length limit is a SHOULD and not a MUST.

Obviously if you've got a header field name longer than 998 characters 
that you would HAVE to fold but you can't, then you've got a problem - 
in more ways than one.


-- 
Paul
Paul Smith Computer Services
support@pscs.co.uk - 01484 855800


-- 


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

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

v2.23.0 | Report a Bug | By Email