Network Working Group R. Haddad Internet-Draft Inventor Intended status: Standards Track November 27, 2025 Expires: May 31, 2026 Mail Pre-Flight Template Discovery Protocol (MPTDP) draft-haddad-mptdp-00 Abstract This document specifies the Mail Pre-Flight Template Discovery Protocol (MPTDP). This mechanism allows a Mail User Agent (MUA) to proactively discover and retrieve a structured message template based on the recipient's public email address, prior to message composition. It utilizes a well-known URI structure and provides a security manifest to prevent address enumeration. 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 May 31, 2026. Copyright Notice Copyright (c) 2025 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. 1. Introduction Current email composition relies heavily on unstructured text or reactive mechanisms (auto-responders). There is no standard way for a recipient domain to dictate the structure of an incoming message before the sender begins typing. This leads to incomplete correspondence, operational inefficiencies, and poor user experience. MPTDP solves this by introducing a "Pre-Flight" check via HTTP, leveraging the existing web infrastructure of the recipient domain. 2. Conventions and Definitions 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. 3. Protocol Overview The protocol operates in a sequence triggered by the MUA upon entry of a valid email address string. +------+ +-------------+ +----------+ | User | | Client (MUA)| | Server | +--+---+ +------+------+ +-----+----+ | | | | Types "contact@" | | +----------------------->| | | | 1. Check Manifest | | |------------------------>| | | GET /.well-known/... | | |<------------------------| | | 200 OK (Allowed) | | | | | | 2. Get Template | | |------------------------>| | | GET ...?addr=contact | | |<------------------------| | | 200 OK (JSON Payload) | | | | | 3. Form Appears | | |<-----------------------| | | | | +--+---+ +------+------+ +-----+----+ Figure 1: MPTDP Communication Sequence 4. Discovery Mechanism 4.1. The Manifest (Security Layer) To prevent email enumeration (privacy attacks), a domain MUST publish a manifest listing authorized public endpoints. o URI: https://{domain}/.well-known/mptdp-manifest.json o Format: JSON Example: { "version": "1.0", "public_endpoints": ["support", "sales", "jobs"], "wildcard": false } The MUA MUST NOT issue a specific template request for an address local-part not listed in this manifest. 4.2. Template Retrieval If authorized by the manifest, the MUA issues the retrieval request. o URI: https://{domain}/.well-known/mptdp o Method: GET o Parameters: * address (REQUIRED): The local-part of the email. * lang (OPTIONAL): ISO 639-1 language code. 5. Response Format The server responds with a JSON object defining the message structure. Example Payload: { "status": "success", "content": { "subject_template": "Claim [REF] - Assistance", "body_structure": [ { "type": "text", "value": "Hello Support," }, { "type": "input", "label": "Contract ID", "required": true } ] }, "security": { "signature": "sha256:7f83b165..." } } 6. Security Considerations 6.1. Privacy The Manifest mechanism (Section 4.1) is critical. Implementers MUST ensure that private addresses (e.g., individual employees) are not exposed via this protocol unless explicitly intended. 6.2. Phishing and Integrity MUAs SHOULD verify the "security.signature" field against the domain's public keys (DKIM or specific DNS TXT record) to ensure the template has not been tampered with during transit. HTTPS is MANDATORY. 7. IANA Considerations This document requests the registration of the URI suffix "mptdp" in the "Well-Known URIs" registry as defined by RFC 8615. 8. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, May 2019. Author's Address Rachid Haddad Email: haddad.rachid2006@gmail.com