Policy-Controlled Handling of URLs in MIME Messages
draft-vinnakota-mime-url-policy-01

dispatch                                                 P.P.V. Rajendra
Internet-Draft                                             23 April 2026
Intended status: Informational                                          
Expires: 25 October 2026

          Policy-Controlled Handling of URLs in MIME Messages
                   draft-vinnakota-mime-url-policy-01

Abstract

   This document defines a MIME-based mechanism for policy-controlled
   handling of URLs in email messages.  The mechanism provides an
   alternative to hyperlink rewriting techniques used for click-time
   security enforcement.  By avoiding modification of original URLs and
   introducing policy metadata, this approach improves interoperability,
   preserves message integrity, and enhances privacy.

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 25 October 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.

Rajendra                 Expires 25 October 2026                [Page 1]
Internet-Draft               MIME URL Policy                  April 2026

Table of Contents

   1.  Conventions and Terminology . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Reduced User Interpretability . . . . . . . . . . . . . .   3
     3.2.  Privacy and Metadata Exposure . . . . . . . . . . . . . .   3
     3.3.  Functional Interference . . . . . . . . . . . . . . . . .   3
     3.4.  Access Latency  . . . . . . . . . . . . . . . . . . . . .   3
     3.5.  Evasion Techniques  . . . . . . . . . . . . . . . . . . .   3
     3.6.  Long-Term Stability . . . . . . . . . . . . . . . . . . .   4
     3.7.  Internationalization and Encoding Issues  . . . . . . . .   4
     3.8.  URL Extraction Complexity . . . . . . . . . . . . . . . .   4
     3.9.  Implicit Link Detection in Text Bodies  . . . . . . . . .   4
   4.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  MIME Header Field Definitions . . . . . . . . . . . . . . . .   6
     6.1.  URL-Policy  . . . . . . . . . . . . . . . . . . . . . . .   6
     6.2.  URL-Policy-Token  . . . . . . . . . . . . . . . . . . . .   6
   7.  Processing Model  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Example Flow  . . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Enforcement Model . . . . . . . . . . . . . . . . . . . . . .   7
   10. Token and Trust Model . . . . . . . . . . . . . . . . . . . .   7
   11. Client Behavior . . . . . . . . . . . . . . . . . . . . . . .   8
   12. Security Considerations . . . . . . . . . . . . . . . . . . .   8
   13. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   14. Backward Compatibility  . . . . . . . . . . . . . . . . . . .   9
   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Conventions and Terminology

   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, RFC 2119, and RFC 8174 when, and only when, they appear in all
   capitals, as shown here.

2.  Introduction

   Email security systems commonly employ hyperlink rewriting to enforce
   click-time protection against malicious content.  While effective in
   certain scenarios, this approach introduces complexity,
   interoperability issues, and privacy concerns.

   This document proposes a MIME-based mechanism that enables policy-
   controlled handling of URLs without modifying the original message
   content.

Rajendra                 Expires 25 October 2026                [Page 2]
Internet-Draft               MIME URL Policy                  April 2026

   Existing mechanisms such as message/external-body (RFC 2046) allow
   referencing external content but do not provide policy-controlled
   access or security enforcement.

3.  Problem Statement

3.1.  Reduced User Interpretability

   Hyperlink rewriting replaces original URLs with transformed
   representations that are often significantly longer and less human-
   readable.  This reduces the ability of users to inspect and verify
   link destinations.

3.2.  Privacy and Metadata Exposure

   Rewritten URLs may embed identifiers and routing metadata.  Accessing
   such URLs may expose interaction data to intermediary systems.

   URLs containing query parameters may include sensitive data such as
   tokens or identifiers, increasing the risk of exposure through logs
   or intermediaries.

3.3.  Functional Interference

   Rewriting may interfere with application behavior, including:

   *  One-time-use links (for example, password reset links)

   *  Token-based authentication flows

   *  URL fragments or client-side routing

   Automated analysis systems may access such links prior to user
   interaction, potentially invalidating time-sensitive tokens.

3.4.  Access Latency

   Users may experience delays due to click-time analysis, affecting
   usability and productivity.

3.5.  Evasion Techniques

   Attackers may employ redirection chains or delayed activation
   techniques to bypass static or pre-access analysis.

