Network Working Group                                         T. Madaras
Internet-Draft                                                  P. Estis
Intended status: Experimental            GuardSuite, a VXMSecure Company
Expires: 5 June 2026                                     2 December 2025


 GuardMail Protocol (GMP): Authenticated Messaging with Non-Repudiable
                         Cryptographic Receipts
                     draft-madaras-guardmail-gmp-00

Abstract

   This document specifies the GuardMail Protocol (GMP), a framework for
   authenticated outbound messaging that provides cryptographic proof of
   origin, integrity, and policy compliance for email and file-based
   communications.  GMP introduces GuardMail Receipts (GMRs), signed
   metadata structures bound to sender identity and message content that
   allow recipients to verify authenticity independent of transport
   mechanisms such as SPF, DKIM, and DMARC.

   GMP provides a modern, interoperable method for organizations to
   protect against impersonation, deepfake-based fraud, unauthorized
   content changes, and spoofed internal communications in enterprise
   environments.

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 June 2026.

Copyright Notice

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





Madaras & Estis            Expires 5 June 2026                  [Page 1]

Internet-Draft                GuardMail GMP                December 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   3
   5.  GuardMail Receipt (GMR) Structure . . . . . . . . . . . . . .   4
   6.  Outbound Stamping Process . . . . . . . . . . . . . . . . . .   5
   7.  Verification Process (Inbound)  . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Email and messaging systems commonly rely on SPF, DKIM, and DMARC to
   provide domain-level authentication and alignment.  While these
   mechanisms help detect some forms of spoofing, they do not provide a
   sender-specific, action-bound, or content-bound non-repudiation
   mechanism.  A message may appear to originate from a legitimate
   domain while still being malicious, manipulated, or unauthorized.

   GuardMail Protocol (GMP) introduces GuardMail Receipts (GMRs), which
   are cryptographically signed metadata objects that bind a sender
   identity to a particular message instance and its canonical content
   representation.  A recipient or automated verifier can use the GMR to
   determine whether a message is authentic and intact, regardless of
   the underlying transport.

   GMP is designed to work with existing email infrastructure and can be
   deployed incrementally.  It is intended to complement, not replace,
   mechanisms such as SPF, DKIM, and DMARC.









Madaras & Estis            Expires 5 June 2026                  [Page 2]

Internet-Draft                GuardMail GMP                December 2025


2.  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.

3.  Terminology

   The following terms are used throughout this document:

   GMR (GuardMail Receipt)  A cryptographically signed metadata
      structure associated with a specific outbound message instance,
      containing sender identity and content hashes.

   GMP (GuardMail Protocol)  The protocol described in this document,
      defining how GMRs are constructed, attached, and verified.

   GMS (GuardMail Stamping Service)  The service that creates and
      attaches GMRs to outbound messages on behalf of a sending domain
      or organization.

   VERIFIER  A service or component that validates GMRs on received
      messages.

   MUA (Mail User Agent)  Email client used by end-users.

   MTA (Mail Transfer Agent)  Server responsible for transmitting email
      between domains.

4.  Architectural Overview

   GMP assumes the following high-level architecture:

   1.  A sender composes a message using a MUA.

   2.  The message is submitted to a sending MTA, which forwards it to
       the GuardMail Stamping Service (GMS) or applies stamping locally.

   3.  The GMS computes content hashes, constructs a GMR, signs it, and
       attaches it to the message as a header and/or footer block.

   4.  The stamped message is delivered over existing SMTP
       infrastructure to the recipient's MTA and MUA.






Madaras & Estis            Expires 5 June 2026                  [Page 3]

Internet-Draft                GuardMail GMP                December 2025


   5.  A VERIFIER (running as part of the MUA, a plugin, or a gateway)
       extracts the GMR, recomputes hashes, validates the signature, and
       presents a verification status.

   GMP does not mandate where the GMS or VERIFIER reside; they MAY be
   implemented as standalone services, integrated gateways, MTA
   extensions, or client-side components.

