Subject: [Asrg] 6. Proposals - Legal - Subject labeling - FTC response

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 01 Dec 2003 16:42:41 -0500

Hi,

I received some feedback from the FTC today. As it stands right now, the 
FTC has only begun preliminary analysis of the bill. Since this 
particular report on filtering has an 18 months deadline, work has not 
begun on it yet. When the FTC begins working on this report, input from 
the IETF and the ASRG will be solicited.

Sincerely,
Yakov Shafranovich
Co-Chair, ASRG
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"All that is gold does not glitter" (J.R.R. Tolkien)
-------

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

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 1 Dec 2003 17:35:24 -0500

> the IETF and the ASRG will be solicited.

Good.  Then the right time to standards-track a labeling RFC is *now*,
so we'll have it in hand with a decent amount of community review when
FTC comes knocking.

This goal is not exclusive of other RFCs or findings.  The fact that
"input from the IETF and the ASRG will be solicited" means we MUST
have a constructive response in *addition* to whatever else we do, or
lose future influence on the interpretation and implementation of
CAN-SPAM.

I have a draft RFC, to which I've seen the following responses:

1. Several friendly corrections -- typo fixes, advice that I should 
   highlight the U.S. specificity of Can_SPAM, etc.  I take these as
   support.

2. A technical objection that the proposal needs to use a new header
   rather than Keywords.  Incorporated.

3. One misunderstanding about the scope of "commercial email" in CAN-SPAM
   and my draft.  This is the only objection that has produced even a threat
   of a competing draft.

4. Two objections (one from John Levine, one from somebody else) that we 
   shouldn't have a labeling system because we should be doing something 
   else instead.  As I've pointed out above, this is not responsive to the
   political reality of CAN-SPAM.

I've been through the RFC mill before.  This is a remarkably low level
or controversy, and very encouraging.

I'm volunteering to be the point guy on this.  The issue interests me, and my
public fame might turn out to be a useful tool when it comes time to talk
the FTC and Congress out of peeing in the proposal so they'll like the
flavor better.  We're at particular risk of that here because the issue
has little technical depth, increasing the risk that some bureacrat will
think he understands the background issues enough to "improve" an RFC.  (The
most likely attempted "improvement" will be a more elaborate classification
system.)

Let me reiterate that I do not view this effort as competitive with
any of the other proposals on the table (LMAP, callback, pull, MTA
labeling, whatever) but as complementary with them.

Those of you with interest in this issue, please work with me to
improve the draft.

What is the next step?  If I'm reading RFC2026 correctly, it would be 
publishing my proposal as an Internet-Draft with a view to having it
accepted as a Proposed Standard.

Is this a candidate BCP or TS?  I can see arguments in both directions.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 1 Dec 2003 18:00:12 -0500

> I have a draft RFC, to which I've seen the following responses:

Perhaps you could post the URL again for the latest rev?

mm

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 1 Dec 2003 18:07:02 -0500

> Perhaps you could post the URL again for the latest rev?

