Discussion:
6. Proposals - Legal - Subject labeling - FTC response
(too old to reply)
Yakov Shafranovich
2003-12-01 21:42:41 UTC
Permalink
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)
-------
Eric S. Raymond
2003-12-01 22:35:24 UTC
Permalink
Post by Yakov Shafranovich
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.
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>
Mark E. Mallett
2003-12-01 23:00:12 UTC
Permalink
Perhaps you could post the URL again for the latest rev?

mm
Eric S. Raymond
2003-12-01 23:07:02 UTC
Permalink
Post by Mark E. Mallett
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: ***@thyrsus.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>
Yakov Shafranovich
2003-12-01 23:45:32 UTC
Permalink
Post by Mark E. Mallett
Perhaps you could post the URL again for the latest rev?
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)
-------
Carl Malamud
2003-12-01 23:53:59 UTC
Permalink
Post by Yakov Shafranovich
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
Eric S. Raymond
2003-12-02 00:23:49 UTC
Permalink
Post by Carl Malamud
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
http://trusted.resource.org/no-solicit/
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>
Yakov Shafranovich
2003-12-02 00:25:09 UTC
Permalink
Post by Eric S. Raymond
Post by Carl Malamud
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
http://trusted.resource.org/no-solicit/
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.
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)
-------
Eric S. Raymond
2003-12-02 00:54:14 UTC
Permalink
Post by Yakov Shafranovich
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>
Yakov Shafranovich
2003-12-02 01:49:29 UTC
Permalink
Post by Eric S. Raymond
Post by Yakov Shafranovich
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.
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"
-------
Jon Kyme
2003-12-02 10:39:22 UTC
Permalink
Post by Yakov Shafranovich
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.
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




--
Yakov Shafranovich
2003-12-02 16:19:24 UTC
Permalink
Post by Jon Kyme
Post by Yakov Shafranovich
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.
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?
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.
Post by Jon Kyme
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.
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.
Post by Jon Kyme
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.
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
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
-------
Jon Kyme
2003-12-02 21:26:45 UTC
Permalink
Post by Yakov Shafranovich
Post by Jon Kyme
Post by Yakov Shafranovich
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
Post by Jon Kyme
Post by Yakov Shafranovich
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
Post by Jon Kyme
Post by Yakov Shafranovich
forum for this discussion would either be the main IETF mailing list
(as
Post by Jon Kyme
Post by Yakov Shafranovich
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.
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
Post by Jon Kyme
the group won't be appreciated - that there's no way such a proposal
would
Post by Jon Kyme
get group support? Or perhaps support by the chairs is the issue, in
that
Post by Jon Kyme
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.
It depends what you call research doesn't it? The group is chartered (among
other things) to "collectively propose and evaluate solutions".
Post by Yakov Shafranovich
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.
Post by Jon Kyme
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
Post by Jon Kyme
by the group.
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.
Post by Jon Kyme
How about if references to any particular "law", were removed? Would it
then be suitable matter for evaluation here and eventual recommendation
to
Post by Jon Kyme
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.
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.
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







--
Carl Malamud
2003-12-02 00:45:42 UTC
Permalink
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
Post by Eric S. Raymond
Post by Carl Malamud
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
http://trusted.resource.org/no-solicit/
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>
Eric S. Raymond
2003-12-02 01:28:43 UTC
Permalink
Post by Carl Malamud
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.
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.
Post by Carl Malamud
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?
Mechanism-only would satisfy the IETF's traditional requirements, but
not the request we've had dropped on us by CAN-SPAM 11.2.
Post by Carl Malamud
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. :)
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>
Carl Malamud
2003-12-02 16:27:00 UTC
Permalink
Post by Eric S. Raymond
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.
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.
Post by Eric S. Raymond
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.
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.
Post by Eric S. Raymond
Mechanism-only would satisfy the IETF's traditional requirements, but
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
Mark E. Mallett
2003-12-02 16:45:11 UTC
Permalink
Post by Carl Malamud
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.
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
Carl Malamud
2003-12-02 17:21:42 UTC
Permalink
That's doable. Thanks for the suggestion.
Post by Mark E. Mallett
Post by Carl Malamud
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.
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
Eric S. Raymond
2003-12-02 18:11:37 UTC
Permalink
Post by Carl Malamud
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.
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>
Carl Malamud
2003-12-02 18:16:27 UTC
Permalink
Post by Eric S. Raymond
Post by Carl Malamud
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.
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.
--
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
Richard Welty
2003-12-02 01:26:14 UTC
Permalink
Post by Carl Malamud
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.
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 ***@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Jon Kyme
2003-12-02 08:22:00 UTC
Permalink
Post by Carl Malamud
http://trusted.resource.org/no-solicit/
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.







--
Eric S. Raymond
2003-12-02 08:54:17 UTC
Permalink
Post by Jon Kyme
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".
Urgh. Good point.
Post by Jon Kyme
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.
I've been working on it.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Mark E. Mallett
2003-12-02 16:26:14 UTC
Permalink
Post by Jon Kyme
Post by Carl Malamud
http://trusted.resource.org/no-solicit/
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".
Hmm, that's exactly the point I made when Eric first submitted his
draft back on November 14. Thus I agree :-)

