Network Working Group B. Lilly Internet Draft January 2005 Updates: 822, 2822 (if approved) Expires: July 29, 2005 Message Header From Field Made Optional draft-lilly-from-optional-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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). Lilly Expires July 29, 2005 [Page 1] Internet Draft From Field Made Optional January 2005 [N2.RFC2822] section 3.6.2 states that the [N1.STD11] A.2.6 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. 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. 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. The syntax of the From field body might be changed to an address list rather than a mailbox list, allowing a named group with an empty set of mailboxes, but that would not be compatible with 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 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. 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 [I3.STD10], [I1.RFC2821], Usenet news [I4.RFC1036], Internet fax [I5.RFC2305], VPIM [I6.RFC3801], EDI [I7.RFC1767], [I8.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 [I10.SIP]. 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. Lilly Expires July 29, 2005 [Page 2] Internet Draft From Field Made Optional January 2005 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] ) 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 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. Lilly Expires July 29, 2005 [Page 3] Internet Draft From Field Made Optional January 2005 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. 6. Impact Analysis The MIME media type message/rfc822 [I11.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 [I11.RFC2046] requirements. Message transport protocols [I3.STD10], [I1.RFC2821], [I12.STD53], [I13.RFC3501], [I14.RFC977], etc. do not make use of the From field, and so are not affected by this change. Similarly, MDNs (Message Disposition Notifications) [I15.RFC3798], DSNs (Disposition Status Notifications) [I16.RFC3464], and MTSNs (Message Tracking Status Notifications) [I17.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) [I18.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. 7. Acknowledgments The author gratefully acknowledges the helpful comments provided by members of the ietf-822 mailing list. In particular, Keith Moore has made several 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. Lilly Expires July 29, 2005 [Page 4] Internet Draft From Field Made Optional January 2005 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". 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.STD10] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [I4.RFC1036] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987. [I5.RFC2305] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. [I6.RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004. [I7.RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767, March 1995. [I8.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. Lilly Expires July 29, 2005 [Page 5] Internet Draft From Field Made Optional January 2005 [I9.HTTP] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [I10.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. [I11.RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [I12.STD53] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [I13.RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [I14.RFC977] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986. [I15.RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004. [I16.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [I17.RFC3886] Allman, E., "An Extensible Message Format for Message Tracking Responses", RFC 3886, September 2004. [I18.BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. 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 Lilly Expires July 29, 2005 [Page 6] Internet Draft From Field Made Optional January 2005 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lilly Expires July 29, 2005 [Page 7]