Rajendra                 Expires 25 October 2026                [Page 3]
Internet-Draft               MIME URL Policy                  April 2026

3.6.  Long-Term Stability

   Rewritten URLs depend on intermediary infrastructure, including
   vendor-specific domains and token formats.  Changes in such systems
   may cause previously delivered links to become non-functional over
   time.

3.7.  Internationalization and Encoding Issues

   Hyperlink rewriting may introduce errors when processing
   internationalized resource identifiers (IRIs) and Unicode-based URLs.

   Transformations applied during rewriting, including encoding,
   normalization, or wrapping, may alter the original URL representation
   and lead to invalid or inaccessible resources in practice.

   Such issues are particularly prevalent when URLs contain non-ASCII
   characters, percent-encoded sequences, or language-specific content.

   By preserving the original URL without modification, the mechanism
   defined in this document avoids such interoperability issues.

3.8.  URL Extraction Complexity

   URLs embedded in message bodies are not represented in a structured
   manner and must be extracted by parsing text/plain or text/html
   content.

   In text/plain bodies, URLs may be affected by line wrapping,
   formatting, or surrounding punctuation, leading to ambiguity in
   determining the intended URL.

   In text/html bodies, the visible text and hyperlink target may
   differ, requiring additional parsing.

   Different clients and security systems may extract URLs
   inconsistently, leading to broken links or inconsistent enforcement.

3.9.  Implicit Link Detection in Text Bodies

   Even in messages with Content-Type "text/plain", many modern mail
   clients automatically detect URL-like patterns and render them as
   clickable hyperlinks.

   As a result, security mechanisms must rely on heuristic extraction of
   URLs from unstructured text.

Rajendra                 Expires 25 October 2026                [Page 4]
Internet-Draft               MIME URL Policy                  April 2026

   This leads to inconsistent behavior across clients and systems.  The
   mechanism defined in this document avoids reliance on such parsing by
   using explicit policy metadata.

4.  Design Goals

   The mechanism defined in this document aims to:

   *  Avoid modification of original URLs

   *  Preserve compatibility with existing email systems

   *  Support internationalized resource identifiers without
      transformation

   *  Minimize exposure of sensitive data

   *  Enable policy-controlled access by recipient domains

   *  Improve long-term reliability of message-contained references

   *  Preserve exact URL encoding and representation, including
      internationalized and Unicode URLs

5.  Overview

   This document defines an optional MIME mechanism for associating
   policy metadata with URLs contained in email messages.

   If the mechanism is present, recipient systems MAY apply policy-
   controlled handling to URLs during user interaction.

   In typical deployments, the URL-Policy and URL-Policy-Token header
   fields are inserted or validated by the recipient domain's mail
   handling infrastructure.  Sender-provided values MUST NOT be assumed
   to be authoritative without validation.

   If the URL-Policy header field is present, it applies to all URLs
   contained within the associated message.

   Enforcement of policy-controlled URL handling is performed by
   recipient-side software and not by the MIME header fields themselves.

Rajendra                 Expires 25 October 2026                [Page 5]
Internet-Draft               MIME URL Policy                  April 2026

6.  MIME Header Field Definitions

6.1.  URL-Policy

   The URL-Policy header field specifies a policy-controlled endpoint.

   If present, this field indicates that URLs contained in the message
   MAY be evaluated through a policy-controlled endpoint determined by
   the recipient domain.

   Example:

   URL-Policy: https://policy.example.com/url-check

6.2.  URL-Policy-Token

   The URL-Policy-Token header field contains an opaque identifier
   generated by the recipient domain.

   The token is used to correlate message-specific context with the
   policy endpoint.

   Example:

   URL-Policy-Token: 4f9e7c12-8d11-47b1-a9c5-2d43c1f66e20

   Tokens MAY be generated per-recipient or per-message.  Per-recipient
   tokens provide stronger isolation and tracking capabilities.

7.  Processing Model

   When a user activates a URL in a message containing the URL-Policy
   header field:

   1.  The recipient-side software identifies the presence of policy
       metadata.

   2.  The original URL remains unchanged.

   3.  The recipient-side software MAY submit the URL and policy token
       to the policy endpoint.

   4.  The policy endpoint evaluates the request.

   5.  The endpoint returns a decision (for example, allow, block, or
       warn).

   6.  The original URL MUST NOT be modified as part of this process.

