One document matched: draft-leiba-5322upd-from-group-09.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC822     PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0822.xml'>
<!ENTITY RFC2026    PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>
<!ENTITY RFC2119    PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC5234    PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml'>
<!ENTITY RFC5322    PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml'>
<!ENTITY RFC5617    PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5617.xml'>
<!ENTITY RFC6530    PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6530.xml'>

]>

<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="no" ?>
<?rfc tocindent="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc
  category="std"
  ipr="trust200902"
  updates="5322"
  docName="draft-leiba-5322upd-from-group-09">

  <front>
    <title abbrev='Group Syntax in "From:" and "Sender:"'>
    Update to Internet Message Format to Allow Group Syntax in the "From:"
    and "Sender:" Header Fields
    </title>

    <author initials='B.' surname='Leiba' fullname='Barry Leiba'>
      <organization>Huawei Technologies</organization>
      <address>
        <phone>+1 646 827 0648</phone>
        <email>barryleiba@computer.org</email>
        <uri>http://internetmessagingtechnology.org/</uri>
      </address>
    </author>

    <date/>
    <area>Applications</area>
    <workgroup>EAI Working Group</workgroup>

    <abstract>
      <t>
        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,
        as well as in "Resent-From:" and "Resent-Sender:",
        in certain situations.
      </t>
    </abstract>

  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>
   The Internet Message Format, as far back as RFC 822
   <xref target="RFC0822"/>, has always
   required a usable address to appear in the "From:" header field of
   messages in order to allow replies to be sent.  To this end, the
   syntax of messages, up to and including the current specification
   <xref target="RFC5322"/>,
   has required the use of the mailbox address form in
   the originator ("From:" and "Sender:") fields of messages and has
   specifically forbidden the use of the group address form, which
   permits an empty list of addresses
   (that is, an address list with no address included that might
   be used for a reply).
      </t>
      <t>
   However, the use cases for the "From:" field have evolved.
   There are numerous instances of automated systems that wish
   to send email but cannot handle replies, and a "From:" field
   with no usable addresses would be extremely useful for that purpose.
   More recently, work with internationalized email addresses
   <xref target="RFC6530"/> creates the real need to take a message
   with an internationalized email address and hand it to an older
   client that would have no ability to reply to such an address but
   might still wish to display the contents of the message.  The group
   construct provides an existing syntax for unusable addresses (using
   the empty list of addresses) and also allows for a text label that
   describes the originator.
   For example:
   <list style="empty"><t>
      From: Automated System:;
   </t></list>
   A review of many current email programs finds that all reviewed clients
   will properly display a message with group syntax in the "From:" field.
   At worst, such programs generate an error message when an attempt
   is made to reply to such a message.
   No other interoperability problems have been discovered.
      </t>
      <t>
   This document therefore updates the Internet Message Format specification
   <xref target="RFC5322"/> to relax that restriction,
   allowing group syntax to be used in the originator ("From:" and
   "Sender:") fields, as well as in their corresponding resent
   ("Resent-From:" and "Resent-Sender:") fields.
   This change permits empty groups, as described above, and
   also permits named groups of mailboxes (groups with
   non-empty lists of addresses; see <xref target="example"/>).
   Nevertheless, this document recommends against the
   general use of group syntax in these fields at this time
   (see <xref target="applicability"/>).
      </t>

      <section title="Notational Conventions">
        <t>
          The notational conventions here are the same as those in RFC 5322, and the following
          two subsections are copied directly from that document.
        </t>

        <section anchor="req" title="Requirements Notation">
          <t>
            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 <xref target="RFC2119"/>.
          </t>
        </section>

        <section anchor="syn" title="Syntactic Notation">
          <t>
            This specification uses the Augmented Backus-Naur Form (ABNF)
            <xref target="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).
       </t>
        </section>
      </section>
    </section>

    <section title='Allowing Group Syntax in "From:" and "Sender:"'>
      <t>
        Section 3.6.2 of RFC 5322 defines the "From:" header field as containing a
        <mailbox-list> syntax element.
        This specification changes that definition to use the <address-list> syntax element,
        as is used in other fields, such as "To:", "CC:", and "Reply-To:".
        This specification also changes the definition of the "Sender:" header field
        from the <mailbox> syntax element to the <address> syntax element.
        While the <address> element includes the <mailbox> element already,
        we have chosen to specify both in the updated syntax as a way of highlighting
        the limited use intended for the change (see <xref target="applicability"/>).
      </t>
      <t>
        <xref target="update"/> below is a full replacement for Section 3.6.2 of RFC
        5322, containing the new syntax as well as a new description of
        the semantics for the "From:" and "Sender:" fields.
        <xref target="resent"/> below is a replacement of only the ABNF syntax for the
        "Resent-From:" and "Resent-Sender:" fields in section 3.6.6 of RFC
        5322; the rest of the syntax as well as the descriptive text of
        section 3.6.6 of RFC 5322 remains unchanged.
      </t>
      <t>
        [The text in the following section is not consistent within itself nor
        with the rest of this document in how it refers to message header fields,
        sometimes putting the field name in quotation marks and sometimes not,
        sometimes capitalizing the field name and sometimes not,
        and sometimes including the final colon and sometimes not.
        Because minimizing changes to the original text is more important, in this case,
        than attaining consistency, the text in <xref target="update"/>,
        as well as that in <xref target="req"/> and <xref target="syn"/> above,
        is left as it was in RFC 5322.]
      </t>
      <t>
          [[RFC Editor (please remove this paragraph before publication):
          Please, therefore, hold back edits to
          <xref target="req"/>, <xref target="syn"/>, and <xref target="update"/>.
          If you think there are editorial changes that you must make, let's please discuss them
          explicitly during AUTH48.]]
      </t>

      <section anchor="update" title="Replacement of RFC 5322, Section 3.6.2. Originator Fields">
        <t>
          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 mailbox specification
          (including all mailboxes included in any groups),
          then the sender field, containing the field name "Sender" and a
          single address, MUST appear in the message.

          The from field and the sender field SHOULD NOT use group syntax; rather, the
          from field SHOULD use only the mailbox-list syntax and the sender
          field SHOULD use only mailbox syntax (see <xref target="applicability"/>).

          If the sender field uses group syntax, the group MUST NOT contain more than one mailbox.
          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.
        </t>
        <t>
          from            =   "From:" (mailbox-list / address-list) CRLF
          <vspace blankLines="1"/>
          sender          =   "Sender:" (mailbox / address) CRLF
          <vspace blankLines="1"/>
          reply-to        =   "Reply-To:" address-list CRLF
        </t>
        <t>
          The originator fields indicate the mailbox(es) of the source of the
          message.  The "From:" field specifies the author(s) of the message,
          that is, the mailbox(es) of the person(s) or system(s) responsible
          for the writing of the message.  The "Sender:" field specifies the
          mailbox 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 mailbox of the secretary would appear in the
          "Sender:" field and the mailbox of the actual author would appear in
          the "From:" field.  If the originator of the message can be indicated
          by a single mailbox and the author and transmitter
          are identical, the "Sender:" field SHOULD NOT be used.
          Otherwise, both fields SHOULD appear.
        </t>
        <t>
          <list>
            <t>
              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.
            </t>
          </list>
        </t>
        <t>
          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,
          replies SHOULD by default be sent to the mailbox(es) specified in the
          "From:" field unless otherwise specified by the person composing the
          reply.
        </t>
        <t>
          In all cases, the "From:" field SHOULD NOT contain any mailbox that
          does not belong to the author(s) of the message.  See also
          <xref target="RFC5322"/> Section 3.6.3
          for more information on forming the destination addresses for a
          reply.
        </t>
      </section>

      <section anchor="resent" title="Update to RFC 5322, Section 3.6.6. Resent Fields">
        <t>
          This updates RFC 5322, Section 3.6.6, to allow groups (via the address-list
          ABNF production) in the "Resent-From:" and "Resent-Sender:" fields,
          to parallel the change to "From:" and "Sender:" above.
          The ABNF for those fields is changed as follows:
        </t>
        <t>
          resent-from     =   "Resent-From:" (mailbox-list / address-list) CRLF
          <vspace blankLines="1"/>
          resent-sender   =   "Resent-Sender:" (mailbox / address) CRLF
        </t>
      </section>
    </section>

    <section anchor="applicability" title="Applicability Statement">
      <t>
        Mailbox syntax is the normal use in the "From:" and "Sender:"
        header fields; the address syntax defined in <xref target="update"/>,
        which allows the specification of a group, is only for
        Limited Use (see <xref target="RFC2026"/>, Section 3.3, item (d)) for the reasons
        described below.
      </t>
      <t>
        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 groups instead of mailboxes can disrupt those uses.
        Consequently, while this specification legitimizes the use of groups,
        it does so only to enable circumstances when that use is necessary,
        and because the use of this mechanism is new
        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 groups
        in those fields in outgoing messages.
      </t>
    </section>

    <section anchor="example" title="Examples">
      <t>
        First, consider an email message that is sent by an automated nightly
        monitor program, to which replies should not be sent.
        Such messages commonly include a valid, replyable address that will
        discard any replies that are sent to it, but recipients who do reply
        might be unaware that their replies will be discarded.
        If the message is instead presented this way, the recipients' email
        clients will not allow them to reply in the first place:
        <list style="empty">
        <t>
        From: Nightly Monitor Robot:;
        </t>
        </list>
      </t>
      <t>
        Second, consider an email message that is meant to be "from" the two managing partners
        of a business, Ben, and Carol, and that is sent by their assistant, Dave.
        That could always have been presented this way:
        <list style="empty">
        <t>
        From: ben@example.com,carol@example.com
        <vspace/>Sender: dave@example.com
        </t>
        </list>
      </t>
      <t>
        This change allows that to be represented this way:
        <list style="empty">
        <t>
        From: Managing Partners:ben@example.com,carol@example.com;
        <vspace/>Sender: dave@example.com
        </t>
        </list>
      </t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>
        See the Internet Message Format specification <xref target="RFC5322"/> for general
        discussion of security considerations related to the formatting of email messages.
      </t>
      <t>
        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 groups there does not exacerbate
        the security problem.
      </t>
      <t>
        Some protocols attempt to validate the originator address by matching the "From:"
        address to a particular verified domain (see Author Domain Signing Practices (ADSP)
        <xref target="RFC5617"/> for one such protocol).
        Such protocols will not be applicable to messages that lack
        an actual email address (whether real or fake) in the "From:" field.
        Local policy will determine how such messages are handled, and
        senders, therefore, need to be aware that using groups in the "From:" might
        adversely affect deliverability of the message.
      </t>
      <t>
        Because groups have previously not been allowed in
        the "From:" and "Sender:" header fields, it is
        possible that some implementations that conform to RFC 5322 might not be prepared to
        handle that 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.
      </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>
        IANA is asked to update the Permanent Message Header Field Names registry
        ( http://www.iana.org/assignments/message-headers/perm-headers.html ) as follows:
        <figure>          
          <artwork>
OLD
+----------------+--------+------------+--------------------------+
|  From          |  mail  |  standard  |  [RFC5322]               |
+----------------+--------+------------+--------------------------+

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

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

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

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

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

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

+----------------+--------+------------+--------------------------+
|  Resent-Sender |  mail  |  standard  |  [RFC5322] [[this RFC]]  |
+----------------+--------+------------+--------------------------+
          </artwork>
        </figure>          
      </t>
    </section>  
  </middle>

  <back>
    <references title="Normative References">
      &RFC2026;
      &RFC2119;
      &RFC5234;
      &RFC5322;
    </references>
    <references title="Informative References">
      &RFC822;
      &RFC5617;
      &RFC6530;
    </references>
  </back>
</rfc>