Network Working Group BZ. Zinn Internet-Draft Department of Chemistry, Louisiana Expires: October 3, 2004 State University April 4, 2004 When NOT to Bounce Email draft-zinn-smtp-bounces-00.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 October 3, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract SMTP RFCs currently require that a notice message MUST be sent when a message will not be delivered, even when the 'reverse-path' is forged by a virus. Of necessity, some ISPs are now dropping such messages silently. Silent dropping of such messages should be allowed and encouraged under certain circumstances. Zinn Expires October 3, 2004 [Page 1] Internet-Draft When NOT to Bounce Email April 2004 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. quotation from the 1928 Radio Manual, page 614 . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 10 Zinn Expires October 3, 2004 [Page 2] Internet-Draft When NOT to Bounce Email 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 October 3, 2004 [Page 3] Internet-Draft When NOT to Bounce Email April 2004 2. Introduction It is time to modify the philosophy that one must always 'deliver or bounce' because bounces are not always in the best interest of the internet. History: Long before the first e-mail was sent, it was the rule that the party in possession of a message was responsible for moving the message toward its destination or returning a notice to the originator of the message [RadioManual]. SMTP (Simple Mail Transfer Protocol) was developed in this atmosphere and the SMTP RFCs such as [RFC2821] seem to imply that the only party that may discard a message is the addressee. Anyone else handling the message MUST return a bounce (an indication of failure to deliver) to the originator. Today, the reliability of e-mail message traffic is being threatened by strict adherence to this principle. Recent viruses take advantage of bounce messages to amplify their damage. These recent viruses forge the ‚Çÿreverse path‚ÇÖ of the messages they send. If the recipient‚ÇÖs ISP detects a virus in an incoming message and blocks delivery to the targeted victim, the system operators often believe they are REQUIRED by the RFCs to send a bounce message back to the originator as indicated by the ‚Çÿreverse path‚ÇÖ. These bounces fill the inboxes of innocent victims with spurious messages. Important messages are being lost in the noise. The spurious messages contain no useful information. Just as the original message, spawned by the virus, contained no useful information, the bounce contains no useful information. Moreover, depending on what an anti virus program does about returning content, it is possibe for bounce messages to spread the virus. Even without an attached virus, such bounces increase traffic and storage requirements unnecessarily. These spurious messages falsely indicate that the supposed originator‚ÇÖs machine is infected with a virus. This false information can prompt the 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 the message is discarded with no notice given to the addressee or sender. Since both the addressee and sender are targeted as victims by the virus, there is no reason to send them notice. Bounces to forged addresses cause many problems. Many ISPs (internet Zinn Expires October 3, 2004 [Page 4] Internet-Draft When NOT to Bounce Email April 2004 service providers) are now silently discarding such messages in order to reduce spurious bounces and protect the reliability of e-mail as a communications medium. The BCP (best current practices) should reflect this fact and the RFCs should be updated to allow and encourage this practice. In a recent conversation related to spurious bounce messages, a system operator was adamant that he MUST send the bounces because the RFCs said so. That is the motivation behind this document. Zinn Expires October 3, 2004 [Page 5] Internet-Draft When NOT to Bounce Email April 2004 3. Proposal This Internet Draft states that although there may be 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. When it can be accurately determined that a message has a forged ‚Çÿreverse path‚ÇÖ, has no content desired by or useful to the addressee, and has no content useful to the forged originator, then the message SHOULD be silently discarded. If the actual source of a message spawned by a virus can be determined, the responsible ISP MAY be notified. New SMTP RFCs should be issued to make it clear that it IS ok to discard messages when it is determined that they have no useful content and such messages SHOULD be silently discarded when the ‚Çÿoriginator‚ÇÖ is forged. Zinn Expires October 3, 2004 [Page 6] Internet-Draft When NOT to Bounce Email 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. 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 such messages silently, continuing to insist on ‚Çÿmust bounce‚ÇÖ encourages a disregard of the RFCs. Zinn Expires October 3, 2004 [Page 7] Internet-Draft When NOT to Bounce Email April 2004 5. Acknowledgements The author gratefully acknowledges the encouragement, suggestions and contributions of: Keith Moore, Dan Wing, John C Klensin, Jack Cleaver, Marta Vasquez and the ietf-smtp discussion group. Zinn Expires October 3, 2004 [Page 8] Internet-Draft When NOT to Bounce Email April 2004 6. quotation from the 1928 Radio Manual, page 614 (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 [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. [RadioManual] Sterling, G., "The Radio Manual for Radio Engineers, Inspectors, Students, Operators and Radio Fans", December 1928. 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 October 3, 2004 [Page 9] Internet-Draft When NOT to Bounce Email 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 October 3, 2004 [Page 10] Internet-Draft When NOT to Bounce Email 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 October 3, 2004 [Page 11]