Internet Draft C. Kularski Informational Highland School of Technology Expires: February 2004 August 2003 SPAM Reduction Through Creative Addressing draft-kularski-spam-spamreduce-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. Abstract This document describes a procedure that users can follow to significantly cut down on the amount of SPAM that they receive. SPAM/UCE (Unsolicited Commercial Email) has become a problem for most Internet users, there is currently no complete solution to the problem. Once the procedure described in this document the user can expect to see dramatically reduced SPAM. Some user refinement may be required at first, but this procedure is very low maintenance. Conventions used in this document 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 RFC-2119 [i]. KULARSKI Expires û February 2004 [Page 1] SPAM Reduction August 2003 A Virtual Address as used in this document is an email address not directly existing on the server, but it specified by a catch-all. Table of Contents 1. General Description............................................2 1.1 Proper Implementation......................................2 2. Mailbox 1......................................................2 2.1 The Email Server Software..................................3 2.2 When SPAM Occurs...........................................3 3. Mailbox 2......................................................3 4. Combining Both Mailboxes.......................................4 5. Future Considerations..........................................4 6. Status of Experiments Performed................................5 7. Full Copyright Notice..........................................5 Security Considerations...........................................6 References........................................................6 Author's Addresses................................................6 1. General Description The key to making this procedure for SPAM elimination work with currently available server software is having two email boxes available. Each of these boxes MUST meet a different set of criteria described later in this document. This procedure can be used by corporate administrators, Internet Service Providers (ISP), or users who have the resource of their own email server. 1.1 Proper Implementation Because the procedure described in this document drastically changes the way user receives email the implementation should either be performed at the userÆs request, or with significant prior notification. 2. Mailbox 1 This mailbox can be used with automated systems, and just about any other purpose, except for those purposes noted for Mailbox 2 in Section 3. This is the only mailbox that is valid for use with non- human senders. KULARSKI Expires û February 2004 [Page 2] SPAM Reduction August 2003 For this mailbox the server will need to recognize each user as their own sub-domain (ex. Jane Doe uses janedoe.example.net). The mailbox MUST have a sub-domain or FQDN (Fully Qualified Domain Name) associated with it. An MX (Mail Exchanger) record should point the domain to the email server on which the account resides. The mailbox will be a general collection box for receiving all of the email pointed at a catch-all mailbox. The address of the real email box should remain private, unless Section 4 is utilized. If Jane uses jane@janedoe.example.net to login to her email box, she should never release jane@janedoe.example.net to anyone as her email address. Each entity that is to receive an email address from the user should be given a unique address, so that the user has the ability to terminate an email address that has been SPAMed and possibly sold to a mass mailing list. If Jane were communicating with the Internet Engineering Task Force she could communicate her email address as being IETF@janedoe.example.net. 2.1 The Email Server Software The Email server MUST have software capable of handling a catch-all system. The catch all mailbox needs to point to a single mailbox on the server. The mailbox may reside on the same domain or a separate domain, depending upon the userÆs needs and the server capabilities. The email server SHOULD support the ôX-RCPT-TOö email header to allow for identifying mail that may be disguised. Some email servers will often tell the sending server the destination of any type of forwarded address, including for catch-alls. This MUST NOT be allowed to occur on a server where the procedure described in this document is implemented. 2.2 When SPAM Occurs After a short amount of time in circulation one or more of the userÆs virtual addresses will begin to attract SPAM. As soon as SPAM is received the ôX-RCPT-TOö or ôTOö lines in the header should be checked to verify the address that the mail was destined for. The virtual address should be immediately discontinued from use. A few options exist for what to do with the virtual address after it is identified as a SPAM recipient. First, the virtual address can be created as an alias and forwarded to a dead-end mailbox that is automatically cleared after a certain amount of time (or is never permanently recorded). The second option is a little less drastic, the virtual address can be created as an alias and pointed to another actual account residing on the userÆs domain. For example, Jane can get all of her SPAMed virtual addresses pointed to KULARSKI Expires û February 2004 [Page 3] SPAM Reduction August 2003 spam@janedoe.example.net where she can later sort the mail manually, or by a conventional SPAM identification program. 3. Mailbox 2 This mailbox can be used for personal communication, public newsgroups, web page contact or a situation where the address will only be used by humans. For this mailbox the server must support intelligent white listing. Intelligent white listing involves the email box only receiving email from senders listed on the white list, but sending an email to those who are not on the white list to give them a chance to verify that they are human by accepting an email at a special address, once that mail is received and the sender is confirmed the sender is automatically added to the white list, and the mail is released from the queue and delivered to the user. White listing by itself is effective in eliminating SPAM, but is horribly inconvenient, so it MUST be used in conjunction with the catch-all mailbox in Section 2. If SPAM is found in the white listed mailbox the senderÆs email address should be removed from the white list and added to the blacklist. It is preferable to place existing email addresses as the white list protected address once automated systems that must contact the user have been notified of their assigned address on the catch-all system. Doing so will prevent an interruption in email, or the transition period often associated with changing email systems. 4. Combining Both Mailboxes Maintaining two independent email boxes is not user friendly, nor does it maintain a low amount of network traffic. Maintaining two separate mailboxes is quite resource heavy for both the server and client. The two mailboxes can be combined on most servers that support both catch-all and white list functions. The proper way to configure both systems as a single mailbox is to set up the catch-all system as specified, and then configure an alias to use white listing. If mail to the white listed alias passes the white list it can be delivered to the userÆs main mailbox that they keep secret. 5. Future Considerations KULARSKI Expires û February 2004 [Page 4] SPAM Reduction August 2003 In the future the developers of email server software may want to write the software with the ability to assign each user to their own sub-domain and not have to specify the sub-domain as an independent domain within the sever software configuration. 6. Status of Experiments Performed Several experiments of the procedure described in this document were performed. In each of the experiments there was no loss of legitimate email, and only about 2% of the mail was identified as SPAM. The experiments were performed with live email accounts and actual users using the mailboxes for a period of 6 months. The experimental users had an average of about 25 aliases for avoiding SPAM on the catch-all system, and an average of 3.2 addresses on their blacklists to avoid mail going to the whitelist only system. 7. 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 KULARSKI Expires û February 2004 [Page 5] SPAM Reduction August 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Security Considerations The actual address of the mailbox that the mail is pointed to as its final destination should never be revealed. If it is revealed to an inappropriate entity the user could begin receiving SPAM that canÆt be prevented. In the event the primary mailbox is divulged it should be renamed by the administration as soon as possible. Because this document does not specify an Internet standard of any kind there are no direct security considerations. References i Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Author's Addresses Curtis M. Kularski 219 Best St Bessemer City, NC 28016-9330 United States Phone: +1 (704) 629-2498 Email: curtis@kularski.net Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. KULARSKI Expires û February 2004 [Page 6]