I haven't webbed it yet.  Here it is:

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 machine-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: [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.

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 01 Dec 2003 18:45:32 -0500

> I haven't webbed it yet.  Here it is:

This document has been added to the ASRG worksite at the following URL:

http://asrg.kavi.com/apps/group_public/download.php/17/draft-irtf-asrg-filtering-can-spam-00.txt

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> 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: Mon, 01 Dec 2003 18:52:26 -0500

> lose future influence on the interpretation and implementation of
[..]
> accepted as a Proposed Standard.

We can publish the draft as an Internet draft via the group, I will 
discuss that with John. The goal here would be to start a discussion on 
the issue. If a filtering subgroup is created, this will end up there 
probably.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
  "Why are both drug addicts and computer aficionados both called 
users?" (Clifford Stoll)
-------

---

From: Carl Malamud <[email-masked]>
Date: Mon, 1 Dec 2003 15:53:59 -0800 (PST)

> http://asrg.kavi.com/apps/group_public/download.php/17/draft-irtf-asrg-filtering-can-spam-00.txt

Hi Yakov -

A somewhat related document is draft-malamud-no-soliciting-02, which should be coming out
of the i-d queue adn.  Source for the current doc can always be found at:

	http://trusted.resource.org/no-solicit/

Regards,

Carl

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 1 Dec 2003 19:23:49 -0500

Carl Malamud <[email-masked]>:
> A somewhat related document is draft-malamud-no-soliciting-02, which
> should be coming out of the i-d queue adn.  Source for the current
> doc can always be found at:
> 

Hmmm.  Carl, should we be using the same class keywords, perhaps?  It would 
be a trivial change to my draft, as our categories are equivalent.

In fact, I see no good reason the "Sender-Keywords" header in my proposal
shouldn't become "Solicitation".  Then my proposal would simply become
a requirement that commercial email MUST be labeled with the same keywords
in a Solicitation header as are specified in your MTA-labeling draft.

This would unify your MTA-labeling proposal with our proposed recommendation to
the FTC on CAN-SPAM labeling in a nice way.  If and when both drafts become 
RFCs, they can use the same IANA registry for solicitation keywords.

In fact, this is so obviously the right thing that I'm going to go do it to
my draft right now.

I hope this will mean that advocates of MTA labeling and spam-labeling
standards can get behind these proposals and cooperate rather than treating
these alternatives as exclusive.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 01 Dec 2003 19:25:09 -0500

> these alternatives as exclusive.

Perhaps the two drafts should be merged together?

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Power tends to corrupt, and absolute power corrupts absolutely" (Lord 
Acton)
-------

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 1 Dec 2003 19:26:03 -0500

> the issue. If a filtering subgroup is created, this will end up there 

You may count on me to be cooperative.

I am about to fix my draft to be compatible with Carl Malamud's 
NO SOLICITING proposal.  The changes will be trivial.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Carl Malamud <[email-masked]>
Date: Mon, 1 Dec 2003 16:45:42 -0800 (PST)

Hi Eric -

I agree that the labels could share the same registry.  But, one of the
things I tried to do in my draft is let somebody else worry about
what the labels are and how they are defined.  It got bootstrapped
with three easy ones, but I'd sure like the FTC or somebody else
to worry about what these tokens really mean and who is
supposed to use them.  So, I'm not sure I'm comfortable
with language in an i-d or rfc like "Commercial electronic mail 
MUST be labeled".  Seems like that belongs in a law, not
a standard. 

Do you think we can, in a proposed standard, require certain
types of content to be labeled, or might we be better off simply
specifying a carrier mechanism that can be used and let somebody
else do the requiring?  Also, do you think asrg will reach
consensus in time to make a recommendation?  Those people
in DC sure have a lean and mean operation compared to ours.  :)

(BTW, I did both MTA protocol-level and header-level definitions
under the theory that even if you require a header, some
folks might forget to insert the label and, in that case,
perhaps an intermediate relay might step in to help
out via the trace fields ... in either case, the receiving
mua and the receiving mta's get to decide what to believe
and what to do with the message.)

Regards,

Carl

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 1 Dec 2003 19:54:14 -0500

> Perhaps the two drafts should be merged together?

I'm open to this possibility.  Actually the only considerations were
technical I'd do it in a heartbeat -- I have no ego investment in
being the only name at the top.  But the relevant question is actually
political -- and no, I don't mean IETF politics :-).

My draft is designed for a particular, narrow purpose -- to be the IETF's 
response to the request for IETF input on the labeling standard contemplated
in CAN-SPAM section 11.2.

Carl's draft addresses the same problem, but in a way that is
probably not under the remit given FTC by CAN-SPAM.  Therefore it
may be politically best to keep the two drafts separate, unless we're
going to try to sell the FTC on the theory CAN-SPAM gives it authority 
to make regulations bot only with respect to my draft but with 
respect to his.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 1 Dec 2003 20:28:43 -0500

> MUST be labeled".  Seems like that belongs in a law, not

I hear you.  And I think I've got the solution to your problem.  Or
*a* solution, anyhow.  You see, I didn't just pull those three labels
out of my butt -- they're the minimum set of categories required by
CAN-SPAM, which actually does a pretty good job of defining them.  My
draft refers their definition to CAN-SPAM, and thus to FTC as the
implementing regulatory authority.  There goes one of your problems. :-)

Remember that my draft is intended *specifically* as a response to the
section 11.2 language in CAN-SPAN that enjoins the IETF to develop a
labeling requirement in conformance with IETF standards; said labeling
requirement would have the force of law.  It's a happy coincidence
that it dovetails so exactly with your proposal, but that was not
my original intention.

So we're in an interesting gray area here.  We need to say MUST so our
recommendation to FTC will have the appropriate meaning in *legal*
and *political* terms.  You say "Seems like that belongs in a law, not
a standard." and you're right;  if the FTC doesn't reject the IETF's 
recommendation, we will in effect be writing law.

And I give it 60% odds the FTC will just adopt the draft whole,
because messing with it would require extra work.  The 40% chance is
that some FTC staffer or Congessman will get a bug up his butt about
other kinds of "bad" content and want to elaborate the keyword system.
In my Visualization of the Cosmic All, the most likely proposal for a
new keyword is DRUGS.

> else do the requiring? 

Mechanism-only would satisfy the IETF's traditional requirements, but
not the request we've had dropped on us by CAN-SPAM 11.2.

>                 Also, do you think asrg will reach

I think you just helped things along a whole hell of a lot, actually.
Your draft and my draft now reinforce each other, making it
politically more difficult to oppose either one without looking like a
spoiler.

I'll have some more comments on your draft off-list.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Richard Welty <[email-masked]>
Date: Mon, 1 Dec 2003 20:26:14 -0500 (EST)

> MUST be labeled".  Seems like that belongs in a law, not

if i might suggest, normally in the crypto groups, algorithms and their
labeling are generally separated out from the protocols. this allowed,
for example, AES to easily be added to the IPSec and SSH suites
w/o messing with the existing drafts. i would submit that labeling
should be a separate draft which can subsequently be supplemented
or superceeded.

having suggested it, i suppose i should also state that i'm willing
to pull this part out of the existing drafts to stand on its own.

richard
-- 
Richard Welty                                         [email-masked]
Averill Park Networking                                         518-573-7592
    Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 01 Dec 2003 20:49:29 -0500

> in CAN-SPAM section 11.2.

It seems to us that there is no further research possible within the 
scope of ASRG for this draft, considering its narrow focus. As it stands 
now, the proper forum for this discussion would probably be the IETF.

Therefore, what we would suggest, is to submit the draft to the IETF as 
a independent submission and then shift the discussion there. The proper 
forum for this discussion would either be the main IETF mailing list (as 
a starting point), or the ietf-822 mailing list 
(http://www.imc.org/ietf-822/index.html). If the IETF sends it back to 
us, then we can continue discussing it here.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
-------

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 02 Dec 2003 08:22:00 +0000

>
>
>
>A somewhat related document is draft-malamud-no-soliciting-02, found at:
>

The problem I have with the various NO-SOLICIT / NO-UCE proposals that have
been made over the years is that they seem to imply that a system /
recipient accepts UCE / solicitations *by* *default* unless it gives the
sender notice. And that a sender will assume it's doing nothing "wrong" if
it isn't given any such notice. It strikes me that this is completely
contrary to the direction of this group (and the law in many
jurisdictions). A recipient does not give implicit consent to any
communication by not expressly denying it, any more that I accept that you
can shoot me because I don't wear a T-shirt saying "No-Shooting".

This particular no-solicit proposal has been elaborated to produce a rather
coarse and inflexible recipient consent-expression system.

I'm sure that most contributors and the chairs would agree that:
1. Most email recipients do not believe that they implicitly consent to all
communications that they don't explicitly reject.
This group shouldn't support any proposal which goes against this in any
way.
2. Any consent expression system will need to be flexible and extensible if
it's to be useful.

Labelling the message (not the SMTP transaction) may be useful in enabling
enforcement of recipient (or system) policy. This is the kind of thing that
we're chartered to do, I believe.

--

---

From: "Eric S. Raymond" <[email-masked]>
Date: Tue, 2 Dec 2003 03:54:17 -0500

> can shoot me because I don't wear a T-shirt saying "No-Shooting".

Urgh.  Good point.

> we're chartered to do, I believe.

I've been working on it.

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 02 Dec 2003 10:39:22 +0000

> us, then we can continue discussing it here.

Surely Eric can submit it *independently* whenever he likes? He doesn't
need you to tell him to. Are you trying to say that further discussion by
the group won't be appreciated - that there's no way such a proposal would
get group support? Or perhaps support by the chairs is the issue, in that
support for labelling is seen as support for a particular law?

Maybe I've got this wrong, and I'm eager to be corrected - surely the
output of this group is going to be (in part) IDs recommended to the IETF
by the group.

How about if references to any particular "law", were removed? Would it
then be suitable matter for evaluation here and eventual recommendation to
the IETF by this group?

And if not, why not? 

I'd be grateful if the chairs could take the trouble to respond to this.

Thanks,

JK

--

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 02 Dec 2003 11:19:24 -0500

> support for labelling is seen as support for a particular law?

This draft addresses a very specific requirement. The goal of the group 
is to do research in different areas and present findings. This specific 
draft does not require research since the guidelines for it have already 
been defined, and especially considering that the law concentrates on 
subject labeling specifically, which does not have too many options.

Additionally, the goal of the draft is to be a response of the IETF on 
the issue. The formal body that is allowed to make such response would 
either be the IAB, the IESG or the IETF chair, not the IRTF. Therefore, 
it seems to us that this belongs on the IETF side, since this would be a 
policy issue that needs to be defined by them. We do not want to 
pre-empt their responsibilites, however if they choose to send it back 
to us, we'll be happy to look at it.

> output of this group is going to be (in part) IDs recommended to the IETF

Yes it is, but see my comments above. The IRTF's goal is to do research, 
anything that would be standards making or policy issues for the IETF, 
would go to the IETF.

> I'd be grateful if the chairs could take the trouble to respond to this.

It can be a suitable matter for evaluation if effectiveness can be 
shown. If the only way these schemes are effective is via law 
enforcement, that would not be a research topic for the ASRG unless we 
are asked to do so by another body: either the IETF or the FTC.

Yakov
-------

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 2 Dec 2003 11:26:14 -0500

> can shoot me because I don't wear a T-shirt saying "No-Shooting".

Hmm, that's exactly the point I made when Eric first submitted his
draft back on November 14.  Thus I agree :-)

-mm-

---

From: Carl Malamud <[email-masked]>
Date: Tue, 2 Dec 2003 08:27:00 -0800 (PST)

> that it dovetails so exactly with your proposal, but that was not

Hmmm ... I went back and look at section 111.2 of the bill.  I'm not
sure I read it as requiring any action by the IETF.  Section 111.2
merely says that any solution should conform to IETF standards,
e.g., RFCs 2822, 2821.

> recommendation, we will in effect be writing law.

But, I don't think we should do that.  We can specify protocol
mechanisms and even header fields as containers, but why not let the
legislators and the ftc do their labels themselves?  After all,
Korea or the EU or Bangladesh may very well have different labels.
I'd much specify a mechanism and let policy people make policy.

> not the request we've had dropped on us by CAN-SPAM 11.2.

Again, I don't see 111.2 as being a request to the IETF.  

I'm not saying you shouldn't publish your draft, I'm just highly
skeptical you'll reach the rough consensus watermark for
mandating the use of specific content labels.  

BTW, I was thinking about your comments and those by Jon about
no-soliciting generating implied consent (e.g., if I don't
have a no shooting shirt on you can shoot me).  I'm not sure
I agree.  With no trespassing signs, at least out here in the
forest where I live, the sign tells you not to go on a specific
piece of property.  But, if you see a driveway without a sign,
I'm not sure I'd go driving up the hill, even if I am wearing
my "no shooting" shirt.  :)  The point of my draft was a
"go away" sign, which didn't and shouldn't imply "come in" if no
sign is posted.

I'll try to make more clear in the next draft both the implied
consent issue and that the registry examples I specified are
merely illustrative ... I picked maps-ube as one of
the bootstraps because I thought that would make it very
clear that others should load the registry with content.

Regards,

Carl

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 2 Dec 2003 11:45:11 -0500

> piece of property.

Out in our neck of the woods one has to post no trespassing/
no hunting signs, else hunting is implicitly permitted.  But
that's really neither here nor there.  Personally I would like
something (perhaps in the introduction) saying that the mere
presence of this document is in no way to be taken as an endorsement
of opt-out unsolicited bulk email.

mm

---

From: Carl Malamud <[email-masked]>
Date: Tue, 2 Dec 2003 09:21:42 -0800 (PST)

That's doable.  Thanks for the suggestion.

---

From: "Eric S. Raymond" <[email-masked]>
Date: Tue, 2 Dec 2003 13:11:37 -0500

> I'd much specify a mechanism and let policy people make policy.

As I said in private mail, if that's what you want you should write
the draft that way.  The way it's worded now it looks like you're pushing the
MAPS-UBE definition, which is flawed in part 3.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Carl Malamud <[email-masked]>
Date: Tue, 2 Dec 2003 10:16:27 -0800 (PST)

> MAPS-UBE definition, which is flawed in part 3.

I think the draft is written that way: the registry holds labels and
people (e.g., the FTC) can register a label.  Users then choose which
flags to assert.

As an example, you could register your 3 keywords and a definition.

I'll try to make this point clearer.

Carl

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 02 Dec 2003 21:26:45 +0000

> subject labeling specifically, which does not have too many options.

It depends what you call research doesn't it? The group is chartered (among
other things) to "collectively propose and evaluate solutions".

> are asked to do so by another body: either the IETF or the FTC.

How we measure "effectiveness" has still to be determined (unless I'm
mistaken). But anyway, estimation of effectiveness is an element of, not a
prerequisite for, evaluation. So I'm afraid that this can't be right.

Of course, legal issues are indeed covered by the charter:
"... will not pursue research into legal issues of spam, OTHER THAN the
extent to which these issues affect, support, or constrain the technology."
(my capitals)
This is a instance where a technology and a "legal issue" are intimately
related and mutually supportive.

So, even though this proposal seems fairly well suited for evaluation by
the group - it's not to be allowed for political reasons (at this time).
I'm not knocking this - it's a valid position, and better for being
explicit.

In a sense of course, this proposal has already achieved quite a lot (not
just noise), whether or not it's put forward as an ID.

Thank you for taking the time to clarify,

JK

--

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 02 Dec 2003 21:34:40 +0000

> draft back on November 14.  Thus I agree :-)

Sorry, I missed that. Well done.

--

---

From: Matthew Elvey <[email-masked]>
Date: Sat, 06 Dec 2003 12:23:07 -0800

I believe that rough consensus exists:
We believe that the labeling requirement in S.877 will not result in 
significant sender compliance.
The reasons being that S.877 provides weak enforcement mechanisms for 
its labeling requirement - and that California tried a similar 
requirement for years and it had no notable positive effect. 

Based on the postings I've seen here and in other forums, the bill is 
unpopular among people who fight spam, despite its good points.
http://www.junkbusters.com/spams.html lists the following as not liking 
the bill:
Jason Catlett, President, Junkbusters Corp.
Jeff Chester, Executive Director, Center for Digital Democracy
Tom Geller, Secretary, SpamCon Foundation
Beth Givens, Director, Privacy Rights Clearing House
Ken McEldowney, Executive Director, Consumer Action
Scott Hazen Mueller, Chairman, CAUCE.org (Coalition Against Unsolicited 
Commercial Email)
Chris Murray, Legislative Counsel, Consumers Union
Gary Ruskin, Executive Director, Commercial Alert

The only counterargument I've seen is that the US isn't California (a 
really weak argument, especially given that CA is perhaps 1/4 of the US 
tech economy).
The following S.877 excerpt  is equally true with respect to labeling 
with 'States' meaning states of the world, not states of the union:
//

            / (11) Many States have enacted legislation intended to
            regulate or reduce unsolicited commercial electronic mail,
            but these statutes impose different standards and
            requirements. As a result, they do not appear to have been
            successful in addressing the problems associated with
            unsolicited commercial electronic mail, in part because,
            since an electronic mail address does not specify a
            geographic location, it can be extremely difficult for
            law-abiding businesses to know with which of these disparate
            statutes they are required to comply./ 

(Further comments interspersed below.)

On 12/1/2003 2:35 PM, Eric S. Raymond sent forth electrons to convey:

>We MUST have a constructive response in *addition* to whatever 
>else we do, or lose future influence on the interpretation 
>and implementation of CAN-SPAM.
>  
>
Yes, we do need to respond with a labeling standard.
Would a response that ALSO states that we believe the labeling 
requirement that the response standardizes will not result in 
significant compliance, and how it can be fixed, be constructive?  I 
think so.
Or do you believe we need to make it seem that we think this is a great 
bill?  I think the FTC thinks that this is a good bill; other than 
prohibiting using false claims that an unsolicited e-mail was solicited, 
and supporting consumer action, it's what they asked 
for:http://www.ftc.gov/opa/2003/07/spamtest.htm.

>I have a draft RFC, to which I've seen the following responses:
You didn't mention that I'd also made some suggestions, which I referred 
to Mon, 01 Dec 2003 12:36:51 -0800.
Here they are, rephrased/refined:
While providing a standard to which the law may require compliance, we 
must not provide it the appearance of any legitimacy or IETF stamp of 
approval.

I PROPOSE that the letter referred to above (Posted at 
http://www.junkbusters.com/spams.html) be the basis for a section of the 
draft. It's language that a bunch of respected folks have already agreed 
upon.  It hits the key points that need to be addressed very well. 
Others, some less key:  the labeling requirement in S.877 will not 
result in significant sender compliance, long arm provisions to make it 
apply to assets/spammers/advertisers outside the US but within reach of 
US law.
Let's not get into the individual items in that letter, at least for a 
few days.  Rather, let's confirm (or deny) a rough consensus on two issues:
1)True or false: the labeling requirement in S.877 will not result in 
significant sender compliance.
2)True or false: the labeling standard should speak of the bill's 
deficiencies and/or the IETF's non-approval/endorsement.

I don't think these have been discussed, I don't think the ASRG has 
exhausted its mandate on this topic; if this draft is being discussed on 
the ietf-822 or main list 
(http://www1.ietf.org/mail-archive/ietf/Current/maillist.html) I haven't 
seen it; wherever it's on topic, I'd like to see these discussed.

>   and my draft.  
>   [explained away as] CAN-SPAM's "CE" is your "UCE".
>  
>
Sorry. The definitions are more alike than I had believed. (S.877's 
definition is short and good enough, even if it isn't clear or wrong on 
some edge cases that, for example, http://mail-abuse.org/standard.html 
deals with.)
Still, it's not ideal that the draft uses a phrase that S.877 redefines 
to be something quite different from its plain language meaning.
The draft defines and uses "porn email" instead of using S.877's 
definition of /`sexually oriented material'/

>flavor better.  
Hope so; agreed; trying.

---

From: "Jon Kyme" <[email-masked]>
Date: Sun, 07 Dec 2003 10:15:10 +0000

> let's confirm (or deny) a rough consensus on two
> issues:

Not being a purely technical issue, there are considerations (attitudes of
regulators, law enforcement, courts, jurisdictions inhabited by spammers /
spammer operations relocatability, etc) which make this question difficult
to answer (except by considering those things).
So as a start: What proportion of spam can be reliably attributed to
operators based in the US (or any other particular state). How committed
are the (for instance) US regulators / law enforcement to prosecuting?
How easy is it for a spammer to relocate? 

> deficiencies and/or the IETF's non-approval/endorsement.

False. I'm not sure that it's wise to produce a technical document which
discusses the rights/wrongs of a particular bill (of a particular
jurisdiction). I'd be happier seeing a technical document referring to this
bill only as an *example* of the kind of legislation that a labelling
mechanism might support and discusses the strengths/weaknesses of the
mechanism proposed.

> exhausted its mandate on this topic; 

I agree.

--