Subject: [Asrg] 2. Legal - Last Call: 'A No Soliciting SMTP Service Extension' to Proposed Standard

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 27 Jan 2004 16:28:52 -0500

From the main IETF announce list.

----------------forwarded text-----------------------
To: IETF-Announce :;
Subject: Last Call: 'A No Soliciting SMTP Service Extension' to Proposed 
Standard
From: The IESG <[email-masked]>
Date: Mon, 26 Jan 2004 10:53:08 -0500
Reply-to: [email-masked]
Sender: [email-masked]

The IESG has received a request from an individual submitter to consider 
the
following document:

- 'A No Soliciting SMTP Service Extension '
    <draft-malamud-no-soliciting-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-02-23.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-malamud-no-soliciting-04.txt

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"But in this world nothing can be said to be certain, except death and 
taxes" (Benjamin Franklin)
-------

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

---

From: Philip Miller <[email-masked]>
Date: Tue, 27 Jan 2004 21:15:29 -0500

>    <draft-malamud-no-soliciting-04.txt> as a Proposed Standard

Promulgation of this document as an RFC would encode exactly what we tried 
to avoid with our consent framework: content-specific solutions that are 
open to definition wars, redefinition, and even worse, cross-border legal 
wrangling. It requires that senders, to be compliant with every possible 
national law, check their mail against each and every registered keyword.
I believe that the acceptance of this proposal would be harmful to the 
operation of the global mail transport system. However, I want to hear some 
other opinions before submitting my comments to the IETF.

Also, should we, as a group, submit a collective opinion, which may carry 
more weight than just our individual statements?

Philip Miller

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 27 Jan 2004 21:38:38 -0500

Philip Miller wrote:
> Promulgation of this document as an RFC would encode exactly what we 
> tried to avoid with our consent framework: content-specific solutions 
> that are open to definition wars, redefinition, and even worse, 
> cross-border legal wrangling. It requires that senders, to be compliant 
> with every possible national law, check their mail against each and 
> every registered keyword.
> operation of the global mail transport system. However, I want to hear 
> some other opinions before submitting my comments to the IETF.
> 
> Also, should we, as a group, submit a collective opinion, which may 
> carry more weight than just our individual statements?

The current draft sets out that IESG or IANA should appoint a designated 
expert to do these. This may provide some oversight. However, another 
problem is that people might use it without going through the registry 
and use that as a basis for a lawsuit anyway.

There is also another issue of exchanging policy information between 
sending and receiving MTAs, which is related to what SPF is trying to do 
as well with extensibility.

In any case, it would be useful to hear what the author has to say to these.

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: John Levine <[email-masked]>
Date: 28 Jan 2004 04:40:56 -0000

>cross-border legal wrangling.

The CAN SPAM act, already in effect in the US, tells the FTC to study
both spam tagging and a do-not-spam list.  This gives them advice on
the least bad way to do those things, avoiding both junk added to mail
headers and a centralized list of people who don't want spam.

> It requires that senders, to be compliant with every possible

The alternative is for each country to make up its own rules, many of
which will likely contradict each other.  For example, Korean law says
that the subject line in spam has to start with the Korean word for
advertisement, while the US rule will probably be for ADV: or ADV:ADLT
at the beginning of the subject line.  The same subject line can't
simultaneously be in Korean and English.

> I believe that the acceptance of this proposal would be harmful to
> the operation of the global mail transport system.

If you think that the lack of a standard is going to keep governments
from passing laws, I think you greatly overestimate our influence.

I dislike the per-recipient stuff in Carl's draft, and based on some
discussions with him, I don't think he's all that crazy about it
either.  But if someone demands per-recipient granularity in spam
acceptance, that's how you'd do it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

---

From: Carl Malamud <[email-masked]>
Date: Tue, 27 Jan 2004 22:54:26 -0800 (PST)

Hi Yakov and Philip -

Let me take your comments in reverse order.

> as well with extensibility.

I've tried hard to keep this draft very focused on a simple mechanism
that allows a sender or an mta to assert keywords, a receiver to
assert keywords, and a registry to keep track of keywords.

I agree it could, in a sense conflict with potential future solutions.
But, the hope is that the extension meets the "probably won't hurt,
might help" criteria of protocol design.  So, if SPF does something
in this area, perhaps they could use this mechanism as a partial
transport or perhaps just ignore it.  I don't see how it could hurt.

> and use that as a basis for a lawsuit anyway.