-mm-
Jon Kyme
2003-12-02 21:34:40 UTC
Permalink
Post by Mark E. Mallett
Hmm, that's exactly the point I made when Eric first submitted his
draft back on November 14. Thus I agree :-)
-mm-
Sorry, I missed that. Well done.





--
Yakov Shafranovich
2003-12-01 23:52:26 UTC
Permalink
Post by Eric S. Raymond
Post by Yakov Shafranovich
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.
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.
[..]
Post by Eric S. Raymond
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.
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)
-------
Eric S. Raymond
2003-12-02 00:26:03 UTC
Permalink
Post by Yakov Shafranovich
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.
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>
Matthew Elvey
2003-12-06 20:23:07 UTC
Permalink
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.)
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.
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.
3. One misunderstanding about the scope of "commercial email" in CAN-SPAM
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'/
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.
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.
Hope so; agreed; trying.
Jon Kyme
2003-12-07 10:15:10 UTC
Permalink
Post by Matthew Elvey
let's confirm (or deny) a rough consensus on two
1)True or false: the labeling requirement in S.877 will not result in
significant sender compliance.
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?
Post by Matthew Elvey
2)True or false: the labeling standard should speak of the bill's
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.
Post by Matthew Elvey
I don't think these have been discussed, I don't think the ASRG has
exhausted its mandate on this topic;
I agree.





--

Brett Watson
2003-12-02 02:14:40 UTC
Permalink
Post by Richard Welty
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.
I heartily second that notion. Eric's draft makes a number of suggestions, of
which the content-tagging tokens are only a small part. It would be better if
the draft merely specified a *means* for those tokens to be incorporated, and
the tokens themselves were externalised.

Eric has already expressed the opinion that the tokens are the most likely
candidate for tweaking by the other Powers That Be, so it would be wise to
isolate them from the more technical aspects of the draft. This is also the
area most likely to be expanded upon by other lawmaking bodies or future
revisions to the law. If the Powers That Be are going to do any tweaking,
let's give them something obvious to tweak that won't result in any technical
brain damage.

Let the main draft specify "Solicitation:" (or whatever) as the standard means
of placing legally-required labels on a message, and define the labels
themselves in another document entirely. (You may want to define a *grammar*
for the labels in the main draft, but leave the actual vocabulary out of it.)

Regards,
TFBW
Richard Welty
2003-12-02 02:24:28 UTC
Permalink
Post by Brett Watson
Let the main draft specify "Solicitation:" (or whatever) as the standard means
of placing legally-required labels on a message, and define the labels
themselves in another document entirely. (You may want to define a *grammar*
for the labels in the main draft, but leave the actual vocabulary out of it.)
actually, i'd lean towards a doc on grammar and other generic labeling
details, and one with an actual set of labels, now that i think about it.

richard
--
Richard Welty ***@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
Eric S. Raymond
2003-12-02 02:40:45 UTC
Permalink
Post by Brett Watson
I heartily second that notion. Eric's draft makes a number of
suggestions, of which the content-tagging tokens are only a small
part. It would be better if the draft merely specified a *means* for
those tokens to be incorporated, and the tokens themselves were
externalised.
It's an appealing idea. But:

(1) Right now, the draft is a complete and self-contained response to
CAN-SPAM 11.2. I think it may be a bad idea tactically to split it
apart. Better to give the FTC one simple document when it comes time.

(2) The present vocabulary is not arbitrary, it is the categories
*required* by CAN-SPAM. So there's a case for any further vocabulary
extensions to be in a separate TS, but an equally strong case that these
belong in the base document.

(3) There's a coordination issue with Carl Malamud's NO-SOLICITATION
I-D. I've just changed my draft to spell the header and keywords the
exact same way he does.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Hallam-Baker, Phillip
2003-12-02 19:21:14 UTC
Permalink
Post by Carl Malamud
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.
In the light of this point and the points made by Yakov I suggest we proceed
as follows:

1) Send a note to the IAB telling them that we think that this is their tar
baby and that they should deal with it.

2) Attach to the note a >short< summary of the discusion on ASRG, viz

* Concerns were raised about the practical value of labelling which the
FTC can evaluate for itself in the light of their mandate from Congress.

* Responsibility for defining label terms and their use is properly the
domain of the FTC, the role of the IETF would appear to be limited to
defining the mechanism by which the labels are expressed.

* Various mechanisms for expressing labelling were discussed, these
include overloading the subject line, use of the keywords field, defining a
new header. The advantages of and objections to overloading the subject line
and defining a new header are largely self evident.

* The principal difficulty with use of keyword terms is the risk of
collision. This risk may be mitigated by defining some form of prefix scheme
analogous to the namespace scheme employed in XML. Keyword labels might be
encoded as USFTC:Spam or possibly IETF:Spam. It is likely that IANA
registration will be sufficient to avoid prefix collisions.


Given that we are not the IETF and given that we report through the IAB and
given that political philosophy is out of scope that would appear to be the
sum total of the discussion of the topic here that has relevance.

