



Network Working Group                                            J. Sims
Internet-Draft                                              SIMS.NET Inc
Intended status: Standards Track                        11 December 2025
Expires: 14 June 2026


     The "HeaderWrittenBy" and "SendingSoftware" Mail Header Fields
                     draft-simsnet-mail-headers-00

Abstract

   This document proposes two new, optional mail header fields.

   *  "HeaderWrittenBy" is designed to provide a simple attestation of
      the host that injected a message's primary author-level headers
      (such as "From") into the mail system.

   *  "SendingSoftware" is designed to declare the Mail User Agent (MUA)
      that composed the message.

   These are intended to provide additional, simple-to-parse signals for
   mail filtering and analysis, to be used in conjunction with existing
   authentication mechanisms like DKIM.

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

Copyright Notice

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






Sims                      Expires 14 June 2026                  [Page 1]

Internet-Draft             Mail Origin Headers             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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Header Field Specifications . . . . . . . . . . . . . . . . .   3
     3.1.  "HeaderWrittenBy" Syntax  . . . . . . . . . . . . . . . .   3
     3.2.  "HeaderWrittenBy" Semantics . . . . . . . . . . . . . . .   3
     3.3.  "SendingSoftware" Syntax  . . . . . . . . . . . . . . . .   4
     3.4.  "SendingSoftware" Semantics . . . . . . . . . . . . . . .   4
   4.  Operational Considerations  . . . . . . . . . . . . . . . . .   4
     4.1.  Example 1: Legitimate Mail ("Good Actor") . . . . . . . .   4
     4.2.  Example 2: Forged Mail ("Bad Actor")  . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In modern email, the author-level header fields, such as From and
   Reply-To, are trivial to forge.  This forgery is a cornerstone of
   phishing and spam.  While a message's transport path is documented in
   Received headers, parsing these headers is notoriously complex and
   error-prone.

   This proposal introduces two simpler, non-cryptographic headers.

   *  The SendingSoftware header is added by the Mail User Agent (MUA)
      to identify itself (e.g., "Outlook 16.0").

   *  The HeaderWrittenBy header is added by the Mail Submission Agent
      (MSA) that first receives the message.

   These headers provide clear signals that can be compared against
   other headers for discrepancies.  Their primary utility is realized
   when they are included in a message's cryptographic signature, such
   as DKIM [RFC6376].




Sims                      Expires 14 June 2026                  [Page 2]

Internet-Draft             Mail Origin Headers             December 2025


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   MUA (Mail User Agent):  A program (e.g., a desktop client or webmail
      interface) used to compose and read email.

   MSA (Mail Submission Agent):  A server that receives mail from an MUA
      and cooperates with Mail Transfer Agents (MTAs) to deliver the
      mail.  This is the first point of entry into the mail transport
      system.

   MTA (Mail Transfer Agent):  A server that relays mail between other
      servers.

3.  Header Field Specifications

3.1.  "HeaderWrittenBy" Syntax

   The HeaderWrittenBy header field is added to a message's header
   section as defined in RFC 5322 [RFC5322].

   The syntax, in ABNF [RFC5234], is as follows:

   HeaderWrittenBy = "HeaderWrittenBy:" FWS hostname FWS
   hostname = (ALPHA / DIGIT) *( *("-" (ALPHA / DIGIT)) )
   FWS (Folding White Space) is defined in [RFC5322].

   The hostname value SHOULD be the fully qualified domain name (FQDN)
   of the MSA that adds the header.  If an FQDN is not available, a
   literal IP address (IPv4 or IPv6) MAY be used, enclosed in brackets
   (e.g., [192.0.2.1] or [ipv6:2001:db8::1]).

3.2.  "HeaderWrittenBy" Semantics

   The HeaderWrittenBy field provides a simplified trace of the
   message's origin.

   An MUA MUST NOT add this header field.  An MSA that receives a
   message from an MUA (i.e., its first injection into the mail system)
   SHOULD add exactly one HeaderWrittenBy header field.  The value of
   the hostname component MUST be the verified identity of the MSA
   itself.






Sims                      Expires 14 June 2026                  [Page 3]

Internet-Draft             Mail Origin Headers             December 2025


   If an MTA receives a message from another host (not an MUA) that
   already contains a HeaderWrittenBy header, this indicates a potential
   header forgery attempt or a non-compliant relay.  The receiving MTA
   SHOULD prepend its own HeaderWrittenBy header.

   The presence of multiple HeaderWrittenBy headers is a strong signal
   for spam filtering.  A legitimate message, handled by compliant
   servers, should only have one such header.

3.3.  "SendingSoftware" Syntax

   The SendingSoftware header field's syntax is as follows:

   SendingSoftware = "SendingSoftware:" FWS unstructured FWS

   unstructured is defined in [RFC5322] and allows for free-form text
   (e.g., "Outlook 16.0.1", "Apple Mail (2.345.1)").

