MIME Encoding for List-Unsubscribe Header
Closed this issue · 1 comments
In https://aboutmy.email/270cc13c/unsubscribe there's an error that says
List-Unsubscribe header has been MIME encoded. This may work at some mailbox providers but is not valid.
Try as I might, I couldn't find the part of the spec where it says that it's not valid.
List-Unsubscribe headers can be quite long (that is, longer than 65-72 characters, see https://datatracker.ietf.org/doc/html/rfc822#section-3.4.8) and as such should be folded (see https://datatracker.ietf.org/doc/html/rfc822#section-3.1.1). Folded header values that do not have whitespace pose a problem when being unfolded. Specifically
This: Header
Value
could be unfolded as This: Header Value or This: HeaderValue depending on who does the unfolding.
To battle this issue, it's RFC2047 (https://datatracker.ietf.org/doc/html/rfc2047) introduced header value encoding which helps disambiguate this entire "unfolding" process and make it repeatable.
There's a similar discussion over at jstedfast/MimeKit#236 (comment) and with MimeKit being one of the strictest MIME libraries out there I'm thinking that MIME-encoding List-Unsubscribe header is a perfectly valid option.
RFC 2047 is the place to start. If you check section 5 of RFC 2047 it's very explicit about where RFC 2047 encoding may and may not be used.
It may only be used in *text fields, such as free text in Subject or Comments, in parenthesised comments, and in word entities in a phrase.
The URLs in a List-Unsubscribe header are not any of those, so MUST NOT be RFC 2047 encoded.
(RFC 2047 provides a non-exhaustive list of things that must not be encoded, and that includes things like addr-spec and "any structured field body except within a 'comment' or 'phrase'".)
If a List-Unsubscribe header has RFC 2047 encoding applied to it that will either make the header itself invalid, make the URLs it contains in valid or leave the URLs syntactically valid, just not pointing where you think they are.
A mailbox provider can choose to accept an invalid header, decode it and use the results - either intentionally or because their header parsing library (incorrectly) applies RFC 2047 decoding to things that look encoded - but the sender is still sending invalid mail.
If I were an MUA developer I'd try and use invalid List-Unsubscribe headers in that way, as that'll provide the best experience for everyone, but as an email sender you should use a valid syntax.