Network Working Group BZ. Zinn Internet-Draft Department of Chemistry, Louisiana Expires: September 30, 2004 State University April 2004 Relaxing SMTP's "deliver or notify" rule draft-zinn-smtp-bounces-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on September 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Current SMTP RFCs are interpreted by some as requiring non delivery notice to be sent, even when the "reverse-path" is forged by a virus. Some ISPs are now dropping such messages silently. Silent dropping of such messages should be encouraged under certain circumstances, however this should not be taken as a permananet carte-blanch to silently discard any message that one does not like. Zinn Expires September 30, 2004 [Page 1] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. quotation from the 1928 Radio Manual, page 614 [NOTE - this quote might not be included in the final document] . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 11 Zinn Expires September 30, 2004 [Page 2] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Zinn Expires September 30, 2004 [Page 3] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 2. Introduction It is time to modify the philosophy that one must always 'deliver or bounce' because non delivery notice messages, also known as bounces, are no longer always in the best interest of the internet. Long before the first e-mail was ever sent, the party in possession of a message was held responsible for moving it toward its destination or returning a notice to the originator of the message [1928RadioManual]. SMTP (Simple Mail Transfer Protocol) was developed in this atmosphere and the SMTP RFCs such as [RFC2821] imply that only the addressee may discard a message. Anyone else handling the message MUST return a bounce to the originator. Today, the reliability of e-mail is threatened by blind adherence to this principle. Important messages are being lost in the noise. Some system operators are adamant that bounces MUST be sent "because the RFCs say so." Others are adamant that such messages MUST be refuse with a 5xx code, "because the RFCs say so." Recent viruses take advantage of bounce messages to spread. They forge the "reverse path" of the messages they send. Some even send fake bounce message. A virus spawned message contains no useful information and the bounce is of no interest to the forged sender. Moreover, depending on the anti virus program used and what is done with message content, it is possibe for the bounce to spread the virus. Even without an attached virus, these spurious bounces increase traffic and storage requirements. These messages falsely indicate that the supposed originator"s machine is infected with a virus. This false information can prompt a user to damage their machine by trying to remove a nonexistent virus. "Silent message dropping" implies that a message is accepted for delivery or relay and then discarded with no notice given to the addressee or sender. Both the addressee and forged sender are targets of the virus, there is no reason to further victimize them by sending them notice. Bounces to forged addresses cause many problems, some ISPs (internet service providers) now silently discard such messages. When done carefully, this represents best current practices and should be encouraged. Zinn Expires September 30, 2004 [Page 4] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 3. Proposal Although there is clearly an obligation to deliver or notify when a message has a valid origin, messages generated by viruses are "invalid" in origin and carry neither an obligation to deliver nor an obligation to notify. There is a need to make it explicitly clear that this obligation only applies to "real" messages and that when an MTA can accurately determined that a message has a forged "reverse path" and has no content useful to the addressee, the message SHOULD be silently discarded. If the actual source of the message can be determined, the responsible ISP MAY be notified. revised wording: The concept of "real or genuine mail" is introduced. Genuine mail is originated by an individual or his agent. The individual must be authorized to create such messages and to send them from the equipment in question. Messages sent by viruses are clearly NOT genuine mail. The exact method of determining that a message is genuine is deliberately not specified at this time. RFC 821 like wording: If a server-SMTP has accepted the task of relaying a 'genuine' message and later finds that the forward-path is incorrect or that the mail cannot be delivered for whatever reason, then it must construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path). 'There is no obligation to deliver or notify for messages that are not genuine, such as those generated by a virus.' RFC 2821 like wording: 6.0 Reliable Delivery and Replies by Email: When the receiver-SMTP accepts a 'genuine' piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. It MUST NOT lose the message for frivolous reasons, such as because the host later crashes or because of a predictable resource shortage. 'However, messages generated by viruses are not genuine e-mail messages and SHOULD be silently discarded. If the infected machine can be identified, notification MAY be sent to those responsible. ' If there is a delivery failure after acceptance of a 'genuine' message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line). However, if this address is null ("<>") 'or if the return path is determined to be forged,' the receiver-SMTP MUST NOT send a notification. Obviously, nothing in this section can or should prohibit local decisions (i.e., as part of the same system environment as the receiver-SMTP) to log or otherwise transmit information about such events locally if that is desired. Zinn Expires September 30, 2004 [Page 5] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 If the address is an explicit source route, it MUST be stripped down to its final hop. .... 7.7 Scope of Operation of SMTP Servers It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server. However, cooperation among sites and installations makes the Internet possible. If sites take excessive advantage of the right to reject traffic, the ubiquity of email availability (one of the strengths of the Internet) will be threatened; considerable care should be taken and balance maintained if a site decides to be selective about the traffic it will accept and process. ' Special care must be exercised when messages are accepted and then silently dropped to avoid silently dropping genuine messages.' In recent years, use of the relay function through arbitrary sites has been used as part of hostile efforts to hide the actual origins of mail. Some sites have decided to limit the use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering. When 'genuine' mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL, or RCPT as appropriate. Zinn Expires September 30, 2004 [Page 6] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 4. Security Considerations This proposal would modify the long standing assumption that any message sent will either be delivered or trigger a notification bounce by adding the modifier 'genuine' so that henceforth '...any 'genuine' message sent will either be delivered or trigger.... The change might seem to "reduce the reliability" of e-mail as a communications channel. However, failure to silently delete messages spawned by viruses exacerbates the damage done by viruses. If message dropping is done carefully, fewer "real" messages will be lost than would be lost if the "must bounce" rule were followed. Blind adherence to the "must bounce" principle causes a greater overall harm to the communications channel because it decreases the reliability of e-mail and speeds the propagation of worms and viruses. As some ISPs are now dropping some messages silently, continuing to insist on "must bounce" encourages a disregard of the RFCs. Failure to explicitly allow silent dropping of virus infected messages reduces the usefulness of the internet. Zinn Expires September 30, 2004 [Page 7] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 5. Acknowledgements The author gratefully acknowledges the encouragement, suggestions, comments, critiques and contributions of: Keith Moore, Dan Wing, John C Klensin, Jack Cleaver, Marta Vasquez, Daryl Odnert, "wayne", "Laurence F. Sheldon, Jr.", John F Hall, "Chris U", Dan Oetting, Hal Murray, "Morely 'spam is theft' Dotes", Robert Bonomi, "Someone Else", "Morely 'I drank what?' Dotes", Vernon Schryver, Norman L. DeForest, "Buss Error", Duncan Hill, Tony Roza, Karsten M. Self, "werner -at- ccwf.cc.utexas.edu", Walter Dnes, Warren Block, the nanae news group, and the ietf-smtp discussion group. Note: this is the first revision of http://www.ietf.org/internet-drafts/draft-zinn-smtp-bounces-00.txt Zinn Expires September 30, 2004 [Page 8] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 6. quotation from the 1928 Radio Manual, page 614 [NOTE - this quote might not be included in the final document] (52)Whenever it is impossible to deliver a message that has been received, a service [message] must be forwarded immediately to the office of origin of the message which can not be delivered, stating the reason for non-delivery. (53)Service message received pertaining to non-delivery due to improper address of a message previously transmitted should be compared with the original message, and if there is any discrepancy, the office reporting non-delivery shall be immediately notified by service [message] of the correct address as appearing on the original message. In such cases it is not necessary to notify the sender. (54)Should, however the address as repeated in the service [message] be found to correspond with the address on the original message, a copy of the service message shall be delivered to the sender and a recipt obtained. In such cases the sender can only rectify or complete the address by means of a paid service message. 7 References [1928RadioManual] Sterling, G., "The Radio Manual for Radio Engineers, Inspectors, Students, Operators and Radio Fans", December 1928. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. Zinn Expires September 30, 2004 [Page 9] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 Author's Address Robert R. Zinn Department of Chemistry, Louisiana State University 232 Choppin Hall Baton Rouge, LA 70893 US Phone: +1 225 578 5381 EMail: Bz+IDprop@chem.lsu.edu URI: http://chemistry.lsu.edu/bz Zinn Expires September 30, 2004 [Page 10] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Zinn Expires September 30, 2004 [Page 11] Internet-Draft Relaxing SMTP's "deliver or notify" rule April 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zinn Expires September 30, 2004 [Page 12]