Subject: [Asrg] 6. Propsals -- Labeling recommendations for the FTC

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 26 Nov 2003 08:50:17 -0500

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] reads 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 direction 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 Keywords header

 The Keywords header, described in [RFC822], 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

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 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.

 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.

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 House 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: [email-masked]
 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>

Rapists just *love* unarmed women.  And the politicians who disarm them.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 26 Nov 2003 09:42:51 -0500

Eric,

i18n/l10n.

Eric

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 26 Nov 2003 09:45:46 -0500

> Eric

I thought about it.

Yes, the keywords and ADV are English.  There are 4, count 'em 4 tokens;
with a vocabulary that small, the benefits of internationalization are 
extremely dubious compared to the added complexity.

I'll add a 'graph about this to the Rationale.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 26 Nov 2003 09:54:23 -0500

We differ.

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 26 Nov 2003 10:19:03 -0500 (EST)

>  The presence of these mechanisms fulfills the requirements of

Have any MUAs expressed plans to support (a)? 

Daniel Feenberg

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 26 Nov 2003 10:34:59 -0500

> Have any MUAs expressed plans to support (a)? 

What, with an "unsubscrube" button?  Not that I know of.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 26 Nov 2003 16:10:51 +0000

> Have any MUAs expressed plans to support (a)? 

pine already does. A bit.

--

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 26 Nov 2003 11:29:51 -0500 (EST)

> What, with an "unsubscrube" button?  Not that I know of.

Recall that most (all?) MUAs that I am suppress headers except Subject:,
From: and To:, so that a list-unsubscribe header is invisible to the end
user unless they know the secret "display all headers" icon. Few do.

Note that when spam receipients forward spam to the FTC, the MUA deletes
the headers, so the spammer's lawyer can always reply to an action by the
FTC with the claim "list-unsubscribe" was in the headers, and neither the
FTC nor the initial complainaint will have any ability to cast doubt on
that claim, since MUAs don't save the headers unless "display all headers"
is set. Note that under long-standing US law and custom, the lawyer can
make this claim without asking the client if it is true or not, and
nothing need be sworn. It is still an effective defense unless substantial
evidence is provided controverting it.

If (a) is to be allowed, MUAs really have to come on board. Not all of
them, but at least one in reasonably wide use.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 26 Nov 2003 11:46:29 -0500

> extremely dubious compared to the added complexity.

Would "ADV" matching be done before or after any charset conversion?

Also, would it be worth a sentence somewhere that says that the
existence of this I-D (or RFC) in no way endorses any particular
approach (I'm specifically thinking of the implication that suddenly
opt-out has been sanctified).

While I am here: is there a current practice of any sort for a
header that identifies the end-user filter program that the message
has passed through?  e.g.   "X-Filtered-By:  spamanoid version 3.2" ?
I seem to recall seeing one once, but haven't been able to locate it.

Yours,
-mm-

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 26 Nov 2003 12:12:25 -0500

> Would "ADV" matching be done before or after any charset conversion?

Can't be after -- your character set might wind up being one of the
wide-character CJK encodings, in which case you can't even write "ADV:".
Thanks for pointing out that this means some form of Keyword header 
is not optional; I will add a note to the Rationale.

> opt-out has been sanctified).

I don't think we need to go there.  In fact, I'd prefer the RFC not 
talk about policy at all, just specify mechanisms.  Lees controversy
that way.

> I seem to recall seeing one once, but haven't been able to locate it.

I don't know of any standard practice.  I had planned to write up such a 
proposal as part of this draft, but as that is not responsive to the
CAN-SPAM request it is really a separate topic.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 26 Nov 2003 12:16:15 -0500

> wide-character CJK encodings, in which case you can't even write "ADV:".

That was more or less the implication. 

Thanks for the other responses too.

Yours,
-mm-

---

From: "Dave Atherton" <[email-masked]>
Date: Wed, 26 Nov 2003 09:24:02 -0800

----- Original Message ----- 
From: "Eric S. Raymond" <[email-masked]>
>  The "CAN-SPAM Act of 2003" [CAN-SPAM] reads in part (11.2):
<snip>
>            Internet".  S.877, passed the House on 21 Nov 2003.

In consideration of the majority of the planet's population, should not
references to CAN-SPAM and the houses of Congress be prefaced with terms
like "US", "USA", or "US Federal"?

-Dave

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 26 Nov 2003 12:48:31 -0500

> like "US", "USA", or "US Federal"?

I had that about 0.75 done, I'll get the rest.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 15:19:38 -0500

> I'll add a 'graph about this to the Rationale.