Rajendra                 Expires 25 October 2026                [Page 6]
Internet-Draft               MIME URL Policy                  April 2026

8.  Example Flow

   A message is received with the following header fields:

   URL-Policy: https://policy.example.com/url-check
   URL-Policy-Token: abc123

   When a user activates a URL, recipient-side software MAY perform a
   policy check prior to allowing navigation.

   For example, an implementation MAY send a request such as:

   POST /url-check HTTP/1.1
   Host: policy.example.com
   Content-Type: application/json

   {
     "token": "abc123",
     "url": "https://example.com/reset?token=XYZ"
   }

   The exact format and transport of such requests are implementation-
   specific and are not defined by this document.

9.  Enforcement Model

   Policy enforcement is expected to be performed by recipient-
   controlled systems such as webmail interfaces, mail clients, browser
   extensions, or enterprise security services.

   This specification does not require modifications to general-purpose
   web browsers.

10.  Token and Trust Model

   The URL-Policy-Token is an opaque identifier generated by the
   recipient domain.

   The token does not contain user or URL information and MUST be
   treated as opaque by clients.

   Enforcement of this mechanism is performed by recipient-side software
   that recognizes and enforces the defined header fields, such as
   webmail systems, mail clients, gateways, or associated enterprise
   security services.

   The policy endpoint MUST be able to resolve or validate the token
   using implementation-specific mechanisms such as:

Rajendra                 Expires 25 October 2026                [Page 7]
Internet-Draft               MIME URL Policy                  April 2026

   *  Shared storage

   *  Pre-registration APIs

   *  Cryptographic validation

   In deployments where a message is delivered to multiple recipients,
   recipient systems MAY generate distinct URL-Policy-Token values for
   each delivered message instance.  This enables recipient-specific
   policy enforcement, tracking, and incident response.

   Alternatively, a recipient domain MAY use a shared token representing
   a broader message context, provided that recipient identity is
   determined through local authenticated context at the time of URL
   activation.

   Sender-provided tokens or endpoints MUST NOT be trusted without
   validation by the recipient domain.

   Recipient systems MUST determine trusted policy endpoints based on
   local administrative policy.  The presence of the URL-Policy header
   field alone MUST NOT be sufficient to establish trust.

11.  Client Behavior

   Clients that support this mechanism:

   *  SHOULD detect the URL-Policy header field

   *  MAY route URL activations through the policy endpoint

   *  MUST use secure transport (HTTPS)

   Clients that do not support this mechanism:

   *  MUST ignore the header fields

   *  MUST process URLs normally

12.  Security Considerations

   This mechanism avoids modification of message content and therefore
   reduces interference with message authentication mechanisms such as
   DKIM.

   Unlike URL rewriting approaches, this mechanism does not require
   modification of message body content and preserves compatibility with
   DKIM signatures.

Rajendra                 Expires 25 October 2026                [Page 8]
Internet-Draft               MIME URL Policy                  April 2026

   This approach avoids issues related to URL normalization and encoding
   errors that may arise when processing internationalized URLs.

   Implementations MUST:

   *  Ensure secure communication with policy endpoints

   *  Protect against unauthorized access and replay attacks

   *  Validate trust relationships for policy endpoints

13.  Privacy Considerations

   Implementations SHOULD:

   *  Minimize collection of user interaction data

   *  Avoid exposing sensitive information in URLs

   *  Allow recipient domains to retain control over telemetry

14.  Backward Compatibility

   This mechanism is optional.

   Systems that do not recognize the defined header fields MUST ignore
   them and continue normal message processing.

15.  IANA Considerations

   This document requests registration of the following message header
   fields:

   Header field name: URL-Policy
   Applicable protocol: mail
   Status: provisional
   Author/Change controller: IETF
   Specification document: this document

   Header field name: URL-Policy-Token
   Applicable protocol: mail
   Status: provisional
   Author/Change controller: IETF
   Specification document: this document

Author's Address

   Phani Prasad Vinnakota Rajendra

Rajendra                 Expires 25 October 2026                [Page 9]
Internet-Draft               MIME URL Policy                  April 2026

   Email: vrppinvictaralabs@gmail.com

Rajendra                 Expires 25 October 2026               [Page 10]