Phill
k***@icann.org
2003-12-03 07:41:04 UTC
Permalink
On Tue, Dec 02, 2003 at 11:21:14AM -0800, Hallam-Baker, Phillip wrote:
[...]
Post by Hallam-Baker, Phillip
* Responsibility for defining label terms and their use is properly the
domain of the FTC, the role of the IETF would appear to be limited to
defining the mechanism by which the labels are expressed.
The IETF is global, and the standards it develops are not restricted to
the US. While it is very tempting to simply use labels from CAN-SPAM,
what if the Chines Government (for example) produced similar laws, but
with different labels? (The US government has limited jurisdiction over
email that originates from China.)


[...]
Post by Hallam-Baker, Phillip
* The principal difficulty with use of keyword terms is the risk of
collision. This risk may be mitigated by defining some form of prefix scheme
analogous to the namespace scheme employed in XML. Keyword labels might be
encoded as USFTC:Spam or possibly IETF:Spam. It is likely that IANA
registration will be sufficient to avoid prefix collisions.
Perhaps, but there are other issues. The common case in an IANA
registry is that one or more "technical experts" are annointed to pass
on additions to the registry, but that doesn't seem appropriate here.
There is another possible model, that of the urn/uri registries, where
essentially anyone can register a schema, and obvious problems are
vetted via a mailing list of interested parties. It's not clear that's
appropriate, either.
Post by Hallam-Baker, Phillip
Given that we are not the IETF and given that we report through the IAB and
given that political philosophy is out of scope that would appear to be the
sum total of the discussion of the topic here that has relevance.
OK, but... the IANA registry being hinted at seems to me to have some
fairly unique characteristics, and it would probably be worth trying to
outline at least some possibilities of how the IANA would manage it.

Regards

Kent
--
Kent Crispin "Be good, and you will be
***@icann.org,***@songbird.com lonesome."
p: +1 310 823 9358 f: +1 310 823 8649 -- Mark Twain
Hallam-Baker, Phillip
2003-12-03 16:34:10 UTC
Permalink
Post by Hallam-Baker, Phillip
[...]
Post by Hallam-Baker, Phillip
* Responsibility for defining label terms and their use
is properly the
Post by Hallam-Baker, Phillip
domain of the FTC, the role of the IETF would appear to be
limited to
Post by Hallam-Baker, Phillip
defining the mechanism by which the labels are expressed.
The IETF is global, and the standards it develops are not
restricted to
the US. While it is very tempting to simply use labels from CAN-SPAM,
what if the Chines Government (for example) produced similar laws, but
with different labels? (The US government has limited
jurisdiction over email that originates from China.)
That is certainly possible. However there is a natural process that reduces
this type of proliferation. The terms defined comprise a shared vocabulary,
the use of those terms establishes an intersubjective understanding of the
terms. If you use a term that is outside that vocabulary and it cannot be
understood then it has no effect.

There are actually two issues here. First China might define different terms
with the same meaning. Second China might define different terms with a
completely different meaning. The IETF could only actually address the
first.

Clearly there is an advantage if the prefix choosen is neutral. China is
much less likely to attempt to define its own term in place of ietf:spam
than it would usftc:spam. But that does not change the fact that the actual
act of definition can be left to the FTC lawyers.


The proliferation issue is not as severe here as it is in other areas since
many spam filters use feedback and are thus capable of learning new terms
and assigning appropriate weights.
Post by Hallam-Baker, Phillip
Perhaps, but there are other issues. The common case in an IANA
registry is that one or more "technical experts" are annointed to pass
on additions to the registry, but that doesn't seem appropriate here.
There is another possible model, that of the urn/uri registries, where
essentially anyone can register a schema, and obvious problems are
vetted via a mailing list of interested parties. It's not
clear that's appropriate, either.
How do we know who should be the experts? Perhaps we could try strange women
lying about in ponds distributing swords?

I prefer the URI model, but I think for this particular case the value of
transporting the additional URI information required to disambiguate the
term is not justified by the benefit.
Post by Hallam-Baker, Phillip
Post by Hallam-Baker, Phillip
Given that we are not the IETF and given that we report
through the IAB and
Post by Hallam-Baker, Phillip
given that political philosophy is out of scope that would
appear to be the
Post by Hallam-Baker, Phillip
sum total of the discussion of the topic here that has relevance.
OK, but... the IANA registry being hinted at seems to me to have some
fairly unique characteristics, and it would probably be worth
trying to
outline at least some possibilities of how the IANA would manage it.
I don't think that an IANA registry is needed. People will avoid terms that
are already in use when they want to define new semantics.

Several hundred years ago the Academie Francaise was formed with the goal of
promoting French as the international language by means of Napoleon's
cannons and rigorously defining the meaning of each word in the French
language.

We can now see that this endeavor is a total failure, and not just because
of Waterloo. The Academie Francaise did not promote the growth of the French
language, it smothered it in beuracracy. Meanwhile English has been
successful as the International language for exactly the reasons French
failled, there is no central repository of 'experts' trying to control
things.


Phill
Continue reading on narkive:
Loading...