A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension
RFC 3865
Document | Type |
RFC - Proposed Standard
(September 2004; No errata)
Was draft-malamud-no-soliciting (individual in app area)
|
|
---|---|---|---|
Author | Carl Malamud | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3865 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Harald Alvestrand | ||
Send notices to | (None) |
Network Working Group C. Malamud Request for Comments: 3865 Memory Palace Press Category: Standards Track September 2004 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described. Malamud Standards Track [Page 1] RFC 3865 No Soliciting September 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Spam Pandemic. . . . . . . . . . . . . . . . . . . . 3 1.2. No Soliciting in the Real World. . . . . . . . . . . . . 4 1.3. No Soliciting and Electronic Mail. . . . . . . . . . . . 5 2. The No-Soliciting SMTP Service Extension . . . . . . . . . . . 6 2.1. The EHLO Exchange. . . . . . . . . . . . . . . . . . . . 7 2.2. Solicitation Class Keywords. . . . . . . . . . . . . . . 7 2.2.1. Note on Choice of Solicitation Class Keywords. . 8 2.3. The MAIL FROM Command. . . . . . . . . . . . . . . . . . 9 2.4. Error Reporting and Enhanced Mail Status Codes . . . . . 10 2.5. Solicitation Mail Header . . . . . . . . . . . . . . . . 10 2.6. Insertion of Solicitation Keywords in Trace Fields . . . 11 2.7. Relay of Messages. . . . . . . . . . . . . . . . . . . . 12 2.8. No Default Solicitation Class. . . . . . . . . . . . . . 12 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4.1. The Mail Parameters Registry . . . . . . . . . . . . . . 13 4.2. Trace Fields . . . . . . . . . . . . . . . . . . . . . . 14 4.3. The Solicitation Mail Header . . . . . . . . . . . . . . 14 5. Author's Acknowledgements . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 6.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Collected ABNF Descriptions (Normative) . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 19 Malamud Standards Track [Page 2] RFC 3865 No Soliciting September 2004 1. Introduction 1.1. The Spam Pandemic Unsolicited Bulk Email (UBE), otherwise known as spam, has become as one of the most pressing issues on the Internet. One oft-quoted study estimated that spam would cost businesses $13 billion in 2003 [Ferris]. In April 2003, AOL reported that it had blocked 2.37 billion pieces of UBE in a single day [CNET]. And, in a sure sign that UBE has become of pressing concern, numerous politicians have begun to issue pronouncements and prescriptions for fighting this epidemic [Schumer][FTC]. A variety of mechanisms from the technical community have been proposed and/or implemented to fight UBE: o Whitelists are lists of known non-spammers. For example, Habeas, Inc. maintains a Habeas User List (HUL) of people who have agreed to not spam. By including a haiku in email headers and enforcing copyright on that ditty, they enforce their anti-spamming terms of service [Habeas]. o Blacklists are lists of known spammers or ISPs that allow spam [ROKSO]. o Spam filters run client-side or server-side to filter out spam based on whitelists, blacklists, and textual and header analysis [Assassin]. o A large number of documents address the overall technical considerations for the control of UBE [crocker-spam-techconsider], operational considerations for SMTP agents [RFC2505], and various extensions to the protocols to support UBE identification and filtering [danisch-dns-rr-smtp][daboo-sieve-spamtest][crouzet- amtp]. o Various proposals have been advanced for "do not spam" lists, akinShow full document text