Well, if I were the designated expert (and, believe me, I'd rather not),
I'd set up the registry using some neutral algorithm.  For example,
if you have a verifiable email address, a verifiable reference
URI, then keywords are allocated on a first-come, first-serve basis.
As to using a keyword not in the registry, then suing [iana, ietf,
recipient, sender]?  I'm not sure I get that one.

> > every registered keyword.

No, no, no.  :)  The draft provides a mechanism for the transport
of solicitation class keywords.  It does not say when a message is
accepted or rejected, or when to send it, or anything else having
to do with consent.  If you want to assert a keyword (or are required
to by a license agreement or other governing document), this is,
imho, a much better mechanism than inserting them into subject
headers, non-standard headers, or other mechanisms.

> > carry more weight than just our individual statements?

I would recommend against that course of action.  ;)  Seriously,
why would the asrg take a group position on this?  If you don't
like the draft, send the iesg a note and explain why.

(I'd highly recommend a look at the ietf-smtp list, where it appears
to me there is at least a glimmer of possible consensus.)

Regards,

Carl

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 28 Jan 2004 06:45:22 -0800

The legal standard you are trying to achieve here is constructive notice.

IANAL but I have spent a considerable time with lawyers and the
International Chamber of Commerce (ICC) tring to establish an international
registry for notice documents such as would achieve constructive notice. It
is a very hard problem.

Instead I would suggest that you abandon the keyword approach entirely and
use a referential mechanism based on URIs alone. It is not necessary for the
mechanism to guarantee that the end user achieve constructive notice
acceptable to a court of relevant jurisdiction, it is merely necessary to
give the user the ability to achieve it.

The best way to achieve constructive notice would be to use a URI that was
a-priori bound to a mechanism that ensured that the name could be resolved
to a unique document, i.e. a URN. This is actually quite difficult in
practice since there are not many URN sequences that are established in a
manner that would be likely to be considered notice. The IETF document
sequence is arguably one such sequence.

A more practical alternative would be to register the policy document with a
third party who made some undertaking to make the document available for
reading at any time, track modifications to the document, etc.

		Phill

---

From: wayne <[email-masked]>
Date: Wed, 28 Jan 2004 07:37:42 -0600

> assert keywords, and a registry to keep track of keywords.

I confess that I haven't read the draft *real* closely, but can't a
spammer just avoid seeing the "no solicitations" sign by using HELO
instead of EHLO?

-wayne

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 28 Jan 2004 17:22:01 +0000

On Jan 27, 10:54pm, Carl Malamud wrote:
}
} > Philip Miller wrote:
} > > 
} > > It requires that senders, to be compliant 
} > > with every possible national law, check their mail against each and 
} > > every registered keyword.
} 
} No, no, no.  :)  The draft provides a mechanism for the transport
} of solicitation class keywords.  It does not say when a message is
} accepted or rejected, or when to send it, or anything else having
} to do with consent.  If you want to assert a keyword (or are required
} to by a license agreement or other governing document), this is,
} imho, a much better mechanism than inserting them into subject
} headers, non-standard headers, or other mechanisms.

On Jan 28,  6:45am, Hallam-Baker, Phillip wrote:
}
} The legal standard you are trying to achieve here is constructive notice.

On Jan 28,  7:37am, wayne wrote:
} 
} I confess that I haven't read the draft *real* closely, but can't a
} spammer just avoid seeing the "no solicitations" sign by using HELO
} instead of EHLO?

I have a related question/concern.

Suppose that this draft is published as a (proposed) standard.

Suppose further that the FTC actually does adopt it as the labeling
mechanism for commercial email.

Doesn't that effectively legislate that everyone who wishes to send
commercial email in any capacity, must immediately upgrade their mail
servers to something that supports ESMTP including this extension?

In which case, why propose it as an extension at all?  It's effectively
scrapping the existing email system anyway; if you're going to legislate
that the infrastructure must be upgraded, you might as well choose a
better target for the end result of the upgrade.

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 28 Jan 2004 11:31:21 -0500

> Let me take your comments in reverse order.

Thanks for the quick response!

> transport or perhaps just ignore it.  I don't see how it could hurt.

I have no problems with your specific draft, rather I am afraid of it 
being overloaded and used for things other than solicitions and more as 
a generic policy mechanism. It would be helpful if the IANA registry 
guidelines are restricted to only "solicition" stuff, and nothing else.

There are problems with policy expression mechanisms mainly from the 
design point, since this particular mechanism was intended for a 
specific purpose, overloading as a generic mechanism might not work so 
well. Therefore, it might be better to have a separate generic policy 
mechanism.

> URI, then keywords are allocated on a first-come, first-serve basis.

