Network Working Group A. Eble Internet-Draft fsck Expires: March 26, 2004 September 26, 2003 Security Best Practices: Out-of-Office Replies draft-aeble-ooo-replies-00 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 March 26, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Email has come to be the single most important application of modern Information Technology. It is often considered business critical. Most current email systems have means for automated replies to incoming messages. These are mostly used for so-called out-of-office replies or OoO-replies for short. This document discusses problems of out-of-office replies and suggests best practices and controls that should be put in place. Eble Expires March 26, 2004 [Page 1] Internet-Draft Security Best Practices: Out-of-Office Replies September 2003 1. 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 particular requirements of this specification. A discussion of the meanings of these terms appears in RFC2119. In this document, the sender of the original message is called sender or originator and the recipient of said message addressee or recipient. The out-of-office reply will then originate at the recipient's side. Eble Expires March 26, 2004 [Page 2] Internet-Draft Security Best Practices: Out-of-Office Replies September 2003 2. Introduction Email is the most prominent application in information technology. Many companies rely on its timely delivery, the asynchronicity of the medium and the anonymity especially compared to the telephone. Since people expect an email to be delivered almost immediately even to addressees on the other side of the world, it is singularly annoying to many not to receive a reply to a message declared urgent. Thus, modern email systems offer the capability of so-called out-of-office replies where the addressee sets up an automated agent to automatically reply to incoming messages. While this feature sounds interesting and useful, the possible misconfiguration and abuse far surpasses its usefulness. Eble Expires March 26, 2004 [Page 3] Internet-Draft Security Best Practices: Out-of-Office Replies September 2003 3. Problems 3.1 Mailing Lists Many employees in technical positions subscribe to mailing lists, most to several simultaneously. If every message from the mailing list generates an automated OoO reply, the list contributors will be annoyed or, even worse, the list will be swamped with OoO messages, thus effectively posing a denial-of-service attack. This especially counts for large lists hosted on systems with limited bandwidth. In addition, OoO replies will possibly generate traffic about the reply from annoyed subscribers, thus lowering the signal/noise ratio significantly. 3.2 Security Considerations OoO replies are known to contain job information about the addressee. This is particularly interesting if the job is in a sensitive area like Human Resources, account management or some sort of security position. Any such information may help a hostile person significantly to launch a social engineering attack against the organization. "Social Engineering" is the process of gleaning potentially sensitive information from third parties or making them initiate processes that are available only to personnel inside the organization being attacked. Eble Expires March 26, 2004 [Page 4] Internet-Draft Security Best Practices: Out-of-Office Replies September 2003 4. Suggested Practices Wherever possible, OoO replies SHOULD NOT be used. If they have to be used, their use should be tightly controlled: 1. OoO replies SHOULD only be used internal to any organization. Any mailbox available for contact with external parties SHOULD be a role-based mailbox to which several employees have access. Outgoing replies SHOULD have a From: header from that role mailbox, not from the person replying. This serves the purposes of * being always available to the external party * keeping sensitive information in-house. Role-based mailboxes SHALL NOT generate OoO replies ever. 2. OoO replies MUST NOT include job information of the addressee. 3. OoO replies SHALL NOT be generated in response to emails with a Header "Precedence: bulk", "Precedence: junk" or "Precedence: list". 4. OoO systems MUST remember which originators were already notified and MUST NOT resend another OoO reply during a configurable timeframe. This timeframe SHOULD vary between one week and one month. 5. An OoO reply MUST NOT be generated in response to emails 1. from an address that ends with -REQUEST 2. originating from Postmaster 3. originating from UUCP, 4. originating from MAILER, 5. originating from MAILER-DAEMON. These addresses have a high probability of being used by automated services of the given mail system and thus might be able to create a mail loop. This has to be avoided by all means. 6. An OoO reply MUST NOT be generated in response to messages that are tagged as spam. OoO replies are a great way for spammers to harvest addresses for further mailings. Eble Expires March 26, 2004 [Page 5] Internet-Draft Security Best Practices: Out-of-Office Replies September 2003 7. The Postmaster role either MUST be able to turn off the OoO reply feature for every user on the system or MUST be able to delegate this task to an appropriate party (like a system administrator). Eble Expires March 26, 2004 [Page 6] Internet-Draft Security Best Practices: Out-of-Office Replies September 2003 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. Author's Address Axel Eble Frankfurt Security Consulting Kooperative Aussiger Str. 7 Rodgau 63110 DE Phone: +49 178 285-3265 EMail: axel.eble@fsck.de Eble Expires March 26, 2004 [Page 7] Internet-Draft Security Best Practices: Out-of-Office Replies September 2003 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 (2003). 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 Eble Expires March 26, 2004 [Page 8] Internet-Draft Security Best Practices: Out-of-Office Replies September 2003 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. Eble Expires March 26, 2004 [Page 9]