WDIFF

draft-lilly-from-optional-00.txt --> draft-lilly-from-optional-01.txt

Network Working Group B. Lilly
Internet Draft January February 2005
Updates: 822, 2822 (if approved)
Expires: July 29, August 14, 2005

Message Header From Field Made Optional
draft-lilly-from-optional-00
draft-lilly-from-optional-01

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
becomes 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.

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, August 14, 2005 [Page 1]

Internet Draft From Field Made Optional January February 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. 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. 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.

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

Lilly Expires August 14, 2005 [Page 2]

Internet Draft From Field Made Optional February 2005

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

Lilly Expires July 29, August 14, 2005 [Page 3]

Internet Draft From Field Made Optional January February 2005

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.

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 [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, August 14, 2005 [Page 4]

Internet Draft From Field Made Optional January February 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, August 14, 2005 [Page 5]

Internet Draft From Field Made Optional January February 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
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Lilly Expires July 29, August 14, 2005 [Page 6]

Internet Draft From Field Made Optional January February 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, August 14, 2005 [Page 7]

----