Is quoted printable text allowed in the List-Unsubscribe header?

Key findings

• RFC 2047 limitations: RFC 2047, which defines encoded words like quoted-printable for non-ASCII text, explicitly limits their use to specific header fields, primarily Subject, Comments, and within the phrase part of address fields.
• List-Unsubscribe RFC: RFC 2369, which governs the List-Unsubscribe header, specifies that its value should be one or more URLs (Uniform Resource Locators) or mailto: URIs (Uniform Resource Identifiers). It does not provide for the internal encoding of these URIs with quoted-printable.
• Non-compliant formatting: Using quoted-printable encoding directly within the List-Unsubscribe URL is generally considered a malformed header, as it falls outside the specified permissible contexts for such encoding.
• Accidental functionality: If a malformed List-Unsubscribe header (with quoted-printable) appears to function at certain ISPs, it is likely due to accidental or lenient parsing by that specific provider, rather than proper adherence to standards.
• Client-specific behavior: Email clients and ISPs may interpret non-standard headers differently, leading to inconsistent display or functionality. Some may attempt to decode it, while others may not, impacting the visibility of the unsubscribe option.

Key considerations

• Deliverability impact: Malformed headers can signal poor sending practices to ISPs, potentially leading to deliverability issues and an increased likelihood of emails landing in the spam folder. Understanding email deliverability issues is crucial.
• Unsubscribe functionality: The primary purpose of the List-Unsubscribe header is to offer an easy opt-out mechanism. If it is improperly formatted, email clients may not display the unsubscribe button, forcing recipients to mark emails as spam, which negatively impacts sender reputation.
• Sender reputation: Consistent adherence to email standards, including header formatting, contributes positively to sender reputation. Deviations can lead to a damaged reputation and poor inbox placement.
• Compliance: While not directly a compliance issue in many regions, hindering a clear unsubscribe path can have implications for anti-spam regulations (e.g., CAN-SPAM). The List-Unsubscribe header simplifies this process.
• Testing and monitoring: Regularly test your email headers and monitor how List-Unsubscribe functionality performs across various email clients and ISPs to identify and rectify any issues promptly.

Key opinions

• Suspicious formatting: Many marketers express suspicion when their ESPs generate List-Unsubscribe headers containing quoted-printable text, recognizing it as an unusual and potentially problematic format.
• Inconsistent decoding: Observations show that while some clients, like Gmail, may successfully decode these headers, others, such as Apple Mail or Hotmail, often do not, resulting in the unsubscribe link not appearing.
• ESP responsibility: Marketers frequently find that their ESPs are responsible for encoding headers in a non-standard way, prompting them to contact their providers for clarification and resolution.
• Functionality over specification: There's a pragmatic recognition that despite being out of spec, some ISPs may still process these headers, suggesting a gap between strict RFC adherence and real-world implementation by providers.
• Impact on user experience: A non-functional unsubscribe link can lead to a poor user experience, potentially increasing spam complaints, which sends emails to spam.

Key considerations

• ESP partnership: Engage with your ESP to ensure they are generating compliant List-Unsubscribe headers. If they are not, escalate the issue as it can directly affect your deliverability.
• Testing across clients: Regularly test your email campaigns across a wide range of popular email clients (e.g., Gmail, Outlook, Apple Mail) to ensure the List-Unsubscribe header functions correctly everywhere. This is part of a thorough email deliverability test.
• Compliance and user experience: Prioritize a seamless unsubscribe experience. The List-Unsubscribe header is a key component for both compliance and recipient satisfaction.
• Monitor spam complaints: A rise in spam complaints might indicate that your unsubscribe mechanism, including the header, isn't working as intended for a segment of your audience.

Key opinions

• Not useful: It is generally accepted that quoted-printable text in this header is not useful and may not function as intended.
• RFC 2047 limits: RFC 2047 clearly defines the limited contexts where encoded words can be used, none of which include directly encoding the List-Unsubscribe URI.
• Malformed header: An encoded List-Unsubscribe header is considered badly formed and outside the technical specifications of RFC 2047 and RFC 2369.
• Accidental functionality: Any instances where such a header appears to work are likely due to lenient or accidental parsing by the recipient's ISP, not proper design.
• Unwise behavior: Employing such non-standard encoding is deemed unwise and poses a significant risk that the unsubscribe functionality will fail for some recipients. This ties into issues with what RFC 5322 says versus what actually works.

Key considerations

• Adherence to RFCs: Always prioritize strict adherence to relevant RFCs (like 2047 and 2369) when constructing email headers to ensure consistent and reliable functionality across all platforms.
• Risk of non-compliance: While some ISPs might be lenient, relying on non-standard practices can lead to deliverability problems, including emails being blocklisted or sent to spam, affecting domain reputation.
• Impact on user experience: A non-functional unsubscribe link will frustrate recipients, potentially increasing direct spam complaints or leading to blocklisting, impacting sender reputation.
• Monitoring: Implement robust monitoring of email headers and unsubscribe functionality to quickly identify and address any non-compliant formatting or delivery issues.
• ESP evaluation: Critically evaluate ESPs that generate non-compliant headers, as this indicates a potential lack of understanding or adherence to foundational email standards.

Key findings

• RFC 2047: This RFC defines a mechanism for encoding non-ASCII text in email headers. It specifies that encoded words (e.g., using quoted-printable) are only allowed in particular header fields, such as Subject and Comments, or within a phrase (display name) before an email address.
• RFC 2369: This RFC details the List-Unsubscribe header, stating its value should be one or more URIs. It does not mention or permit the use of quoted-printable encoding for the URIs themselves.
• Header structure: Email headers are generally structured to contain specific types of values (e.g., URLs, email addresses, dates). Inserting quoted-printable encoding outside its designated contexts constitutes a non-standard, malformed header.
• URI syntax: URIs (including URLs and mailto: links) have their own defined character sets and encoding rules (e.g., URL encoding for special characters), which are separate from RFC 2047's encoded words. This is important for how unencoded URLs impact deliverability.
• Interoperability: Adherence to RFCs is critical for ensuring that emails are correctly interpreted and processed by diverse email clients and servers worldwide.

Key considerations

• Strict compliance: Documentation dictates that quoted-printable encoding is not permitted within the List-Unsubscribe URI itself. Deviations from this standard risk the header's functionality.
• Official references: Consult RFCs 2047 and 2369 as the definitive sources for understanding correct List-Unsubscribe header formatting. The Mailfence Blog provides a good overview of email headers.
• Encoding types: Understand the difference between character encoding for message bodies (like quoted-printable for MIME parts) and URI encoding, which follows different rules. Improper encoding can affect email deliverability.
• Provider compliance: Ensure your ESP adheres to these RFCs. If they are sending malformed headers, it's a critical issue that needs to be addressed for deliverability.