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]