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 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]