Network Working Group

Independent Submission                                        D. Crocker
Internet-Draft
Request for Comments: 9057                   Brandenburg InternetWorking
Intended status:
Category: Experimental                             March 20, 2021
Expires: September 21,                                         June 2021
ISSN: 2070-1721

                       Email Author Header Field
                     draft-crocker-email-author-04

Abstract

   Internet mail defines the From: header field to indicate the author
   of the message's content and the Sender: field to indicate who
   initially handled the message, message on the author's behalf.  The Sender:
   field is optional, optional if it has the same information as the From: field.
   This was not a problem, problem until development of stringent protections on
   use of the From: field.  It has prompted Mediators, such as mailing
   lists, to modify the From: field, field to circumvent mail rejection caused
   by those protections.  In effect, the From: field has become
   dominated by its role as a handling identifier.

   The current specification augments the altered use of the From:
   field, field
   by specifying the Author: field, which ensures identification of the
   original author of the message and is not subject to modification by
   Mediators.  This version document is published as an
   Experiment, Experimental RFC to
   assess community interest, functional efficacy, and technical
   adequacy.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and BCP 79.

   Internet-Drafts are working documents of
   evaluation.

   This document defines an Experimental Protocol for the Internet Engineering
   Task Force (IETF).  Note that
   community.  This is a contribution to the RFC Series, independently
   of any other groups may also distribute
   working documents as Internet-Drafts. RFC stream.  The list of current Internet-
   Drafts is RFC Editor has chosen to publish this
   document at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are draft documents valid not candidates for a maximum any level of six months Internet Standard;
   see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 September 21, 2021.
   https://www.rfc-editor.org/info/rfc9057.

Copyright Notice

   Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Author Header Field . . . . . . . . . . . . . . . . . . . . .   4
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Experimental Goals  . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.
   Acknowledgements . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Internet mail conducts asynchronous communication from an author to
   one or more recipients, recipients and is used for ongoing dialogue dialog amongst them.
   Email has a long history of serving a wide range of human uses and
   styles, within that simple framework, and the mechanisms for making
   email robust and safe serve that sole purpose.

   Internet mail defines the content header's From: field to indicate
   the author of the message and the Sender: field to indicate who
   initially handled the message, message on the author's behalf.  [Mail-Fmt] behalf [Mail-Fmt].  The
   Sender: field is optional, optional if it has the same information as the From:
   field.  That is, when the Sender: field is absent, the From: field
   has conflated semantics, semantics as both a handling identifier and a content
   creator identifier.  These fields were initially defined in
   [RFC733] [RFC733],
   and making the redundant Sender: field optional was a small, obvious optimization,
   optimization in the days of slower communications, expensive
   storage storage,
   and less powerful computers.

   The dual semantics was were not a problem, problem until development of stringent
   protections on use of the From: field.  It has prompted Mediators,
   such as mailing lists, to modify the From: field, field to circumvent
   receiver mail rejection, rejection caused by those protections.  This affects
   end-to-end usability of email, email between the author and the final
   recipients, because mail received from the same author is treated
   differently by the recipient's software, depending on what path the
   message followed.

   By way of example, mail originating with:

   From:  Example User <user@example.com>

   which is sent directly to a recipient, will show the author's display
   name correctly and can correctly analyze, filter filter, and aggregate mail
   from the author, author based on their email address.  However  However, if the author
   sends through a mailing list, list and the mailing list conducts a common
   form of From: modification, modification needed to bypass enforcement of stringent
   authentication policies, then the received message might instead have
   a From: field showing:

   From: Example User via Example List <listname@list.example.org>

   The change inserts an operational address, for the Mediator, into the
   From: field, field and distorts the field's display-name, display name as a means of
   recording the modification.

   In terms of email identification semantics, this is a profound
   change:

   o

   *  The result is that the recipient's software will see the message
      as being from an entirely different author and will handle it
      separately, such as for sorting or filtering.  In effect, the
      recipient's software will see the same person's email as being
      from a different address, for address; this includes the person's actual
      address and each of the mailing lists that person's mail transits.

   o

   *  Mediators might create a Reply-To: field, field with the original From:
      field email address.  This facilitates getting replies back to the
      original author, but it does nothing to aid other processing or
      presentation,
      presentation done by the recipient's Mail User Agent (MUA), (MUA) based
      on what it believes is the author's address or original display- display
      name.  This Reply-To action represents another knock-on, knock-on effect
      (e.g., collateral damage, damage) by distorting the meaning of that header
      field, as well as creating an issue if the field already exists.

   In effect, the From: field has become dominated by its role as a
   handling identifier.  The current specification augments this altered
   use of the From: field, field by specifying the Author: field, which
   identifies the original author of the message and is not subject to
   modification by Mediators.

   While it might be cleanest to move towards more reliable use of the
   Sender: field and then to target it as the focus of authentication
   concerns, enhancement of existing standards works best with
   incremental additions, rather than with efforts at replacement.  To
   that end, this specification provides a means of supplying author
   information that is not subject to modification by processes seeking
   to enforce stringent authentication.

   This version is published as an Experiment, Experimental RFC to assess community
   interest, functional efficacy, and technical adequacy.  See
   Section 7.

2.  Terminology

   Terminology and architectural details in this document are
   incorporated from [Mail-Arch].

   Normative language, per [RFC8174]:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   RFC EDITOR: Please remove for publication:

      Discussion of this draft is directed to the ietf-822@ietf.org
      mailing list.

