[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) November 26, 2012
Intended status: Standards Track
Expires: May 30, 2013
Update to Internet Message Format to Allow Group Syntax in the "From:"
and "Sender:" Header Fields
draft-leiba-5322upd-from-group-08
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, as well as in "Resent-
From:" and "Resent-Sender:", in certain situations.
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 May 30, 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
Leiba Expires May 30, 2013 [Page 1]
Internet-Draft Group Syntax in "From:" and "Sender:" November 2012
the Trust Legal Provisions and are provided without warranty as
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:" . . . . . . 4
2.1. Replacement of RFC 5322, Section 3.6.2. Originator
Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Update to RFC 5322, Section 3.6.6. Resent Fields . . . . . 6
3. Applicability Statement . . . . . . . . . . . . . . . . . . 6
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . 9
Leiba Expires May 30, 2013 [Page 2]
Internet-Draft Group Syntax in "From:" and "Sender:" November 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:". While named groups were seen as useful in destination
fields their use in originator fields seemed unnecessary and was not
defined. Additionally, "group" syntax allows for empty groups (a
group name followed by no specified mailboxes) to support a "Bcc:"
function, and it was considered unnecessary to be able to have this
function for originator fields, because the message would then be
unreplyable. However, use cases for group syntax have evolved. The
concept of an originator as a group (a message "from the senior
partners", for example) is no longer considered unreasonable. And
there are instances, particularly with respect to new
internationalized email addresses, where a mail agent might need to
create an email message with no replyable addresses in the "From:" or
"Sender:" fields. Allowing group syntax in the "From:" and "Sender:"
fields makes that possible. Review of current email user agents
makes it clear that there is little interoperability risk in relaxing
the ban on that usage.
The requirement to represent these identities as replyable mailboxes
has thus become unnecessarily restrictive, and this document updates
RFC 5322 to relax that restriction, allowing group syntax in "From:",
"Sender:", "Resent-From:", and "Resent-Sender:" for limited use (see
Section 3).
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.,
Leiba Expires May 30, 2013 [Page 3]
Internet-Draft Group Syntax in "From:" and "Sender:" November 2012
"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 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
Section 3).
Section 2.1 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. Section 2.2 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.
[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 Section 2.1, as
well as that in Section 1.1.1 and Section 1.1.2 above, is left as it
was in RFC 5322.]
[[RFC Editor (please remove this paragraph before publication):
Please, therefore, hold back edits to Section 1.1.1, Section 1.1.2,
and Section 2.1. If you think there are editorial changes that you
must make, let's please discuss them explicitly during AUTH48.]]
2.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields
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
Leiba Expires May 30, 2013 [Page 4]
Internet-Draft Group Syntax in "From:" and "Sender:" November 2012
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 Section 3). 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.
from = "From:" (mailbox-list / address-list) CRLF
sender = "Sender:" (mailbox / address) CRLF
reply-to = "Reply-To:" address-list CRLF
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.
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 mailbox(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 mailbox 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.
Leiba Expires May 30, 2013 [Page 5]
Internet-Draft Group Syntax in "From:" and "Sender:" November 2012
2.2. Update to RFC 5322, Section 3.6.6. Resent Fields
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:
resent-from = "Resent-From:" (mailbox-list / address-list) CRLF
resent-sender = "Resent-Sender:" (mailbox / address) CRLF
3. Applicability Statement
Mailbox syntax is the normal use in the "From:" and "Sender:" header
fields; the address syntax defined in Section 2.1, which allows the
specification of a group, 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 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 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.
4. Example
Consider an email message that is meant to be "from" the three
managing partners of a business, Alice, Ben, and Carol, and that is
sent by their assistant, Dave. That could always have been presented
this way:
From: alice@example.com,ben@example.com,carol@example.com Sender:
dave@example.com
This change allows that to be represented this way:
From: Managing
Partners:alice@example.com,ben@example.com,carol@example.com;
Sender: dave@example.com
5. Security Considerations
See the Internet Message Format specification [RFC5322] for general
Leiba Expires May 30, 2013 [Page 6]
Internet-Draft Group Syntax in "From:" and "Sender:" November 2012
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 groups there does not
exacerbate the security problem.
Some protocols attempt to validate the 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. 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.
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.
6. 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:
Leiba Expires May 30, 2013 [Page 7]
Internet-Draft Group Syntax in "From:" and "Sender:" November 2012
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]] |
+----------------+--------+------------+--------------------------+
7. References
7.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.
Leiba Expires May 30, 2013 [Page 8]
Internet-Draft Group Syntax in "From:" and "Sender:" November 2012
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
7.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 May 30, 2013 [Page 9]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/