Internet DRAFT - draft-aeble-ooo-replies
draft-aeble-ooo-replies
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]