3.4.  "SendingSoftware" Semantics

   The SendingSoftware field indicates the name and version of the MUA
   used to compose the message.

   An MUA SHOULD add exactly one SendingSoftware header field to a
   message upon composition.  This header field is analogous to the non-
   standard User-Agent or X-Mailer headers.  This document proposes
   standardizing it.

4.  Operational Considerations

4.1.  Example 1: Legitimate Mail ("Good Actor")

   A compliant MUA (e.g., Outlook) adds the SendingSoftware header.  The
   user submits the message to their MSA (e.g., smtp.provider.com).  The
   MSA, receiving the message from an MUA and seeing no HeaderWrittenBy
   header, adds one.

   Final Headers (in part):

   SendingSoftware: Outlook (16.0.7716.1000)
   HeaderWrittenBy: smtp.provider.com
   Received: from [192.0.2.100] (helo=desktop-client) ...
   From: "Example User" user@example.com
   To: "Recipient" recipient@other.com
   Subject: Example Message

   A receiving filter sees one HeaderWrittenBy header and can compare
   example.com and smtp.provider.com for analysis.



Sims                      Expires 14 June 2026                  [Page 4]

Internet-Draft             Mail Origin Headers             December 2025


4.2.  Example 2: Forged Mail ("Bad Actor")

   A spammer on a compromised host (spammer-host.com) crafts a message
   with forged headers and sends it to an open relay (random-email-
   host.com).

   Spammer's Injected Headers:

   HeaderWrittenBy: mail.chase.com (FORGED)
   SendingSoftware: Microsoft Outlook (FORGED)
   From: "Chase Bank" security@chase.com

   The server random-email-host.com receives this.  It is not receiving
   from an MUA, and it sees an existing HeaderWrittenBy header.  Per
   Section 3.2, it prepends its own header.

   Final Headers at Recipient (in part):

   HeaderWrittenBy: random-email-host.com (Added by relay)
   Received: from spammer-host.com (HELO mail.chase.com) ...
   HeaderWrittenBy: mail.chase.com (FORGED by spammer)
   SendingSoftware: Microsoft Outlook (FORGED by spammer)
   From: "Chase Bank" security@chase.com

   Analysis: A receiving filter sees this and immediately knows it is
   spam for two reasons:

   1.  There are multiple HeaderWrittenBy headers.

   2.  The topmost HeaderWrittenBy header (random-email-host.com) does
       not match the From domain (chase.com).

5.  Security Considerations

   This proposal, by itself, does not solve header forgery, but provides
   a mechanism to contain and identify it.

   Forgery of Headers: SendingSoftware is trivially forged.
   HeaderWrittenBy is also trivially forged by the original sender.
   However, this proposal is designed to neutralize that forgery.  A
   compliant MTA that receives a message with a pre-existing (forged)
   HeaderWrittenBy header will prepend its own, creating a stack.  This
   stack is a strong indicator of an untrusted message and exposes the
   non-compliant relay (random-email-host.com).

   Relationship to SPF [RFC7208], DKIM, and DMARC [RFC7489]: These
   headers are not a replacement for modern cryptographic authentication
   methods.  They provide supplementary signals.  It is STRONGLY



Sims                      Expires 14 June 2026                  [Page 5]

Internet-Draft             Mail Origin Headers             December 2025


   RECOMMENDED that any MSA that adds a HeaderWrittenBy header also
   includes this header in the list of headers protected by its DKIM
   [RFC6376] signature.  In a legitimate message (Section 4.1), this
   provides a cryptographically-backed attestation of the injection
   host.

6.  IANA Considerations

   This document requests IANA to register the following header fields
   in the "Permanent Message Header Field Registry" [RFC3864]:

   Header field name:
      HeaderWrittenBy

   Applicable protocol:
      mail

   Status:
      optional

   Author/Change controller:
      IETF

   Specification document(s):
      [This document]

   Header field name:
      SendingSoftware

   Applicable protocol:
      mail

   Status:
      optional

   Author/Change controller:
      IETF

   Specification document(s):
      [This document]

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




Sims                      Expires 14 June 2026                  [Page 6]

Internet-Draft             Mail Origin Headers             December 2025


   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

8.  Informative References

   [RFC3864]  Klyne, G., "Registration Procedures for Message Header
              Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September
              2004, <https://www.rfc-editor.org/info/rfc3864>.

   [RFC6376]  Crocker, D., Ed., "DomainKeys Identified Mail (DKIM)
              Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376,
              September 2011, <https://www.rfc-editor.org/info/rfc6376>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/info/rfc7208>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/info/rfc7489>.

Author's Address

   Jim Sims
   SIMS.NET Inc
   12842 Highland Hills Drive
   Cypress, TX 77429
   United States of America
   Email: jim@sims.net














Sims                      Expires 14 June 2026                  [Page 7]
