idnits 2.17.1 draft-kularski-spam-spamreduce-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 13 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2004) is 7407 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet-Draft C. Kularski 3 Expires: June 2004 Highland School 4 of Technology 5 Category: Informational January 2004 7 Compound Procedures for SPAM Control 9 draft-kularski-spam-spamreduce-06.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document gives instructions for implementing a mail system that 34 will reduce the amount of SPAM received by the end users. The 35 instructions specify disposable and single-purpose mailboxes that 36 will allow for the source of SPAM to be easily identified. 38 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC-2119 [i]. 46 1. Introduction 47 The procedures outlined in this document require an SMTP 48 implementation that is capable of handling custom addressing 49 schemes required by this document. The SMTP service itself should 50 remain in compliance with all standards and specifications. 52 This document is NOT a guaranteed solution to SPAM, as of this 53 document�s creation no technology existed that would eliminate 54 SPAM completely. This document contains possible solutions that 55 can reduce SPAM, if you are creative with implementing the 56 solutions you will be more successful in reducing SPAM. 58 2. Address Structuring Considerations 59 The procedures in this document are easiest to implement using a 60 sub-domain for each user, such as "user.example.net". The sub- 61 domain SHOULD NOT be defined explicitly, it should be assigned as 62 a wildcard (*) Mail Exchanger RR. If you have a large number of 63 users it will be more efficient to use the dotted or hyphened 64 nomenclature specified in item 3. 66 3. To avoid DNS issues completely you can use a dotted (.) or 67 hyphenated naming structure before the "at" (@) symbol. The more 68 creative you are with the design of your address schema the fewer 69 SPAM messages your domain is likely to receive. 71 4. Email Addresses 72 There are three main classifications of email address which must 73 be defined. 75 Addresses for Automated and Non-Trusted Sources � This set of 76 addresses is defined by the user. There MUST be a way for the user 77 to easily change his/her list of available addresses quickly and 78 easily. The user will need the ability to add and delete addresses 79 from the list. The user will assign a unique address to each non- 80 trusted email source. If the source misuses the address, then the 81 address can be disposed of by deleting it from the list. Mail 82 received by these addresses should be deposited in the user�s 83 primary mailbox. If a user needs an excessive amount of non- 84 trusted source address a wildcard address can be used for this 85 purpose (with the ability to kill abused addresses), but it is not 86 recommended. 88 Address for Personal Communication � The address for personal 89 communication is a single email address defined by either the user 90 or the administrator. This address will most likely be the one 91 used as the primary mailbox for the user. The user should give 92 this address only to human sources that are unlikely to spread the 93 address. This address is optional. 95 Addresses for Common Services, Roles and Functions � Addresses 96 defined by RFC 2142[ii] should be directed to the mailbox of the 97 appropriate function on the primary domain (example: 98 abuse@user.example.net is delivered to abuse@example.net). 100 5. Considerations for Each Address Type 101 Each address type has its own special needs for them to be used to 102 their full potential and to allow the least amount of SPAM in. 104 Addresses for Automated and Non-Trusted Sources � These addresses 105 MUST be unique to each source. Mail for these addresses can be 106 filtered to add an additional level of SPAM elimination, but the 107 nature of these addresses will significantly reduce the amount of 108 SPAM received. 110 Address for Personal Communication � This address should be 111 protected in several ways. First, the address should not be widely 112 distributed and should NEVER be used for newsgroups, web pages or 113 any purpose where it will be publicly viewable. Additionally the 114 mailbox SHOULD use a whitelist (and blacklist) system to authorize 115 senders. Score-based SPAM detection systems can also be reliable 116 in "weeding out" SPAM from this box. Failing to adequately protect 117 this address will defeat the purpose of this document. 119 Addresses for Common Roles, Services and Functions � due to the 120 nature of these addresses they should not be extremely 121 restrictive, but due to the nature of SPAM attacks some protection 122 is advisable. 124 6. Possible Special Addresses 125 In addition to the addresses for non-trusted sources temporary 126 addresses that expire after a certain amount of time has elapsed 127 can be used for situations where SPAM is imminent, such as 128 newsgroup communication. 130 7. Address Examples 131 Sub-domain Non-trusted source � source@user.example.net 132 Dotted-user Non-trusted source � source.user@example.net 133 Hyphened-user Non-trusted source � source-user@example.net 134 Sub-domain Personal � user@user.example.net 135 Dotted (or Hyphened) Personal � user@example.net 137 Security Considerations 138 The information in this document introduces no Security Concerns. 140 References 141 i Bradner, S., "Key words for use in RFCs to Indicate Requirement 142 Levels", BCP 14, RFC 2119, March 1997 144 ii Crocker, D., "Mailbox Names for Common Roles, Services and 145 Functions", RFC 2142, May 1997 147 Author's Addresses 149 Curtis M. Kularski 150 219 Best St 151 Bessemer City, NC 28016-9330 152 United States 153 Phone: +1 (704) 629-2498 154 Email: spamreducedraft@curtis.kularski.us 156 Full Copyright Statement 158 Copyright (C) The Internet Society (2003). All Rights Reserved. 160 This document and translations of it may be copied and furnished to 161 others, and derivative works that comment on or otherwise explain it 162 or assist in its implementation may be prepared, copied, published 163 and distributed, in whole or in part, without restriction of any 164 kind, provided that the above copyright notice and this paragraph are 165 included on all such copies and derivative works. However, this 166 document itself may not be modified in any way, such as by removing 167 the copyright notice or references to the Internet Society or other 168 Internet organizations, except as needed for the purpose of 169 developing Internet standards in which case the procedures for 170 copyrights defined in the Internet Standards process must be 171 followed, or as required to translate it into languages other than 172 English. 174 The limited permissions granted above are perpetual and will not be 175 revoked by the Internet Society or its successors or assignees. 177 This document and the information contained herein is provided on an 178 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 179 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 180 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 181 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 182 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 184 Acknowledgement 186 Funding for the RFC Editor function is currently provided by the 187 Internet Society.