| Internet-Draft | Mail Origin Headers | December 2025 |
| Sims | Expires 14 June 2026 | [Page] |
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.¶
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 (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.¶
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].¶
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].¶
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]).¶
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.¶
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.¶
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)").¶
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.¶
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.¶
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:¶
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 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.¶
This document requests IANA to register the following header fields in the "Permanent Message Header Field Registry" [RFC3864]:¶
HeaderWrittenBy¶
SendingSoftware¶