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, . 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, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . 8. Informative References [RFC3864] Klyne, G., "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, . [RFC6376] Crocker, D., Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . 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]