Internet DRAFT - draft-lilly-from-optional
draft-lilly-from-optional
Network Working Group B. Lilly
Internet-Draft March 2005
Updates: 822, 2822 (if approved)
Expires: September 15, 2005
Message Header From Field Made Optional
draft-lilly-from-optional-02
Status of this Memo
By submitting this Internet-Draft, the author represents that any
applicable patent or other IPR claims of which he is aware have been
or will be disclosed, and any of which he becomes aware will be
disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright(C)The Internet Society 2005.
Abstract
The requirement for the presence of a syntactically-valid message
header From field in the Internet Message Format presents a problem
in some circumstances. This memo (if approved) amends the Internet
Message Format specifications to make that field optional.
Discussion of the subject matter covered in this memo has taken place
on the ietf-822 mailing list, and that would be a suitable place for
discussion of this document.
1. Introduction
The Internet Message Format specification [N1.STD11], [N2.RFC2822]
requires a From field in the message header with a field body
consisting of a non-empty list of mailboxes for the message authors.
There are at least two situations where such a list is not practical:
a. The author has no mailbox ([N1.STD11] example A.2.6 uses the
sender's mailbox and associates it with a display name different
from that of the true sender, which may lead to confusion).
[N2.RFC2822] section 3.6.2 states that the [N1.STD11] A.2.6
Lilly Expires September 15, 2005 [Page 1]
Internet-Draft From Field Made Optional March 2005
practice of using a mailbox other than the author's is strongly
deprecated, but does not offer a viable alternative.
b. The author or authors require anonymity (e.g. whistle-blowing or
political dissidence)
The fundamental problem is that the Message Format specification
requires supplying information which in some circumstances is
unavailable, and in other circumstances may be harmful, even lethal.
Several approaches to resolving the problem have been considered:
a. As mentioned, the [N1.STD11] example A.2.6 method may lead to
confusion; worse, use of a mailbox for someone other than the
message author may result in harm to an individual or group
unrelated to the message.
b. One might use a syntactically valid but unresolvable domain name
in the mailbox; however, that interacts badly with gateways
[I1.RFC2821] to non-Internet mail and non-mail systems (where DNS
might not be available to the recipient), it is not always easy to
distinguish an unresolvable name from temporary failure or, worse,
deliberate return of inappropriate response codes from a name
server [I2.SiteFinder], and if used widely might result in
unreasonable load on the root nameservers.
c. A domain literal corresponding to no location might be used. That
would avoid DNS issues. Unfortunately, there is no IPv4 address
that guarantees that characteristic [I3.RFC3330]. There is an
IPv6 address range reserved for documentation [I4.RFC3849]. There
have in the past been other reserved ranges [I5.RFC3701].
Finally, there are a few other reserved IPv6 addresses as
specified in [I6.RFC3513]. In particular, the [I6.RFC3513]
"Unspecified" IPv6 address is potentially useful.
Unfortunately, there are several problems with IPv6 domain
literals:
i. IPv6 is not yet widely deployed
ii. In particular, there does not appear to be widely-deployed
recognition of [I1.RFC2821] (as referenced by [N2.RFC2822])
tagged IPv6 domain literals. One [I1.RFC2821] representation
of the [I6.RFC3513] "Unspecified" IPv6 address is "[IPv6:0::]".
Many implementations expect domain literals to conform to the
(untagged) IPv4 syntax of [I7.STD3]
iii. Domain literals are essentially opaque to end users. They
do not convey the desired semantics (lack of an Internet
mailbox or anonymity).
Lilly Expires September 15, 2005 [Page 2]
Internet-Draft From Field Made Optional March 2005
iv. There are literally dozens of distinct but equivalent
[I1.RFC2821] tagged IPv6 representations of the "Unspecified"
IPv6 domain literal. That makes it difficult to educate end
users about the semantics, since an end user might encounter
any of many distinct representations.
v. There is potential for interoperability problems: one type of
[I6.RFC3513] IPv6 address with embedded IPv4 address has the
IPv4 address (32 bits) in an otherwise zero-valued IPv6
address. The "Unspecified" IPv6 might mistakenly be
interpreted as an embedded IPv4 address of 0.0.0.0, which has
semantics of "this" host on "this" network [I3.RFC3330], i.e.
similar to the loopback semantics. Any local-part used with
that IPv6 "Unspecified" literal so interpreted might clash with
a valid local-part on the local system, which is hardly
equivalent to the desired semantics of no Internet mailbox or
anonymity.
Use of either a domain name or domain literal raises the issue of
a suitable local-part, and the issues with respect to
interpretation of such a local-part. Hosts are supposed to treat
local-parts as opaque strings unless the domain matches the host's
domain (which would never be the case for an unassigned domain
name or "unspecified" domain literal).
A field body syntax change would be a problem for SMTP gateways,
which are required to ensure that address fields contain content
which is "effective and useful for sending replies" as specified
in [I1.RFC2821].
d. The syntax of the From field might be changed to permit an empty
field body, i.e. zero or more mailboxes. While the Bcc field has
provision for an empty field body, the From field does not. Such
a change would be incompatible with modern and past
implementations, as an empty From field body has never been legal.
An empty field body presents problems for SMTP gateways, as noted
above. It may also present problems for other protocols using
RFC 822 syntax, as noted below.
e. The syntax of the From field body might be changed to an address
or address list rather than a mailbox list, allowing a named group
with an empty set of mailboxes, but that would not be compatible
with modern deployed implementations which cannot be expected to
cope with such an extension to syntax of the field; such syntax is
explicitly prohibited by [N1.STD11] section 4.4.1. It was,
however, legal syntax under an earlier Message Format RFC, viz.
[I8.RFC733], and is legal in message header recipient address
fields and the Reply-To field.
An alternate syntax change would be to permit an empty angle-addr
in the mailbox specification. That too is currently incompatible
with specified syntax and might not be handled well by some
deployed implementations. Like the above, such syntax was at one
Lilly Expires September 15, 2005 [Page 3]
Internet-Draft From Field Made Optional March 2005
time legal, and is presently permitted in some address fields
(e.g. Return-Path).
Syntax changes to RFC 822 would affect all protocols using the
RFC 822 From field syntax, notably [I9.HTTP].
As noted above, such a syntax change would raise issues with
respect to SMTP gateway requirements.
A null mailbox or empty mailbox list (in a named group address)
does avoid issues related to DNS (availability of service,
nameserver load, resolver issues), domain or domain literal
interpretation, and local-part issues.
f. It is believed that the approach chosen in this memo, viz. to make
the From field OPTIONAL, has the least adverse impact on the
Internet of the available solutions to the problem. It is perhaps
worth noting that the From field is optional in [I9.HTTP].
2. Requirement Levels
The key words "REQUIRED", "SHOULD", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in [N3.BCP14].
3. Scope
This memo (if approved) updates the Internet Message Format
specification [N1.STD11], [N2.RFC2822] as used by various
applications (electronic mail [I10.STD10], [I1.RFC2821], Usenet news
[I11.RFC1036], Internet fax [I12.RFC2305], VPIM [I13.RFC3801], EDI
[I14.RFC1767], [I15.RFC1865], etc.). It applies across the board to
applications using the Internet Message Format. However it does not
discuss similarly named fields in unrelated formats and protocols
such as [I9.HTTP] or [I16.SIP] (HTTP uses the RFC 822 field syntax;
SIP does not).
This memo (if approved) relaxes a requirement of the Internet Message
Format. It does not preclude specific applications from separately
requiring a From field, but authors of such specifications SHOULD
consider the situations discussed in this memo which have lead to the
relaxation of the Internet Message Format requirement.
4. Amendment of STD 11 (RFC 822)
4.1. RFC 822 section 4.1 SYNTAX
authentic = ["From" ":" mailbox] ; Single author
/ ( "Sender" ":" mailbox ; Actual submittor
["From" ":" 1#mailbox]) ; Multiple authors
; or not sender
resent-authentic = ["Resent-From" ":" mailbox]
/ ( "Resent-Sender" ":" mailbox
["Resent-From" ":" 1#mailbox] )
Lilly Expires September 15, 2005 [Page 4]
Internet-Draft From Field Made Optional March 2005
The change is that From and Resent-From fields are made optional.
4.2. RFC 822 section 4.4.2 SENDER / RESENT-SENDER
If the From field is omitted, a Sender field MAY be supplied, but it
is not REQUIRED.
4.3. RFC 822 section 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO
Clearly in the cases under consideration in this memo (author
anonymity or lack of mailbox), it is not possible to use a From field
if no such field is present. That is expected in the circumstances;
one cannot reply to an anonymous author, nor send Internet email to
an author with no Internet mailbox.
4.4. RFC 822 section A.2.6. Agent for user without online mailbox
A friend of George's, Sarah, is visiting. George's
secretary sends some mail to a friend of Sarah in computer-
land. Replies should go to George, whose mailbox is Jones at
Registry.
Comments: Sent on behalf of Sarah Friendly
Sender: Secy-Name <Secy@Registry>
Reply-To: Jones@Registry.
The From field is removed, and a Comments field is added to indicate
the initiator of the communications.
5. Amendment of RFC 2822
5.1. RFC 2822 section 3.6. Field definitions
from 0* 1 See sender and 3.6.2
The minimum number of From fields is decreased to zero.
5.2. RFC 2822 section 3.6.2. Originator fields
In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in the
"From:" field, if present, unless otherwise specified by the person
composing the reply.
A From field cannot be used if not present.
5.3. RFC 2822 section 3.6.6. Resent fields
The requirement for a Resent-From field is waived if the resender has
no Internet mailbox or if the resender requires anonymity.
Lilly Expires September 15, 2005 [Page 5]
Internet-Draft From Field Made Optional March 2005
6. Impact Analysis
The MIME media type message/rfc822 [I17.RFC2046], section 5.2.1,
requires one of From, Subject, or Date fields. In the event that
there is no From field due to anonymity or lack of an Internet
mailbox, one of Subject or Date fields would have to be present in
order to comply with the [I17.RFC2046] requirements.
Message transport protocols [I10.STD10], [I1.RFC2821], [I18.STD53],
[I19.RFC3501], [I20.RFC977], etc. do not make use of the From field,
and so are not affected by this change.
Similarly, MDNs (Message Disposition Notifications) [I21.RFC3798],
DSNs (Disposition Status Notifications) [I22.RFC3464], and MTSNs
(Message Tracking Status Notifications) [I23.RFC3886] do not use the
message header From field and are therefore unaffected.
Some documents have suggested use of the reserved ".invalid" TLD
(top-level domain name) [I24.BCP32] to provide some degree of
anonymity. With relaxation of the requirement for a From field in
the Internet Message Format, such hacks and their negative impact on
the root name service are unnecessary, at least within the scope of
Internet Messages.
Some message-processing applications might assume the guaranteed
presence of a From header field. Robust applications likely make no
such assumption and are prepared for absence of the field, which can
occur due to message modification (including truncation) in transit,
due to message generator design or configuration issues, etc.
Developers SHOULD NOT assume the presence of any particular field and
SHOULD carefully test applications for robustness.
7. Acknowledgments
The author gratefully acknowledges the helpful comments provided by
members of the ietf-822 mailing list. In particular, Keith Moore and
Ned Freed have made detailed and useful comments.
8. Security Considerations
No new security considerations are addressed by this memo. This memo
relaxes requirements on the Internet Message Format specification
which have resulted in security problems (specifically due to lack of
anonymity). As such, it improves security for message authors who
require anonymity.
While this memo does not affect transport protocols, being limited in
scope to the Internet Message Format, users of that format should be
aware that transport protocols may provide a trail leading to the
message sender (who might or might not be distinct from the author).
Some protocols, notably [I25.RFC2476] might use authentication
information to generate missing message header fields. Some SMTP
[I1.RFC2821] message transfer agent (MTA) implementations are known
to alter message content, including addition of message header
Lilly Expires September 15, 2005 [Page 6]
Internet-Draft From Field Made Optional March 2005
originator fields, even though that practice is not legal except for
the specific case of gateways. Accordingly, authors should not rely
on omission of a From header field to provide anonymity without
careful evaluation and testing of transport protocols.
[E]SMTP transport, [I1.RFC2821] [I25.RFC2476], carry in the SMTP
"envelope" a return path intended for notifications of delivery
problems. Placing an author's (as opposed to the sender's) mailbox
in the SMTP envelope would defeat anonymity.
Some user agents (UAs) might be configured to provide an indication
of the sender (as sometimes distinct from author) encoded in host
names (as supplied in EHLO or HELO SMTP commands and recorded in
trace fields) and/or message identifiers. In the case that the
author and sender are identical, such configurations make anonymity
impractical. Note that in general it is possible to trace the
sender, so anonymity is only practical where the sender is not the
message author (or one of the authors). Arrangements for such true
anonymity -- where even the sender is unaware of the identity of the
author(s) -- (e.g.. some sort of drop box) are beyond the scope of
this memo.
Developers and administrators of message submission agents (MSAs) and
MTAs SHOULD carefully consider implications of breaching anonymity
and/or mistakenly associating an Internet mailbox with an author (as
distinct from sender) who has no such mailbox, and SHOULD design and
operate software with due consideration for those circumstances.
Administrators SHOULD advise users and potential users of any
anonymity-breaching configurations of MSAs or administered UAs.
9. Internationalization Considerations
This memo raises no new internationalization considerations.
10. IANA Considerations
IANA shall update the From header field registration to include this
document's RFC number in the list of Specification Documents upon
approval by the IESG. At the same time, it would be helpful if IANA
were to provide useful and meaningful titles for the message header
field name registry lists, which currently are identified by the
nonsensical phrases "header messages" and "message header messages".
Appendix A. Change History
[[This change history will not be part of a published RFC]]
-01 to -02
o added this change history
o added discussion of syntax change alternatives, with references
Lilly Expires September 15, 2005 [Page 7]
Internet-Draft From Field Made Optional March 2005
o added discussion of domain literal alternative, with references
o added discussion of assumptions about header field presence
o expanded discussion of security considerations, with references
o updated acknowledgments
o revised boilerplate
-00 to -01
o converted prose discussion of alternative approaches to
numbered list
o fixed RFC 822 revised ABNF line formatting (line break)
Normative References
[N1.STD11] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[N2.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[N3.BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Informative References
[I1.RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[I2.SiteFinder] SSAC Report: Redirection in the Com and Net Domains,
A Report From the ICANN Security and Stability
Advisory Committee (SSAC), 9 July 2004
[I3.RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
September 2002.
[I4.RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address
Prefix Reserved for Documentation", RFC 3849, July
2004.
[I5.RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
Allocation) Phaseout", RFC 3701, March 2004.
[I6.RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version
6 (IPv6) Addressing Architecture", RFC 3513, April
2003.
[I7.STD3] Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October
1989.
Lilly Expires September 15, 2005 [Page 8]
Internet-Draft From Field Made Optional March 2005
[I8.RFC733] Crocker, D., Pogran, K., Vittal, J., and D.
Henderson, "Proposed official standard for the format
of ARPA Network messages", RFC 724, May 1977.
[I9.HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996.
[I10.STD10] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[I11.RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987.
[I12.RFC2305] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A
Simple Mode of Facsimile Using Internet Mail",
RFC 2305, March 1998.
[I13.RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for
Internet Mail - version 2 (VPIMv2)", RFC 3801, June
2004.
[I14.RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects",
RFC 1767, March 1995.
[I15.RFC1865] Houser, W., Griffin, J., and C. Hage, "EDI Meets the
Internet Frequently Asked Questions about Electronic
Data Interchange (EDI) on the Internet", RFC 1865,
January 1996.
[I16.SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[I17.RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996.
[I18.STD53] Myers, J. and M. Rose, "Post Office Protocol -
Version 3", STD 53, RFC 1939, May 1996.
[I19.RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[I20.RFC977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
[I21.RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[I22.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 3464,
January 2003.
Lilly Expires September 15, 2005 [Page 9]
Internet-Draft From Field Made Optional March 2005
[I23.RFC3886] Allman, E., "An Extensible Message Format for Message
Tracking Responses", RFC 3886, September 2004.
[I24.BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level
DNS Names", BCP 32, RFC 2606, June 1999.
[I25.RFC2476] Gellens, R. and J. Klensin, "Message Submission",
RFC 2476, December 1998.
Author's Address
Bruce Lilly
Email: blilly@erols.com
Full Copyright Statement
Copyright(C)The Internet Society 2005. This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the author retains all his rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Lilly Expires September 15, 2005 [Page 10]
Internet-Draft From Field Made Optional March 2005
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lilly Expires September 15, 2005 [Page 11]