One possibility I was wondering about - what if Saudia Arabia wants to 
register a keyword for "ISLAMIC-conformant email" in order to censor? It 
would be highly recommended that the IANA registry operates under 
specific guidelines and restricts these keywords to "NO SOLICIT" stuff 
only, and not anything else. In any case, that would probably be up to 
the IESG.

> recipient, sender]?  I'm not sure I get that one.

The basic premise of this is to provide ability to pursue the spammers 
legally by giving them prior notice. Being that SMTP uses English and 
somewhat readable keywords, it is feasible that someone will use these 
to give notice with "semi" English keywords they made themselves, and 
then try to sue incoming emailers for not keeping them. And these "semi 
English" words maybe something else other than spam, although I am not 
sure if such lawsuit will ever be successful.

In any case, these are not technical issues but rather is social ones.

> headers, non-standard headers, or other mechanisms.

Nevertheless, this mechanism is intended for legal use as the draft 
describes:

"  The service extension allows a mail recipient to notify the sender
    that certain forms of electronic mail are not desired and thus gives
    policy makers a mechanism for requiring senders of such electronic
    mail to identify their missives any penalties for failure to do so.
"

The problem that Philip is pointing out is not relevant to the actual 
draft, rather to the idea behind it - the fact the multiple 
jurisdictions have multiple laws, and for emailers to comply with them 
would be complicated. But as John pointed out, there are many laws 
anyway today, and governments are passing even more. Having a single 
mechanism might or might not make things simpler.

> to me there is at least a glimmer of possible consensus.)

I would also recommend that whomever wants to submit comments on these, 
should do so to the IESG directly. Keep in mind, that if you mention 
that you are an ASRG member, nevertheless do not make it sound that you 
are speaking for the whole group.

Yakov

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I want to know G-d's thoughts... the rest are details" (Albert Einstein)
-------

---

From: Carl Malamud <[email-masked]>
Date: Wed, 28 Jan 2004 10:13:51 -0800 (PST)

> servers to something that supports ESMTP including this extension?

I'm not the ftc, I don't sit in congress, and I don't enforce an aup
policy for an isp.  But, if I were, I might say:

1. If you send any unsolicited bulk mail in class x, you must use
a solicitation: header.

2. If you do more than x messages per year, you must also use
esmtp and the no-soliciting extension.

> better target for the end result of the upgrade.

Well, esmtp is pretty widely deployed and the effort to do a
simple extension like this is far from the effort to do an ng solution.
I think ng is the right answer, I just don't know what it is.  :))

Even if the sender does not use esmtp, this extension might be quite
helpful once it has reached your own mail processing system: as a 
customer, you might be running several dozen mail servers and if 
those all speak esmtp, this facility might be useful.

Don't forget: my draft does not specify who has to use it or 
how recipients should act when presented with various keywords.
This is simply a way for senders, mtas, and recipients to
assert keywords using a common mechanism.

Regards,

Carl

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 28 Jan 2004 18:23:15 +0000

On Jan 28, 10:13am, Carl Malamud wrote:
}
} I'm not the ftc, I don't sit in congress, and I don't enforce an aup
} policy for an isp.  But, if I were, I might say:
} 
} 1. If you send any unsolicited bulk mail in class x, you must use
} a solicitation: header.
} 
} 2. If you do more than x messages per year, you must also use
} esmtp and the no-soliciting extension.

Unfortunately the federal legislation doesn't mention or define "bulk",
only "commercial", so I'm not sure that the FTC has enough leeway to
limit the labeling requirements only to large-volume senders.

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 28 Jan 2004 13:25:00 -0500

> assert keywords using a common mechanism.

Carl,

This is part that actually worries me more than anything else. Can you 
explain what is the exact scope of this mechanism? If it is generic, 
than it should be stated so, otherwise, the scope of it including the 
operations of the IANA registry, should be narrowed.

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: Carl Malamud <[email-masked]>
Date: Wed, 28 Jan 2004 14:33:24 -0800 (PST)

> operations of the IANA registry, should be narrowed.

Well, the scope is pretty narrow now: solicitation class keywords.
The i-d gives guidance on the puropse, and a designated expert is
recommended to develop any further policies.

I really think it is wise to spec out the fewest things that
are absolutely necessary.  Do we really need to go further?  I'm
not sure how anybody reading the draft could be confused into
thinking this is a more generic, multi-purpose mechanism and
the combination of registration in a registry and the
strong recommendation that documentation of the registry 
be in the form of an rfc gives it significant inertia.

Regards,

Carl

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 28 Jan 2004 18:43:25 -0500

> be in the form of an rfc gives it significant inertia.

Thank you for the clarification.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"All that is gold does not glitter" (LOTR)
-------