Re: [ietf-822] (no subject)

Peter Occil <> Tue, 24 July 2018 04:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69021130DF4 for <>; Mon, 23 Jul 2018 21:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V3ms4x4Me_DI for <>; Mon, 23 Jul 2018 21:25:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3FF1130DF2 for <>; Mon, 23 Jul 2018 21:25:37 -0700 (PDT)
Received: by with SMTP id r3-v6so1074223ywc.5 for <>; Mon, 23 Jul 2018 21:25:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=J3xE+vGk0nWDWNHfFVY9U+mAwEv1KiEJZmHCV1l54yo=; b=RnBsfAYw4LwdylVH/5CSdIJnIG8hv/Arpd8lvvhXhfyDU8wx5yaxj+9h8WzzpLIZpM tZPimSTJAhyj3hqlkaOsaHAJq6m3Ep8otftVxgYeE+PYp6XjUsKU8RuoKWUKQuBD5URJ /Xhnd3qH8Z5Q5RO12SrLeqg+zL0QxIZwNPn+/JGMrwQ+lYMKb1IlVOWxJuExwslRrj67 0C0W0ivAx2Hj7GDCk0d/EYSg1bwCnhK+2wzhSIJfsDa5V++po0EqabeTmBUJLjxvhaOW 1YFs/gHJGdaA3x/LYc8EGlGniZt+JZ1rj0/Yo3OYBmC907uSZwG19NkqIHs75np0r1yo 0dew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=J3xE+vGk0nWDWNHfFVY9U+mAwEv1KiEJZmHCV1l54yo=; b=LBQ8NP5vMFjYLlqhLUZBtWraOK4LDu1WNVKMpDwjoC8MHzy3N4HUU8Bj11AAe8j820 Uf3URmWOX9lmLPUkwZZ8P5nj8C7lUYP39hktnS+K+Uj8D24N4lAKNV5NXyByKVbWLHIL r64bldJ1FGfzt/Go1SHRwS7sQLX2z4zGfD7KKPNkGyV337A2Oml7gwJmh4Qi47eKOGK4 LDCqxWJ7nebvJHIvXrxK5YVy512jSe8U1HE6y6U9faRvD83+BaObuS7UaSU1nNx8X/6D arqWS8MRjVUB0heKFvAmMhpdsdbufINDb6Bn2pvddy/p+OQ3uZGsao8s1275CieBQTnF juKg==
X-Gm-Message-State: AOUpUlGGac051QNEWRSurG0fXlbONB/m66pHTn6KSqVerdGZS4Clqhvi MQNfE71xRSevWhnsqogjbkA=
X-Google-Smtp-Source: AAOMgpfPG8XRFwDczVZ/ZJs8vIMbpzgfNf/1u805QExLm5/GIpqU47beAO1J9GckGqIyiKQOO1KtLQ==
X-Received: by 2002:a0d:ce81:: with SMTP id q123-v6mr7785599ywd.8.1532406337136; Mon, 23 Jul 2018 21:25:37 -0700 (PDT)
Received: from ?IPv6:2601:192:4e00:596:22:8b71:4eb9:6006? ([2601:192:4e00:596:22:8b71:4eb9:6006]) by with ESMTPSA id 21-v6sm5350994ywb.88.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jul 2018 21:25:36 -0700 (PDT)
Message-ID: <>
MIME-Version: 1.0
To: John Levine <>, "" <>
From: Peter Occil <>
Date: Tue, 24 Jul 2018 00:25:38 -0400
Importance: normal
X-Priority: 3
In-Reply-To: <20180724041315.771A32002CDBCF@ary.qy>
References: <> <20180724041315.771A32002CDBCF@ary.qy>
Content-Type: multipart/alternative; boundary="_EB6EF9AE-B63D-4D61-8FF3-1618C927DCFB_"
Archived-At: <>
Subject: Re: [ietf-822] (no subject)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Jul 2018 04:25:39 -0000

I mean from the point of view of a software developer creating a library to generate email messages.  This software developer is not the one who comes up with values for header fields (such as URLs for List-Unsubscribe header fields).  If the developer's software library is passed a List-Unsubscribe header field value greater than 998 characters in length (e.g., when a third-party user uses that library to generate a blank message, then to set the List-Unsubscribe header field to such a value, then to generate a finished message), the software developer would then have to make a choice whether to program that library--
 - to reject the user-provided value, 
 - to accept the value and later be required to generate a message with a line exceeding 998 characters or to fold lines to fit that character limit, or 
 - to take some other error-handling action.

--Peter Occil

From: John Levine
Sent: Tuesday, July 24, 2018 12:13 AM
Subject: Re: [ietf-822] (no subject)

In article <> you write:

>> Plan B: figure out how to make your URLs short enough that your List-Unsubscribe
>headers are under 998 characters. ...

>Plan B is only feasible if the same person provides the URL _and_ writes the code to generate the
>List-Unsubscribe header field (or any other list header field) for the corresponding message; not so if a
>software library generates a message containing the value of a List-Unsubscribe (or other) header field
>provided by a (third-party) user that, while otherwise syntactically valid, could exceed 998 characters in
>length. ....

You lost me here.  Is there some force that requires you to pass giant
URLs to List-Unsubscribe?  If you want to interoperate, use reasonably
short URLs.  This should not be rocket science.