5.  GuardMail Receipt (GMR) Structure

   A GMR is a structured metadata object that MUST contain at least the
   following fields:

   *  rid: A globally unique receipt identifier for this message.

   *  sender_id: A sender identity string representing the originator.

   *  org_id: An organization identifier for the sending domain or
      entity.

   *  hdr_hash: A SHA3-256 hash of the canonicalized header set.

   *  body_hash: A SHA3-256 hash of the canonicalized message body.

   *  att_hash: A SHA3-256 hash of the attachments, or the string "NONE"
      if there are no attachments.

   *  policy_id: An optional identifier referencing the policy or
      profile used when stamping this message.

   *  ts_issued: The timestamp at which the GMR was created.

   *  signature: A digital signature computed over the above fields
      using a key controlled by the GMS for the sending organization.

   *  verify_url: An HTTPS URL for independent verification.

   The following header format is RECOMMENDED:

   X-GuardMail-Stamp: rid=<ID>; sender_id=<sender>;
     org_id=<org>; hdr_hash=<hex>; body_hash=<hex>;
     att_hash=<hex-or-NONE>; ts=<ISO-8601>;
     sig_alg=<alg>; signature=<base64>; verify_url=<url>

   A body footer MAY be added for human consumption:






Madaras & Estis            Expires 5 June 2026                  [Page 4]

Internet-Draft                GuardMail GMP                December 2025


   ----BEGIN GUARDMAIL RECEIPT----
   Receipt-ID: <ID>
   Sender-ID: <sender>
   Org-ID: <org>
   Issued-At: <timestamp>
   Verification: https://verify.example.com/r/<ID>
   ----END GUARDMAIL RECEIPT----

   The header representation is authoritative for automated
   verification; the footer is primarily cosmetic.

6.  Outbound Stamping Process

   The GuardMail Stamping Service (GMS) performs the following steps
   when stamping a message:

   1.  Canonicalize the headers and body.

   2.  Compute hdr_hash, body_hash, and att_hash.

   3.  Construct a GMR with the required fields.

   4.  Sign the GMR with an organizational key.

   5.  Insert the GMR into the message as an "X-GuardMail-Stamp" header
       and/or a footer block.

   6.  Deliver the stamped message to the next-hop MTA.

   MUAs and intermediate MTAs SHOULD preserve the GMR header and any
   associated footer blocks.

7.  Verification Process (Inbound)

   A VERIFIER (or compatible component) MUST implement at least the
   following steps:

   1.  Extract the GMR from the "X-GuardMail-Stamp" header.

   2.  Canonicalize message headers and body using the same algorithm as
       the GMS.

   3.  Compute local hdr_hash, body_hash, and att_hash from the received
       message.

   4.  Compare the locally computed hashes with those contained in the
       GMR.




Madaras & Estis            Expires 5 June 2026                  [Page 5]

Internet-Draft                GuardMail GMP                December 2025


   5.  Validate the GMR signature using a trusted public key or
       certificate for the sending organization or GMS.

   6.  Optionally contact the verify_url endpoint for revocation checks,
       policy evaluation, or additional status information.

   Based on these checks, the VERIFIER SHOULD produce one of:

   *  VALID

   *  TAMPERED

   *  UNTRUSTED

   *  NOT FOUND

8.  Security Considerations

   GMP is intended to raise the bar against impersonation, spoofing, and
   tampering by binding messages to both sender identity and content
   hashes through digital signatures.  It does not replace the need for
   endpoint security, anti-malware, and user education.

   Implementers MUST:

   *  Protect private keys used for GMR signing.

   *  Implement safe key rotation and revocation mechanisms.

   *  Address replay and downgrade attacks in the verification flow,
      including reuse of old GMRs with new messages or weaker policy
      profiles.

   GMP does not protect against compromise of the sender's device or
   account prior to GMR generation.  If an attacker controls the
   sender's environment, they MAY be able to send malicious but
   syntactically "valid" messages.  Additional controls (for example,
   strong authentication, device posture checks, and anomaly detection)
   are REQUIRED to mitigate those threats.

   GMP also does not replace the need for transport-level protections
   such as TLS or domain-based authentication mechanisms such as SPF,
   DKIM, and DMARC.  Rather, it is intended to complement these
   mechanisms by providing cryptographic non-repudiation at the level of
   individual messages and senders.






Madaras & Estis            Expires 5 June 2026                  [Page 6]

Internet-Draft                GuardMail GMP                December 2025


9.  IANA Considerations

   This document requests the registration of a new email header field
   in the "Provisional Message Header Field Names" registry:

   Header field name:  X-GuardMail-Stamp

   Applicable protocol:  mail

   Status:  provisional

   Author/Change controller:  IESG

10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Tom Madaras
   GuardSuite, a VXMSecure Company
   Hollywood, FL 33021
   United States of America
   Email: tom@vxmsecure.com


   Pat Estis
   GuardSuite, a VXMSecure Company
   Houston, TX
   United States of America
   Email: pat.estis@gmail.com













Madaras & Estis            Expires 5 June 2026                  [Page 7]
