Network Working Group Internet Draft C. Kularski Highland School of Technology Expires: February 2004 August 2003 SPAM Reduction Through Creative Addressing draft-kularski-spam-spamreduce-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 [i]. 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 SPAM/UCE (Unsolicited Commercial Email) has become a problem for most Internet users. This document aims to establish a procedure that users can follow to significantly cut down on the amount of SPAM that they receive. Once in place the user can expect to spend about 30 days from the time of the first SPAM creating a list of mailboxes that should be made invalid. 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 [ii]. 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. KULARSKI Expires û February 2004 [Page 1] SPAM Reduction August 2003 Table of Contents 1. General Description............................................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 Security Considerations...........................................4 References........................................................4 Author's Addresses................................................5 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. 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. 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. KULARSKI Expires û February 2004 [Page 2] SPAM Reduction August 2003 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 spam@janedoe.example.net where she can later sort the mail by hand, 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. KULARSKI Expires û February 2004 [Page 3] SPAM Reduction August 2003 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. 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 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. 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., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. KULARSKI Expires û February 2004 [Page 4] SPAM Reduction August 2003 ii 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 Comments about this document should be sent to internet-draft@curtis.kularski.us KULARSKI Expires û February 2004 [Page 5]