| Internet-Draft | Local Headers | June 2026 |
| Chuang & Gustafsson | Expires 21 December 2026 | [Page] |
When human users communicate with autonomous computer agent users, the human users should be able to identify that communication as coming from agent users and know which humans are responsible for the agent users. This document specifies email header fields that an email sender can use to transmit agent user attribution information to email receivers. The first header field is human readable and specifies the agent's responsible humans' email address. The second header field is machine readable and specified in JSON attribution information.¶
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 21 December 2026.¶
Copyright (c) 2026 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.¶
Recent autonomous computer agent users have gained the capability to communicate with human users through such means such as emails ([RFC5322]). Human users should be able to identify that communication as coming from computer agents. They should also be able to identify which humans are responsible for the agent, that is the human owner of the agent. For example when the agent misbehaves and sends unwanted email, the recipient may want to communicate with the responsible human to stop the behavior. This document specifies email header fields ([RFC5322]) that an email sender can use to transmit agent user attribution information to email receivers. The first header field Agent-of specifies the agent's responsible human's email address, and is human and machine readable. The second header field Agent-attribution is specified in JSON attribution information, and is meant to be machine readable only.¶
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 [RFC2119].¶
This specification defines two header field-names ([RFC5322]) agent-of and agent-attribution.¶
When the agent-of header field is attached to an email, it defines that a computer agent sent the message. The field value is an address-list ([RFC5322]) of the responsible humans of the agent that sent an email. This is meant to be human and machine readable.¶
agent-of = "Agent-of:" address-list CRLF¶
With this header field, the responsible human information here is simplified for readability. If there are multiple responsible humans of an agent, multiple addresses may be specified or an email address alias may be used to represent many users that control that agent. In other scenarios, when an agent triggers the creation of another agent, the responsible human information SHOULD be propagated so that it is always available to the newly created agent.¶
Alternatively when the sender wishes to represent a more complex responsibility relationship, they can use the agent-attribution header field. The field value is a base64string ([RFC4648]) of JSON ([RFC8259]). The JSON key-value of attributes about the identity of the responsible humans that allows arbitrary definition of responsibility and delegation relationship of computer agents. We expect that there will be an IANA registry for these values as well as future updates to this document to represent those relationships. It is meant to be only machine readable. When the agent-attribution header field is attached to an email, it also defines that a computer agent sent the message.¶
agent-attribution = "Agent-attribution:" base64string CRLF¶
If both header fields are present in a message, the receiver SHOULD take a union of the sender identities of both header fields.¶
Senders SHOULD sign these header fields with DKIM ([RFC6376]). Receivers that use these headers MUST DKIM authenticate them, i.e the signature passes and the header fields are covered by the header hash. If DKIM2 (draft-ietf-dkim-dkim2-spec) authentication is available, then DKIM2 results SHOULD be used for authentication instead of DKIM. To prevent spoofing of the responsible humans, receivers that use those identities MUST check for DMARC relaxed ([RFC9989]) alignment with a passing DKIM or DKIM2 signature domain.¶
These headers MUST be DKIM authenticated before they can be used as defined in Section 1.2.1. Similarly the responsible humans' email addresses domains MUST be DKIM aligned as defined in Section 1.2.1. Presence of this header field does not infer any trustworthiness. It is simply a claim by the sender that the creator of the email is an agent and a second claim of who are the responsible humans of an agent. Receivers MUST make their own judgement of the utility of this information.¶
This document has no IANA actions yet.¶
--¶