DMARC Use of the RFC5322.Sender Header Field
draft-ietf-dmarc-sender-00

Document Type Active Internet-Draft (dmarc WG)
Author Dave Crocker 
Last updated 2020-09-25
Replaces draft-crocker-dmarc-sender
Stream IETF
Intended RFC status Experimental
Formats plain text xml pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
DMARC                                                         D. Crocker
Internet-Draft                               Brandenburg InternetWorking
Updates: 7489 (if approved)                           September 25, 2020
Intended status: Experimental
Expires: March 29, 2021

              DMARC Use of the RFC5322.Sender Header Field
                       draft-ietf-dmarc-sender-00

Abstract

   Internet mail defines the RFC5322.From field to indicate the author
   of the message's content and the RFC5322.Sender field to indicate who
   initially handled the message.  The RFC5322.Sender field is optional,
   if it has the same information as the RFC5322.From field.  That is,
   when the RFC5322.Sender field is absent, the RFC5322.From field has
   conflated semantics, with both a handling identifier and a content
   creator identifier.  This was not a problem, until development of
   stringent protections on use of the RFC5322.From field.  It has
   prompted Mediators, such as mailing lists, to modify the RFC5322.From
   field, to circumvent mail rejection caused by those protections.

   This affects end-to-end behavior of email, between the author and the
   final recipients, because mail from the same author is not treated
   the same, depending on what path it followed.  In effect, the
   RFC5322.From field has become dominated by its role as a handling
   identifier.

   The current specification augments use of the RFC5322.From field, by
   enhancing DMARC to also use the RFC5322.Sender field.  This preserves
   the utility of RFC5322.From field while also preserving the utility
   of DMARC.

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

Crocker                  Expires March 29, 2021                 [Page 1]
Internet-Draft                    DMARC                   September 2020

   This Internet-Draft will expire on March 29, 2021.

Copyright Notice

   Copyright (c) 2020 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.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Domain Owner Actions  . . . . . . . . . . . . . . . . . . . .   5
   4.  Mail Originator Actions . . . . . . . . . . . . . . . . . . .   6
   5.  Mail Mediator Actions . . . . . . . . . . . . . . . . . . . .   6
   6.  Mail Receiver Actions . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Extract RFC5322.Sender and RFC5322.From Domains . . . . .   6
     6.2.  Determine Handling Policy . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Internet mail conducts asynchronous communication from an author to
   one or more recipients, and is used for ongoing dialogue 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 RFC5322.From field to indicate the author
   of the message's content and the RFC5322.Sender field to indicate who
   initially handled the message.  [Mail-Fmt] The RFC5322.Sender field
   is optional, if it has the same information as the RFC5322.From
   field.  That is, when the RFC5322.Sender field is absent, the
   RFC5322.From field has conflated semantics, as both a handling
Show full document text