The "HeaderWrittenBy" and "SendingSoftware" Mail Header Fields SIMS.NET Inc
12842 Highland Hills Drive Cypress TX 77429 US jim@sims.net
Applications 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.
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 .
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 .
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.
Header Field Specifications
"HeaderWrittenBy" Syntax The HeaderWrittenBy header field is added to a message's header section as defined in RFC 5322 . The syntax, in ABNF , 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]).
"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. 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.
"SendingSoftware" Syntax The SendingSoftware header field's syntax is as follows: SendingSoftware = "SendingSoftware:" FWS unstructured FWS unstructured is defined in and allows for free-form text (e.g., "Outlook 16.0.1", "Apple Mail (2.345.1)").
"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.
Operational Considerations
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.
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 , 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).
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 , DKIM, and DMARC : 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 signature. In a legitimate message (), this provides a cryptographically-backed attestation of the injection host.
IANA Considerations This document requests IANA to register the following header fields in the "Permanent Message Header Field Registry" :
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]
 Normative References Key words for use in RFCs to Indicate Requirement Levels Augmented BNF for Syntax Specifications: ABNF Internet Message Format Informative References Registration Procedures for Message Header Fields DomainKeys Identified Mail (DKIM) Signatures Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Domain-based Message Authentication, Reporting, and Conformance (DMARC)