Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields
draft-leiba-5322upd-from-group-04

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Author Barry Leiba 
Last updated 2012-09-09
Stream (None)
Formats plain text xml pdf htmlized bibtex
Reviews
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
EAI Working Group                                               B. Leiba
Internet-Draft                                       Huawei Technologies
Updates: 5322 (if approved)                            September 9, 2012
Intended status: Standards Track
Expires: March 13, 2013

 Update to Internet Message Format to Allow Group Syntax in the "From:"
                      and "Sender:" Header Fields
                   draft-leiba-5322upd-from-group-04

Abstract

   The Internet Message Format (RFC 5322) allows "group" syntax in some
   email header fields, such as "To:" and "CC:", but not in "From:" nor
   "Sender:".  This document updates RFC 5322 to relax that restriction,
   allowing group syntax in those latter fields.

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 http://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 March 13, 2013.

Copyright Notice

   Copyright (c) 2012 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
   (http://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

Leiba                    Expires March 13, 2013                 [Page 1]
Internet-Draft    Group Syntax in "From:" and "Sender:"   September 2012

   described in the Simplified BSD License.

Table of Contents

   1.      Introduction  . . . . . . . . . . . . . . . . . . . . . . . 3
   1.1.    Notational Conventions  . . . . . . . . . . . . . . . . . . 3
   1.1.1.  Requirements Notation . . . . . . . . . . . . . . . . . . . 3
   1.1.2.  Syntactic Notation  . . . . . . . . . . . . . . . . . . . . 3

   2.      Allowing Group Syntax in "From:" and "Sender:"  . . . . . . 3
   2.1.    Replacement of RFC 5322, Section 3.6.2. Originator
           Fields  . . . . . . . . . . . . . . . . . . . . . . . . . . 4

   3.      Applicability Statement . . . . . . . . . . . . . . . . . . 5

   4.      Security Considerations . . . . . . . . . . . . . . . . . . 5

   5.      IANA Considerations . . . . . . . . . . . . . . . . . . . . 6

   6.      References  . . . . . . . . . . . . . . . . . . . . . . . . 7
   6.1.    Normative References  . . . . . . . . . . . . . . . . . . . 7
   6.2.    Informative References  . . . . . . . . . . . . . . . . . . 7

           Author's Address  . . . . . . . . . . . . . . . . . . . . . 7

Leiba                    Expires March 13, 2013                 [Page 2]
Internet-Draft    Group Syntax in "From:" and "Sender:"   September 2012

1.  Introduction

   The Internet Message Format [RFC5322] allows "group" syntax in some
   email header fields, such as "To:" and "CC:", but not in "From:" nor
   "Sender:".  As use cases for group syntax evolve, particularly with
   respect to email address internationalization issues, it is becoming
   clear that there is little value in forbidding that usage, and
   significant value in allowing it.  This document updates RFC 5322 to
   relax that restriction, allowing group syntax in "From:" and
   "Sender:".

1.1.  Notational Conventions

   The notational conventions here are the same as those in RFC 5322,
   and the following two subsections are copied directly from that
   document.

1.1.1.  Requirements Notation

   This document occasionally uses terms that appear in capital letters.
   When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
   NOT", and "MAY" appear capitalized, they are being used to indicate
   particular requirements of this specification.  A discussion of the
   meanings of these terms appears in [RFC2119].

1.1.2.  Syntactic Notation

   This specification uses the Augmented Backus-Naur Form (ABNF)
   [RFC5234] notation for the formal definitions of the syntax of
   messages.  Characters will be specified either by a decimal value
   (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
   a case-insensitive literal value enclosed in quotation marks (e.g.,
   "A" for either uppercase or lowercase A).

2.  Allowing Group Syntax in "From:" and "Sender:"

   Section 3.6.2 of RFC 5322 defines the "From:" header field as
   containing a "mailbox-list" syntax element.  This changes that
   definition to use the "address-list" syntax element, as is used in
   other fields, such as "To:", "CC:", and "Reply-To:".  This also
   changes the definition of the "Sender:" header field from the
   "mailbox" syntax element to the "address" syntax element.

   The following normative section replaces Section 3.6.2 of RFC 5322.

Leiba                    Expires March 13, 2013                 [Page 3]
Internet-Draft    Group Syntax in "From:" and "Sender:"   September 2012

2.1.  Replacement of RFC 5322, Section 3.6.2. Originator Fields

   In version -00, this section is unchanged from RFC 5322, to make it
   easier to use DIFF to see the actual changes that this version
   contains.  Compare this version with version -00.

   The originator fields of a message consist of the from field, the
   sender field (when applicable), and optionally the reply-to field.
   The from field consists of the field name "From" and a comma-
   separated list of one or more addresses (either mailbox or group
   syntax).  If the from field contains more than one address (mailbox
   or group) in the address-list, then the sender field, containing the
   field name "Sender" and a single mailbox or group specification, MUST
   appear in the message.  In either case, an optional reply-to field
   MAY also be included, which contains the field name "Reply-To" and a
   comma-separated list of one or more addresses (either mailbox or
   group syntax).

   from = "From:" address-list CRLF

   sender = "Sender:" address CRLF

   reply-to = "Reply-To:" address-list CRLF

   The originator fields indicate the address(es) of the source of the
   message.  The "From:" field specifies the author(s) of the message,
   that is, the address(es) of the person(s) or system(s) responsible
   for the writing of the message.  The "Sender:" field specifies the
   address of the agent responsible for the actual transmission of the
   message.  For example, if a secretary were to send a message for
   another person, the address of the secretary would appear in the
   "Sender:" field and the address of the actual author would appear in
   the "From:" field.  If the originator of the message can be indicated
   by a single mailbox in the "From:" field and the author and
   transmitter are identical, the "Sender:" field SHOULD NOT be used.
   Otherwise, both fields SHOULD appear.

      Note: The transmitter information is always present.  The absence
      of the "Sender:" field is sometimes mistakenly taken to mean that
      the agent responsible for transmission of the message has not been
      specified.  This absence merely means that the transmitter is
      identical to the author and is therefore not redundantly placed
      into the "Sender:" field.

   The originator fields also provide the information required when
   replying to a message.  When the "Reply-To:" field is present, it
   indicates the address(es) to which the author of the message suggests
   that replies be sent.  In the absence of the "Reply-To:" field,

Leiba                    Expires March 13, 2013                 [Page 4]
Internet-Draft    Group Syntax in "From:" and "Sender:"   September 2012

   replies SHOULD by default be sent to the address(es) specified in the
   "From:" field unless otherwise specified by the person composing the
   reply.

   In all cases, the "From:" field SHOULD NOT contain any address that
   does not belong to the author(s) of the message.  See also [RFC5322]
   Section 3.6.3 for more information on forming the destination
   addresses for a reply.

3.  Applicability Statement

   Mailbox syntax SHOULD be considered the normal use in the "From:" and
   "Sender:" header fields; the group syntax defined in Section 2.1 is
   only for Limited Use (see [RFC2026], Section 3.3, item (d)) for the
   reasons described below.

   Very many Internet email procedures and software assume that the
   addresses in "From:" and "Sender:" fields can be replied to and are
   suitable for use in mail organizing and filtering.  The use of group
   syntax instead of mailbox syntax can disrupt those uses.
   Consequently, while this specification legitimizes the use of group
   syntax, it does so only to enable circumstances when its use is
   necessary, and it is important that its use be limited to those
   circumstances and that it be used with caution.  In particular, user
   agents SHOULD NOT permit the use of group syntax in those fields in
   outgoing messages, much as they also do not permit the use of a null
   address ("<>").

4.  Security Considerations

   See the Internet Message Format specification [RFC5322] for general
   discussion of security considerations related to the formatting of
   email messages.

   The "From:" address is special, in that most user agents display that
   address, or the "friendly" text associated with it, to the end user,
   and label that so as to identify it as the origin of the message (as
   implied in Section 3.6.2 of RFC 5322).  Group syntax in the "From:"
   header field can be used to hide the identity of the message
   originator.  It is as easy to use a fabricated "From:" address to
   accomplish the same thing, so allowing group syntax does not
   exacerbate the problem.

   Some protocols attempt to validate that originator address by
   matching the "From:" address to a particular verified domain (see
   Author Domain Signing Practices (ADSP) [RFC5617] for one such

Leiba                    Expires March 13, 2013                 [Page 5]
Internet-Draft    Group Syntax in "From:" and "Sender:"   September 2012

   protocol).  Such protocols will not be applicable to messages that
   lack an actual email address (whether real or fake) in the "From:"
   field, and local policy will determine how such messages are handled.
   Senders, therefore, need to be aware that using group syntax in the
   "From:" might adversely affect deliverability of the message.

   Because group syntax in the "From:" and "Sender:" header fields has
   previously not been allowed, it is possible that some implementations
   that conform to RFC 5322 might not be prepared to handle the syntax,
   and, indeed, might not even recognize that group syntax is being
   used.  Of those implementations, some subset might, when presented
   with group syntax in those header fields, behave in a way that is
   exploitable by an attacker.  It is deemed unlikely that this will be
   a serious problem in practice: address field parsing is generally an
   integral component of implementations, and address field parsers are
   required to understand group syntax.  In addition, if any
   implementations should be exploitable through this mechanism, it is
   already possible for attackers to do it by violating RFC 5322, and
   other RFC 5322 violations are commonly used by malefactors.

5.  IANA Considerations

   IANA is asked to update the Permanent Message Header Field Names
   registry (
   http://www.iana.org/assignments/message-headers/perm-headers.html )
   as follows:

      OLD
      +---------+--------+------------+--------------------------+
      |  From   |  mail  |  standard  |  [RFC5322]               |
      +---------+--------+------------+--------------------------+

      +---------+--------+------------+--------------------------+
      |  Sender |  mail  |  standard  |  [RFC5322]               |
      +---------+--------+------------+--------------------------+

      NEW
      +---------+--------+------------+--------------------------+
      |  From   |  mail  |  standard  |  [RFC5322] [[this RFC]]  |
      +---------+--------+------------+--------------------------+

      +---------+--------+------------+--------------------------+
      |  Sender |  mail  |  standard  |  [RFC5322] [[this RFC]]  |
      +---------+--------+------------+--------------------------+

6.  References

Leiba                    Expires March 13, 2013                 [Page 6]
Internet-Draft    Group Syntax in "From:" and "Sender:"   September 2012

6.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

6.2.  Informative References

   [RFC5617]  Allman, E., Fenton, J., Delany, M., and J. Levine,
              "DomainKeys Identified Mail (DKIM) Author Domain Signing
              Practices (ADSP)", RFC 5617, August 2009.

Author's Address

   Barry Leiba
   Huawei Technologies

   Phone: +1 646 827 0648
   Email: barryleiba@computer.org
   URI:   http://internetmessagingtechnology.org/

Leiba                    Expires March 13, 2013                 [Page 7]