[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09 RFC 6854
EAI Working Group B. Leiba
Internet-Draft Huawei Technologies
Updates: 5322 (if approved) July 14, 2012
Intended status: Standards Track
Expires: January 15, 2013
Update to Internet Message Format to Allow Group Syntax in the 'From:'
Header Field
draft-leiba-5322upd-from-group-03
Abstract
The Internet Message Format (RFC 5322) allows "group" syntax in some
email header fields, such as "To:" and "CC:", but not in "From:".
This document updates RFC 5322 to relax that restriction, allowing
group syntax in "From:".
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 January 15, 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 January 15, 2013 [Page 1]
Internet-Draft Group Syntax in Email 'From:' July 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' . . . . . . . . . . . . . . 3
2.1. Replacement of RFC 5322, Section 3.6.2. Originator
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . 6
Leiba Expires January 15, 2013 [Page 2]
Internet-Draft Group Syntax in Email 'From:' July 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:". 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:".
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'
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:".
The following normative section replaces Section 3.6.2 of RFC 5322.
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.
Leiba Expires January 15, 2013 [Page 3]
Internet-Draft Group Syntax in Email 'From:' July 2012
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 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:" mailbox 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
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 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,
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]
Leiba Expires January 15, 2013 [Page 4]
Internet-Draft Group Syntax in Email 'From:' July 2012
Section 3.6.3 for more information on forming the destination
addresses for a reply.
3. 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
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" header field 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 "From" group
syntax, 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.
4. IANA Considerations
IANA is asked to update the Permanent Message Header Field Names
registry (
http://www.iana.org/assignments/message-headers/perm-headers.html )
Leiba Expires January 15, 2013 [Page 5]
Internet-Draft Group Syntax in Email 'From:' July 2012
as follows:
OLD
+--------+--------+------------+--------------------------+
| From | mail | standard | [RFC5322] |
+--------+--------+------------+--------------------------+
NEW
+--------+--------+------------+--------------------------+
| From | mail | standard | [RFC5322] [[this RFC]] |
+--------+--------+------------+--------------------------+
5. References
5.1. Normative References
[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.
5.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 January 15, 2013 [Page 6]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/