Network Working Group P. Kucharski INTERNET-DRAFT September 2003 Expires: March 2004 Recommendations for automatic notifications about email viruses draft-kucharski-email-viruses-00.txt Status of this Document 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 document is a product of an individual. Comments are solicited and should be addressed to the author. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo makes recommendations for sending automatic notifications by software used in antivirus protection of email messages. The purpose of these recommendations is to discourage undesirable behaviour which is caused or aggravated by such software. Terminology This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate Kucharski Automatic email viruses notifications [Page 1] INTERNET-DRAFT Expires: February 2004 August 2003 particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC2119]. Definitions Email, email message or message: defined in [RFC2822]. Body of the email: defined in section 2.3 of [RFC2822] with extensions, specifically the MIME documents [RFC2045], [RFC2046], [RFC2048], [RFC2049]. Trace fields: defined in section 3.6.7 of [RFC2822]. Originator fields: defined in section 3.6.2 of [RFC2822]. The origination date field: defined in section 3.6.1 of [RFC2822]. Identification fields: defined in section 3.6.4 of [RFC2822]. Destination address fields: defined in section 3.6.3 of [RFC2822]. Introduction Current increase of viruses passed by emails almost enforces most administrators to use some kind of protective shields, most usually in the form of automatic mail scanning on the mail hub. Behaviour of such automatons is subject to this memo. Outline It is generally good practice to inform sender about his email being rejected, providing him with reasons and meaningful headers of his email. Many viruses are spreading without users knowing and such notification may allow users to take some actions. Some viruses, however, are faking sender address of the email, making such notifications unnecessary and confusing for innocent users and, which may be considered as bad, generating high volume of unnecessary email traffic. Antivirus software As antivirus software can identify and cure or eliminate the viruses only after the virus was caught and analyzed, it is safe to assume that antivirus authors are aware of the methods used by the virus to spread. Hence antivirus software SHOULD return codes allowing to identify the virus which infected the message and whether this virus is faking sender address of the email. Implementation details are left up to the software authors. Kucharski Automatic email viruses notifications [Page 2] INTERNET-DRAFT Expires: February 2004 August 2003 If system administrator is not using antivirus software, but instead some rules for identifying viruses (like searching for specific strings in the body of email, or denying certain files or extensions), this also constitutes as antivirus software for the purpose of this document. Behaviour of antivirus filters The only possible course of action SHOULD be either accept or reject the message in its whole. Accepting is achieved by passing the message further on its mail path. Rejecting is achieved by not delivering message to its destination, which can be done in several ways, from refusing to accept the message at the SMTP session level, quarantining message for some time or simply deleting the message. Each way of rejecting MUST follow guidelines of notifications. Refusing to accept infected mails When system is configured to refuse infected mails at the end of "Mail Transaction" stage (See section 3.3 of [RFC2821]), it MUST refuse the mail with "Permanent Negative Completion" reply, as defined in section 4.2.1 of [RFC2821]. Note that such behaviour may lead to increased amount of mail traffic and system resources, as viruses with own SMTP engines may not follow [RFC2821], ignore "Permanent Negative Completion" reply and resubmit that mail indefinitely. Note also that delegating responsibility to deal with infected messages with forged sender headers to the system that already accepted such message will in fact lead to generating replies by that system to the innocent users. Modifications of a message Antivirus software and automaton system MUST NOT change the body of the message by deliberately damaging infected parts or by replacing infected parts with safe content (with the exception of following paragraph), especially when they pass the message on. Antivirus software or automaton system MAY replace infected parts with text attachment (in conformance with MIME specifications) only when the infection was not a worm or a virus which fakes the sender address AND the message came from outside to the local user. This text attachment MUST contain clear information about causes of such content removal. Infected messages from local users MUST be rejected in whole. The scope of local is left up to the administrator to decide, but it Kucharski Automatic email viruses notifications [Page 3] INTERNET-DRAFT Expires: February 2004 August 2003 SHOULD NOT exceed organization level. If antivirus software or automaton system detects the infection with a virus, which fakes the sender address, the message MUST NOT be modified and MUST be rejected. Automaton system MAY change the names of files in the attachments to protect users. If antivirus software or automaton system manages to successfully cure all parts of the message, such message SHOULD be treated as not infected at all, hence it SHOULD NOT send notifications. Whether such setup is desired, it is left up to the administrator. Antivirus software and automaton system MAY add to email message some informative header(s) containing info about automatic scanning, its effects, etc. Notification format Notification MUST be sent from a valid email address. Notification MUST contain the reason of stopping email, MUST contain trace fields (namely "Received:") and SHOULD contain originator fields, the origination date field, identification fields and destination address fields. (See definitions for details.) Notification MUST NOT contain body of the email. Notification of a sender Automatons doing antivirus scanning MUST be aware of the state of antivirus software deployed, ie. whether it is able to pass information about the name of the virus and/or about sender address being faked by the virus. If antivirus software is detecting virus faking sender address in the message, the automaton MUST NOT send notification to the sender of the email. If antivirus software is detecting virus presumed to be not faking sender address, the automaton SHOULD inform the sender about rejected email message. If antivirus software does not implement return codes allowing to determine, whether message is infected with a virus faking the sender address, or with a virus not faking the sender address, but it does return name of a virus, it is the administrator's duty to identify Kucharski Automatic email viruses notifications [Page 4] INTERNET-DRAFT Expires: February 2004 August 2003 viruses that fake sender address (See Appendix A) and configure automaton system to act accordingly based upon virus name. If antivirus software does not implement neither returning the virus name nor information about whether virus is faking sender address, automaton SHOULD send notification back to sender to be in conformance with [RFC2821]. It is advised however that such antivirus software SHOULD NOT be used. Notification of the recipient(s) Automatons SHOULD NOT send notifications about blocked email message to the recipient(s) of that message. Notification of an administrator It is left up to administrator to decide, what information is needed for tracking purpose and how it is passed to him, whether simple mail with notification, syslog event or quarantined mail. Keeping the body of the email is NOT REQUIRED. Bibliography [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Format of Internet Message Bodies", RFC 2048, November 1996. [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC Kucharski Automatic email viruses notifications [Page 5] INTERNET-DRAFT Expires: February 2004 August 2003 2821, April 2001. [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. Author's address Piotr Kucharski Szkola Glowna Handlowa Niepodleglosci 162 pok. 13 Warszawa 02-554, Poland EMail: chopin@sgh.waw.pl Appendix A. Viruses known to fake sender address. At the moment of writing this document, viruses which are known to fake sender address of the email messages include, but are not limited to: Bridex aka Braid, Bugbear aka Tanatos, FunLove, Klez, MiMail, Sobig. Kucharski Automatic email viruses notifications [Page 6]