This version addresses all technical and editorial issues raised in
the group thus far. The "Keywords" header has been changed to
"Sender-Keywords" in light of Jacob Pame's recommendation. References
to U.S. law have been internationalized. The Rationale has more
material addressing various issues and objections.
---------------------------------------------------------------------------
Anti Spam Research Group Eric Raymond
Internet-Draft Open Source Initiative
Expires: XXXX XX, 2004 Nov 26 2003
Requirements for Advertising and Bulk Email
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.
This Internet-Draft will expire on XXXX XX, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights
Reserved.
Abstract
This Internet-Draft describes standards for labeling of commercial
and bulk email.
1. Introduction
The "CAN-SPAM Act of 2003" [CAN-SPAM] amends U.S. Federal law
to read in part (11.2):
The Commission shall transmit to the Senate Committee on
Commerce, Science, and Transportation and the House of
Representatives Committee on Energy and Commerce--a report,
within 18 months after the date of enactment of this Act,
that sets forth a plan for requiring commercial electronic
mail to be identifiable from its subject line, by means of
compliance with Internet Engineering Task Force Standards,
the use of the characters `ADV' in the subject line, or other
comparable identifier, or an explanation of any concerns the
Commission has that cause the Commission to recommend against
the plan.
The IETF accepts this as a request to develop a technical
recommendation for requirements on commercial email that will
support the purposes of the Act.
2. Definitions
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 [RFC2119].
For purposes of this RFC, "commercial email" is email sent for
the purpose of advertising a product or service, but not
including transactional or relationship messages. See CAN-SPAM
Section 3.2.
For purposes of this RFC, "bulk email" is mail duplicated to a
list of one hundred (100) or more recipients in substantially
identical form; that is, such that the variations do not affect
the meaning of the mail as it is read by a human being.
For purposes of this RFC, "porn email" is mail which either
contains pornographic content or which offers access to such
material. In U.S. jurisdictions, the relevant legal definition
is section 2256 of title 18, United States Code.
3 Labeling methods
3.1 The ADV convention
Commercial email from reputable firms is often labeled with the
prefix "ADV:" in the Subject header.
This has the advantage of being readily visible, because
effectively all mail readers display mail subject lines in their
summary views. It has the disadvantage that, because of the way
many mailreaders generate reply subject lines, the label may
persist in replies where it is not appropriate,
3.2 The Sender-Keywords header
The Sender-Keywords header contains keywords describing the content
of the mail. Keywords are separated by whitespace and/or commas.
For purposes of conformance to the requirements of [CAN-SPAM], the
following keywords are defined:
advertising Applicable to any commercial email
bulk Applicable to any bulk email
porn Applicable to any porn email
The Sender-Keywords is a necessary part of the sender's compliance with
[CAN-SPAM] and SHOULD NOT be removed or rewritten by relaying systems,
MTAs, or MUAs
4. Opt-out support
The List-Unsubscribe header, defined in [RFC2369], supports list
unsubscription via mechanisms including:
(a) a mailto: URL with the property that sending
mail to it unsubscribes the sender.
(b) a URL to a page where the user may enter an
address to be unsubscribed.
The presence of these mechanisms fulfills the requirements of
[CAN-SPAM] 5.3.
5. Accountability and transparency
The List-Owner header, defined in [RFC2369], specifies a
responsible list administrator to cope with situations in whicch
the List-Unsubscribe mechanisms are inadequate or temporarily
faulty.
The List-Owner header is optional and may be omitted if the
responsible person is the postmaster of the originating system.
6. Conformance requirements
These conformance requirements directly address the legal
requirements of [CAN-SPAM], and will constitute the Internet
Engineering Task Force's recommendation to the Federal
Trade Commission as solicited in section 11.2.
Commercial electronic mail MUST be labeled using at least one of
either the ADV: Subject-line prefix or the token "advertising" in
a Sender-Keywords header.
Bulk email MAY be labeled with the token "bulk" in a Keywords
header. Commercial bulk email MUST be so labeled.
Porn email MAY be labeled with the token "porn" in a Keywords
header. Commercial porn email MUST be so labeled.
Commercial bulk email MUST include a List-Unsubscribe header
implementing the RFC2369 proposal.
Commercial bulk email SHOULD, if the responsible sender is not the
postmaster of the originating system, include a List-Owner
header implementing the RFC2369 proposal.
7. Rationale
In the interests of making adoption as rapid and painless as
possible, this RFC extends and codifies existing practice rather
than inventing new mechanisms.
ADV: by itself is not sufficient. The user's MUA might render
the Subject line in a CJK or other encoding in which the characters
"ADV:" don't exist.
The temptation to design a classification system for
advertising, permitting more exact labeling than "ADV:", is
strong. However, no such elaborate system is required by
[CAN-SPAM], and were we to invent one it might in fact be
unenforceable under the Act. Furthermore, the boundaries of
such a system would be a subject of endless dispute, both during
design and after implementation.
The conformance requirements have been designed to have minimal
impact on individual mail senders, maximal impact on commercial bulk
mailers. In particular, the guidelines on labeling non-bulk mail in
the "advertising" and "porn" classes are written with MAY rather than
SHOULD because the spam problem isn't caused by one-to-one
communication.
Internationalization was considered. With a total inventory of four
tokens intended to be maxhine-readable (rather than presented
directly to humans), the benefits seem small and the added complexity
of a multilingual vocabulary rather pointless.
6. References
[CAN-SPAM] "An Act to regulate interstate commerce by imposing
limitations and penalties on the transmission of
unsolicited commercial electronic mail via the
Internet". S.877, passed the U.S. House or
Representatives on 21 Nov 2003.
[RFC2119] "Key words for use in RFCs to Indicate Requirement
Level"; Scott Bradner.
[RFC2822] "RFC 2822 - Internet Message Format"; Peter Resnick
(Editor).
[RFC2369] "The Use of URLs as Meta-Syntax for Core Mail List
Commands and their Transport through Message Header
Fields"; Joshua D. Baer & Grant Neufeld.
Authors' Addresses
Eric S. Raymond
Open Source Initiative
6 Karen Drive,
Malvern PA 19355
US
EMail: esr(_at_)thyrsus(_dot_)com
URI: http://www.catb.org/
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
assigns.
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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgements
Funding for the RFC Editor function is currently provided by
the Internet Society.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
"...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
-- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg