Network Working Group                                            J. SimsInternet-Draft                                              SIMS.NET IncIntended status: Standards Track                        11 December 2025Expires: 14 June 2026     The "HeaderWrittenBy" and "SendingSoftware" Mail Header Fields                     draft-simsnet-mail-headers-00Abstract   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  . . . . . . . . . . . . . . . . . . . . . . . .   71.  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 20252.  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 Specifications3.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 Considerations4.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 20254.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 STRONGLYSims                      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.netSims                      Expires 14 June 2026                  [Page 7]