Subject: [ietf-822] (no subject)

From: Peter Occil <[email-masked]>
Date: Tue, 24 Jul 2018 00:02:04 -0400

>Remember that MUST means "do this if you want to interoperate", not "do this or die."
>
> Plan A: update RFC 2369 to say MAY add spaces, send out a press release, wait for
everyone in the world to update their software to remove spaces when parsing List-x
headers.
>
> Plan B: figure out how to make your URLs short enough that your List-Unsubscribe
headers are under 998 characters.
> I know what I'd do.

Plan A is not what I suggest at all; I suggest rather that whitespace "SHOULD NOT" be generated between the angle brackets (compare with RFC 2557 sec. 4.4, which applies to the Content-Location header field, which uses URLs similarly to how List-Unsubscribe and certain other list header fields do).

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.  The software library would then have to either—

- reject the user-provided value (even though it’s otherwise syntactically valid – note that RFC 2369 neither specifies nor mandates a character limit), or 
- be forced to generate a message with a line exceeding 998 characters or to fold lines to fit that character limit, or
- take some other error-handling action.

--Peter

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2018 00:13:15 -0400

In article <[email-masked]> you write:

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

R's,
John

---

From: Peter Occil <[email-masked]>
Date: Tue, 24 Jul 2018 00:25:38 -0400

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
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-822] (no subject)

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 24 Jul 2018 00:28:11 -0400

> 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…

But this is engineering, not theology.  If you use long URLs in headers, 
they don't work very well.  So don't do that.  If it were my library I'd 
throw an error if the list-unsubscribe header didn't fit in 998 characters 
so the person calling it would know to fix whatever was generating giant 
URL strings.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Peter Occil <[email-masked]>
Date: Tue, 24 Jul 2018 00:33:12 -0400

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?

--Peter Occil

From: John R Levine
Sent: Tuesday, July 24, 2018 12:28 AM
To: Peter Occil
Cc: [email-masked]
Subject: RE: [ietf-822] (no subject)

[…]  If it were my library I'd 
throw an error if the list-unsubscribe header didn't fit in 998 characters 
so the person calling it would know to fix whatever was generating giant 
URL strings.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Jul 2018 07:22:52 -0700 (PDT)

> 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

---

From: "John R Levine" <[email-masked]>
Date: 24 Jul 2018 12:50:05 -0400

>> List-Unsubscribe header field? ...

> of calling for an update to the specification.

The question that started this was an observation that some software does 
a poor job of unfolding folded URLs in headers.  That's clearly a quality 
of implementation issue, like a lot of other issues in mail, and there is 
no reason to believe that waving fingers at people who misimplement stuff 
will make any difference. It's hardly the only place that unfolding URLs 
doesn't work -- try copying and pasting a URL that some MUA helpfully 
folded while quoting a message in a reply.

I suppose it would be nice to have some place to put advice like your life 
will be easier if your URLs fit on one line, but standards track RFCs 
doesn't seem like it.

Regards,

PS to Peter: in case it's not obvious, I do appreciate your finding places 
where the ABNF disagrees with the practice, even if we don't always agree 
on what to do about it.