At the recent OpenGroup Messaging Forum Conference, one of the speakers 
from Asia discussed the Korean anti-spam law that requires a similar 
labeling scheme in Korean. He mentioned that spammers tend to use 
different character sets that technical say the same thing, but in 
practice are harder to filter.

Yakov
-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
"One who watches the wind will never sow, and one who keeps his eyes on 
the clouds will never reap" (Ecclesiastes 11:4)
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 15:21:58 -0500

> CAN-SPAM request it is really a separate topic.

However, such topic might be very useful to pursue anyway. Is anyway 
interested in this topic?

Yakov

-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
"I ate your Web page. / Forgive me. It was juicy / And tart on my 
tongue." (MIT's 404 Message)
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 15:26:19 -0500

> I seem to recall seeing one once, but haven't been able to locate it.

There isn't one we are aware of, but if folks are interested perhaps we 
should work on one?

Yakov

-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
  "Why are both drug addicts and computer aficionados both called 
users?" (Clifford Stoll)
-------

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 26 Nov 2003 15:38:37 -0500

> interested in this topic?

I still am, and I have implementation experience from the design of bogofilter.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 26 Nov 2003 15:46:18 -0500

> There isn't one we are aware of, but if folks are interested perhaps we 

Would it be more appropriate for ietf-mta-filters ?
I had intended to ask there, as well.

mm

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 15:57:32 -0500

> I had intended to ask there, as well.

I am forwarding this message to the IAB to see where would be the proper 
place for this, and whether the entire idea should be pursued. 
Meanwhile, it would be useful if all of the folks that are interested in 
this, let us know about their interest.

Yakov

-------
Yakov Shafranovich / PGP Key: 0x10D051E6 / www.shaftek.org
SolidMatrix Technologies, Inc. / www.solidmatrix.com
"Power tends to corrupt, and absolute power corrupts absolutely" (Lord 
Acton)
-------

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 16:03:08 -0500

> I had intended to ask there, as well.

I passed on the request. Meanwhile, I wanted to know, if standard 
headers are used for this, then what will stop a spammer from injecting 
those headers with a positive score into the message, and what would the 
MUAs, MTAs and filters do in that case?

Yakov

-------

---

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 26 Nov 2003 16:35:47 -0500

> MUAs, MTAs and filters do in that case?

I'm interested in the topic, perhaps not to wrangle over it but at
least to have a standard way of identifying the filter program(s)
being used.  If there's already something in practical use, or some
current thinking on the subject, so much the better.  I was thinking
mostly of a meaningless "filtered-by" sort of label, but you mention a
score, for which there might be a more structured header or suite of
headers.  Personally I think that with a variety of ways of marking
scores (or in fact even having the concept of a "score"), it would be
hard to specify the a particular structure here.  Plus you might have
a message passing through multiple filters, each of which would want
to place its mark on the message without disturbing other such
marks (so you'd need a tuple of at least {agent, location, assessment}).

Anyway I don't mean to go off on details here.  I am interested should
it be discussed somewhere.

mm

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 17:11:23 -0500

Eric S. Raymond wrote:
> Right.  I ran up against this while designing bogofilter.  The syntax you
> want is something like this:
> 
> * Semicolon-separated fields
> 
> * Each field to consist of a agent@hostname:evaluation token
> 
> * the evaluation field to consist of comma-separated keyword=value
> 
> * The agent field should be versioned, so a real example should look like:
> 
>   [email-masked]:spam-probability=90%,forged_address=yes;

Would that mean that the MUAs have to be matched to the user agent of 
the filters of the MTA that they use? What about a spammer forging the 
header coming from the filter?

Yakov

-------

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 26 Nov 2003 17:00:35 -0500

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 26 Nov 2003 18:28:48 -0500

Yakov Shafranovich <[email-masked]>:
> the filters of the MTA that they use?

Not necessarily.  The actual goal is to allow you to keep a local reputation 
database of filters.

> What about a spammer forging the header coming from the filter?

Policy issue.  You may decide you only want to trust endorsements generated
locally, but the standard header would still be very useful even so.

Suppose for example, that I have a milter that extracts certain header
features indicative of forgery that would be invisible to an
exclusively token-oriented Bayesian filter.  Then what I'd want the milter
to do is say this:

Filtered-By: [email-masked]:bogus-trace=yes;

Then the Bayesian filter would be able to "see" the forgery.

Forging these reputation headers would be a criminal offense under CAN-SPAM.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 26 Nov 2003 19:05:09 -0500

> Forging these reputation headers would be a criminal offense under CAN-SPAM.

Would someone be willing to volunteer to write up an evaluation document 
following the checklist in the end of the following draft (section 6.1):

http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt

Yakov

-------