Unified Rendering of Email Standard (URES)
draft-hackett-ures-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Will Hackett | ||
| Last updated | 2026-01-12 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hackett-ures-00
Independent Submission W. Hackett
Internet-Draft January 2026
Intended status: Standards Track
Expires: 16 July 2026
Unified Rendering of Email Standard (URES)
draft-hackett-ures-00
Abstract
This document specifies requirements for the uniform rendering of
HTML email content across mail user agents (MUAs). It addresses
critical inconsistencies in how email clients interpret HTML and CSS,
including dark mode adaptation, embedded asset handling, positioning
constraints, and secure SVG rendering. The specification aims to
eliminate the current fragmentation in email rendering while
maintaining backwards compatibility with existing MIME standards
(RFCs 2045-2049) and the Internet Message Format (RFC 5322).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 July 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hackett Expires 16 July 2026 [Page 1]
Internet-Draft URES January 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Document Structure Requirements . . . . . . . . . . . . . . . 6
3.1. HTML Version . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Required Document Structure . . . . . . . . . . . . . . . 6
3.3. Style Placement . . . . . . . . . . . . . . . . . . . . . 7
4. CSS Support Requirements . . . . . . . . . . . . . . . . . . 8
4.1. MUST Support Properties . . . . . . . . . . . . . . . . . 8
4.1.1. Box Model Properties . . . . . . . . . . . . . . . . 8
4.1.2. Typography Properties . . . . . . . . . . . . . . . . 8
4.1.3. Colour and Background Properties . . . . . . . . . . 8
4.1.4. Layout Properties . . . . . . . . . . . . . . . . . . 8
4.1.5. CSS Selectors . . . . . . . . . . . . . . . . . . . . 9
4.2. Positioning Constraints . . . . . . . . . . . . . . . . . 9
4.2.1. Permitted Values . . . . . . . . . . . . . . . . . . 9
4.2.2. Prohibited Values in Web Clients . . . . . . . . . . 9
4.3. z-index Handling . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Stacking Context Isolation . . . . . . . . . . . . . 10
4.3.2. Maximum z-index . . . . . . . . . . . . . . . . . . . 10
4.4. Flexbox . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. CSS Grid (SHOULD Support) . . . . . . . . . . . . . . . . 10
5. Dark Mode Adaptation . . . . . . . . . . . . . . . . . . . . 11
5.1. Colour Scheme Meta Tag . . . . . . . . . . . . . . . . . 11
5.2. Media Query Support . . . . . . . . . . . . . . . . . . . 11
5.3. Colour Inversion Rules . . . . . . . . . . . . . . . . . 12
5.3.1. Inversion Pairing . . . . . . . . . . . . . . . . . . 12
5.3.2. Contrast Preservation . . . . . . . . . . . . . . . . 12
6. Image and Asset Handling . . . . . . . . . . . . . . . . . . 12
6.1. Inline Base64 Images . . . . . . . . . . . . . . . . . . 12
6.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 12
6.1.2. Required Support . . . . . . . . . . . . . . . . . . 12
6.1.3. Size Limits . . . . . . . . . . . . . . . . . . . . . 13
6.1.4. Rendering Behaviour . . . . . . . . . . . . . . . . . 13
6.2. CID (Content-ID) Images . . . . . . . . . . . . . . . . . 13
Hackett Expires 16 July 2026 [Page 2]
Internet-Draft URES January 2026
6.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 13
6.2.2. Required Behaviour . . . . . . . . . . . . . . . . . 14
7. SVG Rendering . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Executive-Safe SVG Profile . . . . . . . . . . . . . . . 14
7.2. Prohibited SVG Elements . . . . . . . . . . . . . . . . . 15
7.2.1. Script and Event Handlers . . . . . . . . . . . . . . 15
7.2.2. External References . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.1. Script Execution . . . . . . . . . . . . . . . . . . . . 15
8.1.1. Prohibited Elements . . . . . . . . . . . . . . . . . 15
8.1.2. Prohibited Attributes . . . . . . . . . . . . . . . . 16
8.1.3. JavaScript URLs . . . . . . . . . . . . . . . . . . . 16
8.2. Positioning Attack Prevention . . . . . . . . . . . . . . 16
8.2.1. Fixed Position Blocking . . . . . . . . . . . . . . . 16
8.2.2. z-index Sandboxing . . . . . . . . . . . . . . . . . 16
8.3. Tracking Prevention . . . . . . . . . . . . . . . . . . . 16
8.3.1. Pixel Tracking . . . . . . . . . . . . . . . . . . . 17
8.3.2. Inline Content as Alternative . . . . . . . . . . . . 17
9. Accessibility . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Semantic HTML . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Alternative Text . . . . . . . . . . . . . . . . . . . . 17
9.3. Colour Contrast . . . . . . . . . . . . . . . . . . . . . 18
10. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 18
10.1. URES Level 1 (Baseline) . . . . . . . . . . . . . . . . 18
10.2. URES Level 2 (Enhanced) . . . . . . . . . . . . . . . . 18
10.3. URES Level 3 (Full) . . . . . . . . . . . . . . . . . . 19
11. Adoption Considerations . . . . . . . . . . . . . . . . . . . 19
11.1. Open Source Reference Implementations . . . . . . . . . 19
11.2. Precedent for Community-Driven Adoption . . . . . . . . 20
11.3. Incremental Adoption Path . . . . . . . . . . . . . . . 20
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Known Client Inconsistencies . . . . . . . . . . . . 22
A.1. CSS Support Matrix (Selected Properties) . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
1.1. Background
Email remains one of the most critical communication channels for
both personal and business communications. Despite decades of
development, the rendering of HTML email content remains
frustratingly inconsistent across mail user agents (MUAs).
Hackett Expires 16 July 2026 [Page 3]
Internet-Draft URES January 2026
The current standards landscape is fragmented:
* RFC 5322 [RFC5322] defines the Internet Message Format, specifying
header fields and basic body structure.
* RFCs 2045-2049 [RFC2045] define MIME, enabling multi-part messages
with various content types including text/html.
* The W3C maintains HTML and CSS specifications, but these are
designed for web browsers, not email clients.
* No RFC or standard body governs how email clients SHOULD or MUST
render HTML and CSS content.
This gap has resulted in a situation where email developers must
maintain extensive compatibility matrices, use archaic techniques
such as table-based layouts, and accept that their carefully crafted
emails will appear differently—or broken—across different clients.
1.2. Problem Statement
The following critical issues plague current email rendering:
1. *CSS Support Inconsistency:* Properties universally supported in
browsers (flexbox, grid, CSS variables) have zero or partial
support in major email clients. Gmail strips style tags in non-
AMP contexts. Outlook uses Microsoft Word's rendering engine.
2. *Dark Mode Chaos:* Email clients implement dark mode adaptation
differently. Some invert all colours, some honour author
preferences, some do nothing. Text becomes illegible when
foreground colours are inverted but backgrounds are not.
3. *Image Handling:* Base64 inline images are blocked by many
clients citing size concerns. CID attachments render
inconsistently. Remote images enable tracking and are blocked by
default.
4. *SVG Non-Support:* Most email clients strip or fail to render SVG
entirely, despite it being a W3C standard since 2001. Executives
receive emails with missing logos and charts.
5. *Positioning Attacks:* In web-based clients (Gmail, Outlook.com),
malicious use of position:fixed or high z-index values could
overlay phishing content atop the webmail UI.
Hackett Expires 16 July 2026 [Page 4]
Internet-Draft URES January 2026
6. *Layout Primitives:* Modern CSS layout (flexbox, grid) is
unsupported in Outlook desktop, forcing continued use of nested
HTML tables—a technique deprecated in web development since 2010.
7. *Font Rendering:* @font-face and web fonts work in approximately
40% of email clients, with no fallback standardisation.
8. *Media Queries:* Support for responsive design via @media queries
is inconsistent, with Gmail notably stripping them entirely.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
Mail User Agent (MUA) An application that accesses email on behalf
of a user. This includes desktop applications (Apple Mail,
Outlook, Thunderbird), web-based clients (Gmail, Outlook.com,
Yahoo Mail), and mobile applications (iOS Mail, Gmail app).
Rendering Engine The component of an MUA responsible for
interpreting and displaying HTML/CSS content. Some MUAs use web
browser engines (WebKit, Blink), others use proprietary engines
(Microsoft Word in Outlook desktop).
Dark Mode A display preference where the UI uses a dark background
with light text. Email clients may automatically adapt email
content to match this preference.
Colour Scheme The light or dark preference indicated by the email
author or inferred by the email client.
Inline Image An image embedded directly in the HTML using a data:
URI with base64 encoding, or referenced via Content-ID (CID).
Executive-Safe Content that renders correctly in email clients
commonly used by business executives, particularly Outlook
desktop, Apple Mail, and Gmail.
Stacking Context A three-dimensional conceptualisation of HTML
elements along an imaginary z-axis relative to the user. Elements
with z-index values form stacking contexts.
Hackett Expires 16 July 2026 [Page 5]
Internet-Draft URES January 2026
Content Isolation The practice of preventing email content from
affecting or overlaying the host application's user interface.
3. Document Structure Requirements
3.1. HTML Version
Conforming MUAs MUST support HTML5 document structure as defined in
[HTML5]. The following DOCTYPE declaration MUST be recognised:
<!DOCTYPE html>
MUAs MUST also accept and render documents using XHTML and HTML4
doctypes for backwards compatibility. However, email authors SHOULD
use HTML5.
MUAs MUST NOT require an XML declaration for HTML email content.
3.2. Required Document Structure
MUAs MUST correctly parse and render the following minimal document
structure:
Hackett Expires 16 July 2026 [Page 6]
Internet-Draft URES January 2026
<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml"
xmlns:o="urn:schemas-microsoft-com:office:office">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
<title>Email Subject</title>
<!--[if mso]>
<noscript>
<xml>
<o:OfficeDocumentSettings>
<o:PixelsPerInch>96</o:PixelsPerInch>
</o:OfficeDocumentSettings>
</xml>
</noscript>
<![endif]-->
<style>
/* Author styles */
</style>
</head>
<body>
<!-- Content -->
</body>
</html>
MUAs MUST preserve the html element's lang attribute and make it
available to accessibility tools.
MUAs MUST parse and apply the viewport meta tag for responsive
rendering on mobile devices.
MUAs supporting Microsoft Office conditional comments SHOULD
interpret <!--[if mso]> blocks appropriately.
3.3. Style Placement
MUAs MUST support CSS styles in ALL of the following locations:
1. Inline styles via the style attribute on any HTML element
2. Embedded styles via style elements in the head
3. Embedded styles via style elements in the body
MUAs MUST NOT strip or ignore style elements based on their placement
in the document.
Hackett Expires 16 July 2026 [Page 7]
Internet-Draft URES January 2026
MUAs MUST process multiple style elements in document order, applying
standard CSS cascade rules.
MUAs SHOULD support link rel="stylesheet" elements referencing
external stylesheets, subject to security controls defined in
Section 8.
When an MUA chooses not to load external stylesheets for security
reasons, it MUST still apply all inline and embedded styles.
4. CSS Support Requirements
4.1. MUST Support Properties
Conforming MUAs MUST support the following CSS properties with full
specification compliance:
4.1.1. Box Model Properties
margin, margin-top, margin-right, margin-bottom, margin-left,
padding, padding-top, padding-right, padding-bottom, padding-left,
border, border-width, border-style, border-color, border-top, border-
right, border-bottom, border-left, border-radius, border-top-left-
radius, border-top-right-radius, border-bottom-left-radius, border-
bottom-right-radius, width, min-width, max-width, height, min-height,
max-height, box-sizing
4.1.2. Typography Properties
font-family, font-size, font-weight, font-style, line-height, text-
align, text-decoration, text-decoration-line, text-decoration-color,
text-decoration-style, text-transform, letter-spacing, word-spacing,
white-space, vertical-align
4.1.3. Colour and Background Properties
color, background-color, background-image (for gradients and data:
URIs), background-position, background-repeat, background-size,
background (shorthand), opacity
4.1.4. Layout Properties
display (block, inline, inline-block, none, table, table-row, table-
cell, flex, inline-flex), position (static, relative), float, clear,
overflow, overflow-x, overflow-y
Hackett Expires 16 July 2026 [Page 8]
Internet-Draft URES January 2026
4.1.5. CSS Selectors
MUAs MUST support the following CSS selectors:
Type selectors (p, div, table), Class selectors (.classname), ID
selectors (#idname), Descendant combinator (div p), Child combinator
(div > p), Adjacent sibling combinator (h1 + p), Attribute selectors
([attr], [attr=value], [attr~=value], [attr|=value], [attr^=value],
[attr$=value], [attr*=value]), Pseudo-classes (:first-child, :last-
child, :nth-child(), :hover, :active, :focus, :visited, :link),
Pseudo-elements (::before, ::after, ::first-line, ::first-letter)
4.2. Positioning Constraints
For security reasons detailed in Section 8.2, MUAs MUST constrain the
position property as follows:
4.2.1. Permitted Values
MUAs MUST support:
* position: static (default, normal flow)
* position: relative (offset from normal position)
4.2.2. Prohibited Values in Web Clients
Web-based MUAs (those running within a web browser context) MUST
treat the following values as position: static:
* position: fixed
* position: absolute
* position: sticky
When an email contains these prohibited position values, the MUA MUST
either:
a. Render the element as position: static, OR
b. Render the element as position: relative with top, left, right,
and bottom values clamped to values that cannot cause the element
to escape its container.
Hackett Expires 16 July 2026 [Page 9]
Internet-Draft URES January 2026
4.3. z-index Handling
The z-index property controls stacking order within a stacking
context. MUAs MUST implement z-index handling that prevents
malicious overlay attacks.
4.3.1. Stacking Context Isolation
MUAs MUST create a new stacking context for email content that is
isolated from the host application. This means:
* z-index values within email content MUST NOT affect elements
outside the email content container.
* The email content container MUST have a z-index lower than any
application UI that could be targeted for spoofing.
4.3.2. Maximum z-index
MUAs SHOULD normalise z-index values within email content. If an
email specifies z-index: 2147483647 (the maximum 32-bit signed
integer), this MUST still be rendered below application UI.
Implementation approaches:
a. Contain email content in an iframe with srcdoc
b. Apply CSS containment (contain: strict)
c. Clamp z-index values to a maximum safe value
d. Render email in a separate compositing layer
4.4. Flexbox
MUAs MUST support CSS Flexible Box Layout [CSS-FLEXBOX-1] including:
display: flex, display: inline-flex, flex-direction, flex-wrap, flex-
flow, justify-content, align-items, align-content, order, flex-grow,
flex-shrink, flex-basis, flex, align-self
4.5. CSS Grid (SHOULD Support)
MUAs SHOULD support CSS Grid Layout [CSS-GRID-1]. Where supported,
MUAs MUST implement:
Hackett Expires 16 July 2026 [Page 10]
Internet-Draft URES January 2026
display: grid, display: inline-grid, grid-template-columns, grid-
template-rows, grid-template-areas, grid-gap, gap, row-gap, column-
gap, grid-column, grid-row, grid-area
5. Dark Mode Adaptation
Dark mode support is critical for email legibility. This section
defines requirements for consistent dark mode behaviour.
5.1. Colour Scheme Meta Tag
MUAs MUST recognise and honour the color-scheme meta tag:
<meta name="color-scheme" content="light dark">
Valid values:
* "light" - Email is designed for light mode only
* "dark" - Email is designed for dark mode only
* "light dark" - Email supports both modes
* "only light" - Email MUST NOT be adapted for dark mode
* "only dark" - Email MUST NOT be adapted for light mode
When color-scheme is set to "only light", MUAs MUST NOT invert,
adjust, or otherwise modify the colours specified by the email
author, even when the MUA or operating system is in dark mode.
5.2. Media Query Support
MUAs MUST support the prefers-color-scheme media query:
@media (prefers-color-scheme: dark) {
body {
background-color: #1a1a1a;
color: #ffffff;
}
}
@media (prefers-color-scheme: light) {
body {
background-color: #ffffff;
color: #1a1a1a;
}
}
Hackett Expires 16 July 2026 [Page 11]
Internet-Draft URES January 2026
When the user has selected dark mode in their MUA or operating
system, prefers-color-scheme: dark MUST match.
MUAs MUST NOT strip or ignore @media rules, including @media
(prefers-color-scheme: ...) rules.
5.3. Colour Inversion Rules
When an MUA applies automatic dark mode adaptation to an email that
has not opted out, the following rules MUST be followed:
5.3.1. Inversion Pairing
MUAs MUST NOT invert foreground colours without also inverting the
corresponding background colour. Specifically:
* If text colour is inverted from dark to light, the background
behind that text MUST also be inverted from light to dark.
* If a background is inverted, all foreground elements (text,
borders) on that background MUST be correspondingly adjusted.
5.3.2. Contrast Preservation
When inverting colours, MUAs MUST maintain a minimum contrast ratio
of 4.5:1 for normal text and 3:1 for large text, as defined in WCAG
2.1 [WCAG21].
6. Image and Asset Handling
6.1. Inline Base64 Images
Inline images using data: URIs provide a tracking-free method for
including images directly in email content. MUAs MUST support this
mechanism.
6.1.1. Syntax
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot">
6.1.2. Required Support
MUAs MUST render inline base64 images for the following MIME types:
* image/png
Hackett Expires 16 July 2026 [Page 12]
Internet-Draft URES January 2026
* image/jpeg (including image/jpg as an alias)
* image/gif
* image/webp
* image/svg+xml (subject to security restrictions in Section 7)
6.1.3. Size Limits
MUAs MUST support inline images with encoded sizes of at least:
* Individual image: 1 MB (after base64 encoding)
* Total per email: 10 MB (cumulative across all inline images)
MUAs MAY support larger sizes but MUST NOT fail to render images
below these thresholds.
6.1.4. Rendering Behaviour
MUAs MUST render inline base64 images:
* Without requiring user interaction to "load images"
* Without displaying tracking/privacy warnings for these images
* Immediately upon email open (no lazy-load deferral)
This behaviour is REQUIRED because inline images:
* Cannot be used for tracking (no external request is made)
* Are already fully downloaded as part of the email content
* Provide a privacy-preserving alternative to remote images
6.2. CID (Content-ID) Images
Content-ID references allow images attached to the email to be
displayed inline. MUAs MUST support this mechanism as defined in RFC
2392 [RFC2392].
6.2.1. Syntax
In the HTML body:
<img src="cid:image001@example.com" alt="Inline image">
Hackett Expires 16 July 2026 [Page 13]
Internet-Draft URES January 2026
6.2.2. Required Behaviour
MUAs MUST:
* Resolve cid: URLs to the corresponding MIME part
* Render the image inline at the point of reference
* Support CID references in both img elements and CSS background-
image properties
* Render CID images without requiring "load images" interaction
7. SVG Rendering
Scalable Vector Graphics provide resolution-independent images
essential for logos, icons, charts and diagrams. This section
defines an "Executive-Safe" SVG profile that balances functionality
with security.
7.1. Executive-Safe SVG Profile
The Executive-Safe SVG Profile defines a restricted subset of SVG
that MUST be supported by conforming MUAs. This profile is named to
emphasise that SVG content—particularly logos and charts—must render
correctly in email clients commonly used by business executives.
The Executive-Safe profile includes:
* All SVG 1.1 shape elements
* Text elements
* Gradients and patterns
* Basic filters (subset)
* Symbols and use references (internal only)
* Styling via presentation attributes and internal stylesheets
The Executive-Safe profile excludes:
* Script elements and event handlers
* External references
* Animation elements (use CSS animation instead)
Hackett Expires 16 July 2026 [Page 14]
Internet-Draft URES January 2026
* ForeignObject element
* Certain filter primitives
7.2. Prohibited SVG Elements
MUAs MUST strip or neutralise the following SVG elements:
7.2.1. Script and Event Handlers
The script element and any element with on* attributes (onclick,
onload, onerror, etc.) MUST be stripped.
7.2.2. External References
The following MUST NOT be resolved:
* use href="external.svg#symbol"
* image href="external.png"
* a href="javascript:..."
* feImage xlink:href="external.svg"
Note: Internal references within the same SVG document ARE permitted:
<use href="#internal-symbol"> <!-- OK -->
8. Security Considerations
Email is a primary vector for phishing, malware distribution and
social engineering attacks. MUAs MUST implement robust security
measures while rendering HTML content.
8.1. Script Execution
MUAs MUST NOT execute JavaScript or any other scripting language in
email content.
8.1.1. Prohibited Elements
The following elements MUST be stripped or rendered inert:
* script element
* noscript element (SHOULD be displayed)
Hackett Expires 16 July 2026 [Page 15]
Internet-Draft URES January 2026
8.1.2. Prohibited Attributes
The following attributes MUST be stripped from all elements:
All on* event handlers: onclick, onload, onerror, onmouseover,
onfocus, onblur, onsubmit, etc.
8.1.3. JavaScript URLs
The following URL schemes MUST NOT be executable:
* javascript:
* vbscript:
* data:text/html (when containing script)
MUAs MUST either:
a. Strip href/src attributes containing these schemes, OR
b. Replace them with safe values (e.g., href="#")
8.2. Positioning Attack Prevention
In web-based MUAs, malicious use of CSS positioning could overlay
deceptive content atop the webmail UI.
8.2.1. Fixed Position Blocking
MUAs MUST NOT render position: fixed as specified. Such elements:
* MUST be rendered as position: static or position: relative
* MUST remain within the email content area
* MUST NOT overlay any part of the MUA interface
8.2.2. z-index Sandboxing
MUAs MUST ensure that email content z-index values cannot cause
elements to render above the MUA interface.
Implementation: Create a new stacking context for email content that
is positioned below all MUA UI elements.
8.3. Tracking Prevention
Hackett Expires 16 July 2026 [Page 16]
Internet-Draft URES January 2026
8.3.1. Pixel Tracking
Remote images are commonly used as tracking pixels. MUAs SHOULD:
* Block remote images by default
* Provide clear UI indication when images are blocked
* Allow users to load images per-email or per-sender
8.3.2. Inline Content as Alternative
The mandatory support for base64 inline images (Section 6.1) and CID
images (Section 6.2) provides senders with tracking-free alternatives
for embedding images.
9. Accessibility
Email content MUST be accessible to users with disabilities. MUAs
MUST NOT strip or alter HTML that supports accessibility.
9.1. Semantic HTML
MUAs MUST correctly interpret and render semantic HTML elements:
header, footer, nav, main, article, section, aside, h1 through h6, p,
ul, ol, li, dl, dt, dd, table, th, td (with scope attributes),
figure, figcaption, blockquote, cite, strong, em
MUAs MUST NOT flatten semantic structure (e.g., converting all
elements to div or span).
9.2. Alternative Text
MUAs MUST:
* Display alt attribute text when images are not loaded
* Expose alt text to assistive technologies
* Support role and aria-* attributes
MUAs MUST NOT strip:
alt, title, role, aria-label, aria-labelledby, aria-describedby,
aria-hidden, aria-live, aria-atomic, aria-relevant
Hackett Expires 16 July 2026 [Page 17]
Internet-Draft URES January 2026
9.3. Colour Contrast
When MUAs apply automatic dark mode adaptation (Section 5.3), the
resulting colour combinations MUST maintain WCAG 2.1 AA contrast
ratios:
* Normal text: 4.5:1
* Large text: 3:1
* UI components and graphics: 3:1
10. Conformance Levels
To facilitate gradual adoption, this specification defines three
conformance levels.
10.1. URES Level 1 (Baseline)
An MUA conforming to URES Level 1 MUST:
* Support all properties in Section 4.1
* Support inline base64 images (Section 6.1)
* Support CID images (Section 6.2)
* Strip all JavaScript (Section 8.1)
* Implement positioning constraints (Section 4.2)
* Support prefers-color-scheme media query (Section 5.2)
* Preserve semantic HTML (Section 9.1)
10.2. URES Level 2 (Enhanced)
An MUA conforming to URES Level 2 MUST:
* Meet all Level 1 requirements
* Support the Executive-Safe SVG Profile (Section 7)
* Support CSS Flexbox (Section 4.4)
* Implement dark mode adaptation rules (Section 5.3)
* Support picture element
Hackett Expires 16 July 2026 [Page 18]
Internet-Draft URES January 2026
* Support CSS custom properties (variables)
10.3. URES Level 3 (Full)
An MUA conforming to URES Level 3 MUST:
* Meet all Level 2 requirements
* Support CSS Grid (Section 4.5)
* Support @font-face
* Support CSS animations (with user preference for reduced motion)
* Implement full CSP
* Provide tracking prevention (Section 8.3)
11. Adoption Considerations
This section addresses practical considerations for adoption of this
specification by email client vendors.
11.1. Open Source Reference Implementations
The authors recognise that some email client vendors have
historically been reluctant to invest in standards-compliant
rendering engines, preferring instead to repurpose existing
technologies (such as word processing engines) that were never
designed for standards-compliant HTML/CSS rendering.
To address this, the community intends to develop and maintain open
source reference implementations of URES-compliant rendering
components. These implementations will be:
* Licensed under permissive terms (MIT, Apache 2.0, or similar)
* Designed for embedding in both native and web-based clients
* Maintained by the community with regular security updates
* Tested against the URES conformance test suite
Vendors who have historically chosen not to invest in standards-
compliant rendering may simply adopt these community-maintained
implementations when ready, rather than continuing to maintain
proprietary solutions that diverge from industry consensus.
Hackett Expires 16 July 2026 [Page 19]
Internet-Draft URES January 2026
11.2. Precedent for Community-Driven Adoption
This approach mirrors successful adoption patterns across the
software industry, where vendors have benefited from community-
developed standards and implementations rather than maintaining
proprietary alternatives:
* React (Meta): Now embedded across enterprise applications,
including those from vendors who initially resisted component-
based UI architectures.
* GraphQL (Meta): Adopted by major cloud platforms after community
momentum demonstrated clear benefits over proprietary query
languages.
* OpenTelemetry (CNCF): Observability standard now integrated across
all major cloud providers, replacing fragmented proprietary
instrumentation.
* Chromium (Google): The rendering engine now powers multiple
browsers from vendors who previously maintained independent
engines, including Microsoft Edge.
* VS Code / Monaco Editor (Microsoft): An acknowledgement that
community-driven tooling often surpasses proprietary alternatives.
Vendors currently maintaining non-compliant rendering engines face an
ongoing maintenance burden for technology that provides no
competitive advantage. The availability of URES-compliant open
source alternatives offers a path to reduced maintenance costs while
improving interoperability for their users.
11.3. Incremental Adoption Path
Vendors need not adopt all conformance levels simultaneously. The
three-tier conformance structure (Section 10) enables:
1. Level 1 adoption with minimal investment, addressing the most
critical rendering inconsistencies.
2. Level 2 adoption as community implementations mature, adding
modern layout and dark mode support.
3. Level 3 adoption for full feature parity with web browsers,
enabled by proven, stable open source components.
Hackett Expires 16 July 2026 [Page 20]
Internet-Draft URES January 2026
This graduated approach ensures that even conservative vendors can
adopt URES without significant risk, leveraging battle-tested
implementations developed and maintained by the broader community.
12. IANA Considerations
This document registers a new media feature for the prefers-color-
scheme-only media query:
Name: prefers-color-scheme-only
Values: light | dark
Applies to: visual media
Description: Indicates that the email author has requested no
automatic colour scheme adaptation.
This document requests registration of the following HTTP header for
use in email content negotiation:
Header field name: X-Email-Renderer-Level
Applicable protocol: HTTP (for web-based MUAs)
Status: Informational
Author/Change controller: IETF
Specification document(s): This document
Values: 1 | 2 | 3
Example: X-Email-Renderer-Level: 2
13. References
13.1. Normative References
[CSS-FLEXBOX-1]
Atkins Jr., T., Etemad, E., and R. Atanassov, "CSS
Flexible Box Layout Module Level 1", W3C Candidate
Recommendation, November 2018,
<https://www.w3.org/TR/css-flexbox-1/>.
Hackett Expires 16 July 2026 [Page 21]
Internet-Draft URES January 2026
[CSS-GRID-1]
Atkins Jr., T., Etemad, E., and R. Atanassov, "CSS Grid
Layout Module Level 1", W3C Candidate Recommendation,
December 2020, <https://www.w3.org/TR/css-grid-1/>.
[HTML5] WHATWG, "HTML Living Standard",
<https://html.spec.whatwg.org/>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References
[CANIEMAIL]
Community project, "Can I email... Support tables for HTML
and CSS in emails", <https://www.caniemail.com/>.
[WCAG21] W3C, "Web Content Accessibility Guidelines (WCAG) 2.1",
W3C Recommendation, June 2018,
<https://www.w3.org/TR/WCAG21/>.
Appendix A. Known Client Inconsistencies
This appendix documents specific inconsistencies in current email
clients that this RFC aims to address. Data sourced from caniemail
project [CANIEMAIL] and direct testing as of January 2026.
Hackett Expires 16 July 2026 [Page 22]
Internet-Draft URES January 2026
A.1. CSS Support Matrix (Selected Properties)
+====================+=========+=====+=========+=====+=====+========+
| Property | Gmail |O.com| O.app |Apple|Yahoo| T-bird |
+====================+=========+=====+=========+=====+=====+========+
| style in head | Partial |Yes | Yes |Yes |Yes | Yes |
+--------------------+---------+-----+---------+-----+-----+--------+
| display: flex | Yes |Yes | No |Yes |Yes | Yes |
+--------------------+---------+-----+---------+-----+-----+--------+
| display: grid | Yes |Yes | No |Yes |Yes | Yes |
+--------------------+---------+-----+---------+-----+-----+--------+
| position: fixed | No |No | No |No |No | Yes |
+--------------------+---------+-----+---------+-----+-----+--------+
| position: | No |No | Yes |Yes |No | Yes |
| absolute | | | | | | |
+--------------------+---------+-----+---------+-----+-----+--------+
| background-image | Yes |Yes | No |Yes |Yes | Yes |
+--------------------+---------+-----+---------+-----+-----+--------+
| border-radius | Yes |Yes | Partial |Yes |Yes | Yes |
+--------------------+---------+-----+---------+-----+-----+--------+
| @media queries | No |Yes | Yes |Yes |Yes | Yes |
+--------------------+---------+-----+---------+-----+-----+--------+
| CSS variables | Yes |Yes | No |Yes |Yes | Yes |
+--------------------+---------+-----+---------+-----+-----+--------+
| @font-face | No |Yes | No |Yes |No | Yes |
+--------------------+---------+-----+---------+-----+-----+--------+
| ::before/::after | No |Yes | No |Yes |Yes | Yes |
+--------------------+---------+-----+---------+-----+-----+--------+
Table 1
Legend: Gmail (web), O.com (Outlook.com), O.app (Outlook desktop),
Apple (Apple Mail), Yahoo (Yahoo Mail), T-bird (Thunderbird)
Acknowledgements
The author wishes to acknowledge the work of the Email Standards
Project (2007-2011), the W3C HTML for Email Community Group
(2014-2023), and the caniemail.com project for documenting the
inconsistencies that this specification aims to address.
Author's Address
Will Hackett
London
United Kingdom
Email: will@willhackett.uk
URI: https://willhackett.uk
Hackett Expires 16 July 2026 [Page 23]