3.  Author Header Field

   A

   Author: is a new message header field is defined: Author:. being defined.  It has the same
   syntax as the From: header field [Mail-Fmt].  As with the original
   and primary intent for the From: field, the Author: field is intended
   to contain the email address of the author of the message content.
   It also can contain the displayable human name of the author.

   The [ABNF] for the field's syntax is:

   author = "Author:" mailbox-list CRLF

   which echos the syntax for the From: header field.

   This header field can be added as part of the original message
   creation process, or it can be added later, by a Mediator, to
   preserve the original author information from the From: field.

   The goal of the Author: field is to reflect information about the
   original author.  However  However, it is possible that the author's MUA or
   Mail Submission Agent (MSA) will not create it, it but that a Mediator
   might know it will be modifying the From: field and wish to preserve
   the author information.  Hence  Hence, it needs to be allowed to create the
   Author: field for this, this if the field does not already exist.

   Processing of the Author: field follows these rules:

   o

   *  If an Author: field already exists, a new one MUST NOT be created created,
      and the existing one MUST NOT be modified

   o modified.

   *  An author's MUA or MSA MAY create an Author: field, and its value
      MUST be identical to the value in the From: field

   o field.

   *  A Mediator MAY create an Author: field, field if one does not already
      exist, and this new field's value MUST be identical to the value
      of the From: field, field at the time the Mediator received the message
      (and before the Mediator causes any changes to the From: field) field).

4.  Discussion

   The Author: header field, here, is intended for creation during
   message generation or during mediation.  It is intended for use by
   recipient MUAs, as they typically use the From: field.  In that
   regard, it would be reasonable for an MUA that would normally
   organize, filter, or display information based on the From: field to
   give the Author: header field preference.

   Original-From: is a similar header field, field referenced in [RFC5703].  It
   is registered with IANA, which cites RFC5703 [RFC5703] as the controlling
   source for the entry.  However  However, that document only has a minimal
   definition for the field.  Also, the field is solely intended for use
   by Mediators, Mediators to preserve information from a modified From:. From: field.
   The current specification can be used either during either origination or during
   mediation.

   While the basic model of email header fields is highly extensible,
   there well might be implementation and usability considerations for
   carrying this field through to end-users, end users, such as via [IMAP].

   Obviously

   Obviously, any security-related processing of a message needs to
   distinguish the From: field from the Author: field and treat their
   information accordingly.

5.  Security Considerations

   Any header field containing identification information is a source of
   security and privacy concerns, especially when the information
   pertains to content authorship.  Generally, the handling of the
   Author: header field needs to receive scrutiny and care, comparable
   to that given to the From: header field, but preferably not in a way
   that defeats its utility.

   Given the semantics of this the Author: header field, it is easy to
   believe that use of this field will create a new attack vector for
   tricking end-users. end users.  However (and perhaps surprisingly) surprisingly), for all of
   the real and serious
   demonstration demonstrations of users' users being tricked by
   deceptive or false content in a message, there is no evidence that
   problematic content in a header field, which is providing information
   about message's author, directly contributes to differential and
   problematic behavior by the end user.  (The presents an obvious
   exercise for the reader, reader to find credible, documented evidence.)

6.  IANA Considerations

   The

   IANA is request to register has registered the Author Author: header field, per [RFC3864], into in the Provisional
   "Provisional Message Header Field Names Registry: Names" registry:

   Header field name:  Author
   Applicable protocol:  mail
   Status:  Provisional
   Author/Change controller:  Dave Crocker <dcrocker@bbiw.net>
   Specification document(s): *** This document ***  RFC 9057

7.  Experimental Goals

   Given that the semantics of this field echo the long-standing From:
   header field, the basic mechanics of the field's creation and use are
   well understood.  Points of concern, therefore, are with possible
   interactions with the existing From: field, with anti-abuse systems, and with
   MUA behavior, along with basic market acceptance.  So the questions
   to answer, answer while the header field has experimental status are:

   o

   *  Is there demonstrated interest by MUA developers?

   o

   *  If MUA developers add this capability, is it used by authors?
   o

   *  Does the presence of the Author Author: field, in combination with the
      From
      From: field, create any operational problems, especially for
      recipients?

   o

   *  Does the presence of the Author Author: field demonstrate additional
      security issues?

   o

   *  Does the presence of the Author Author: field engender problematic
      behavior by anti-abuse software, such as defeating its utility?

8.  References

8.1.  Normative References

   [ABNF]     Dave,     Crocker, D., Ed. and P. Paul, Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008. 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [Mail-Arch]
              Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July
              2009. 2009,
              <https://www.rfc-editor.org/info/rfc5598>.

   [Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008. 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [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>.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              DOI 10.17487/RFC3864, September 2004,
              <https://www.rfc-editor.org/info/rfc3864>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [IMAP]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
              <https://www.rfc-editor.org/info/rfc3501>.

   [RFC5703]  Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
              Tests, Iteration, Extraction, Replacement, and Enclosure",
              RFC 5703, DOI 10.17487/RFC5703, October 2009. 2009,
              <https://www.rfc-editor.org/info/rfc5703>.

   [RFC733]   Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
              "Standard for the Format format of ARPA Network Text Messages", network text messages",
              RFC 733, DOI 10.17487/RFC0733, November 1977.

Appendix A. 1977,
              <https://www.rfc-editor.org/info/rfc733>.

Acknowledgements

   The idea for this field was prompted by discussions in the IETF's
   DMARC working group, Working Group, with participation including: from: Benny Lyne Amorsen,
   Kurt Anderson, Laura Atkins, Adrian Farrel, Murray S. Kucherawy, Mike
   Hammer, John Levine, Alexey Melnikov, Jesse Thompson, and Alessandro
   Vesely.

Author's Address

   Dave Crocker
   Brandenburg InternetWorking

   Email: dcrocker@bbiw.net