Re: [ietf-822] (no subject)

Ned Freed <ned.freed@mrochek.com> Tue, 24 July 2018 14:32 UTC

Return-Path: <ned.freed@mrochek.com>
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 E4C67130EA8 for <ietf-822@ietfa.amsl.com>; Tue, 24 Jul 2018 07:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
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 3ptZD6gyn9xJ for <ietf-822@ietfa.amsl.com>; Tue, 24 Jul 2018 07:32:24 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 8D7E7130E97 for <ietf-822@ietf.org>; Tue, 24 Jul 2018 07:32:24 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV8Q5E6GGG0006VH@mauve.mrochek.com> for ietf-822@ietf.org; Tue, 24 Jul 2018 07:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1532442641; bh=sGgmYmEumVIZVu7VTEiTsMNgHpT8RNZUNXYNSpSRukg=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=SOAnDLR9LYKfMr3BAUAyepSgqz6X4RQxJ500RjKM6KMfU5phf8GOYGPrO+G7fcGU5 2bZzvNOC6iVc9bpFWY3+l2vbArKhFaL1Jxxy78Rt3REb3K4pBEJzz4W3R+N67gCcme Dtr3qUs8mMcyyHt7a9L9EapZL2Sa//rkUH0ZJwvc=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QV7GRS9SI800004G@mauve.mrochek.com>; Tue, 24 Jul 2018 07:30:04 -0700 (PDT)
Cc: John R Levine <johnl@taugh.com>, "ietf-822@ietf.org" <ietf-822@ietf.org>
Message-id: <01QV8Q5CB2A600004G@mauve.mrochek.com>
Date: Tue, 24 Jul 2018 07:22:52 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 24 Jul 2018 00:33:12 -0400" <5b56ac06.1c69fb81.3d4fa.136e@mx.google.com>
References: <5b56a4ba.1c69fb81.836c0.d955@mx.google.com> <20180724041315.771A32002CDBCF@ary.qy> <5b56aa40.1c69fb81.53109.c080@mx.google.com> <alpine.OSX.2.21.1807240026310.36374@ary.qy> <5b56ac06.1c69fb81.3d4fa.136e@mx.google.com>
To: Peter Occil <poccil14@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-822/xSrJ2_0ODnPTTZDIZe1pIn-a33c>
Subject: Re: [ietf-822] (no subject)
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 24 Jul 2018 14:32:26 -0000

> So in that case, would a reasonable update to RFC 2369 be to impose a
> character limit of 998 characters on list header fields, including the
> List-Unsubscribe header field?

No, not really. The limit is already there; it's a basic part of SMTP. We don't
talk about it every time we define a new header field. If we did that for every
limit defined at one protocol level which affects other levels there would be
no end to it.

Now, if there was evidence that people are attempting to put huge
URLs in List-* headers and causing problems then there would be justification
for adding some text about it. But IMO it would still not rise to the level
of calling for an update to the specification.

				Ned