Subject: RE: [Asrg] 6. Proposals - Legal - Subject labeling; do-not-spam l ist; banners

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 1 Dec 2003 09:57:53 -0800

Eric writes

> You're ignoring the reality that if CAN-SPAM passes, there 
> *will* be a 
> spam-labeling standard.  The question is only whether it will 
> be a well-
> designed one or a badly-designed one.  If we "don't recommend", we'll
> get one designed by a bureaucrat --  or, worse, a 
> telemarketing lobbyist.

Eric is completely right about this. If you look into the legal issues it is
very easy to see why the bill has a labelling requirement. 

Labelling makes no sense in the context of technical enforcement. It makes a
great deal of sense if you are dealling with first ammendment issues and
enforcement.

> We are being given an open opportunity to design a labeling system
> that works well.  What bill have you ever heard of that actually
> *solicits IETF input*?  We must *not* *blow* *this*.  

It is pretty rare to see any requirement for consultation of any non-federal
agency other than the academy of sciences.

> Matthew:
> >   1. This was tried already in California, and failed abysmally. It
> >      won't be enforced or effective.
> 
> California ain't the Feds.

The California bill has only been signed a few months. It is far too soon to
know what effect it will have. At the FTC workshop the lawyers for the
states mostly stated that they were acting in order to spur federal action.

> >   4. It doesn't prohibit software whose purpose is creating 
> or sending
> >      email with FALSE OR MISLEADING TRANSMISSION INFORMATION.
> 
> Now *you're* being horribly naive.  Haven't you learned anything from
> the history of the DMCA, or for that matter the continued and
> horrifying abuses of drug- firearms-, and porn-possession laws?  Laws
> that criminalize the possession of things, rather that specific
> *behaviors*, are open invitations to abuse.

The possession of spam software is not illegal in itself but would provide
evidence supporting a case that a spamming act had been performed.

Design of a spam feature to allow evasion of a particlar countermeasure
might not be criminal in itself but conspiring with a spammer to create such
could be.

		Phill

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

---

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

Hallam-Baker, Phillip <[email-masked]>:
> > You're ignoring the reality that if CAN-SPAM passes, there *will* be a 
> > spam-labeling standard.  The question is only whether it will be a well-
> > get one designed by a bureaucrat --  or, worse, a telemarketing lobbyist.
> 

(I take it that "first ammendment issues and enforcement" should have read
"first amendment issues and law enforcement".)

We're all engineers here.  We like to think about technical solutions.  It
can be difficult for us, sometimes, to recognize when we are dealing with
constraints that are essentially political.  We also have a tendency to minimax
by deciding a single best strategy and discarding all others in order to
execute it most efficiently.

Politicians and lawyers don't think that way.  They have more of a tendency 
to throw lots of mud at the wall and see which bits stick.  Trust me on
this, I'm married to a lawyer and part-time politician.  Hell of a note
for an anarchist... :-)

Our engineer reflexes could really screw us up here if we're not careful.
We're exploring several categories of attack on the spam problem. There's 
considerable danger that proposals that are politically and operationally
viable will get lost in the noise of debate as we try to settle on a single
minimax that we evaluate in purely technical terms.

Here is my evaluation of the state of play:

1. Pull systems as a replacement for SMTP are a non-starter, if for no other
reason that the deployment problem is impossible.  Besides, the sponsors of
CAN-SPAM won't accept "scrap the email network and start over" as a response
from us -- it's not politically viable, we'd just blow our credibility.

2. We MUST develop a labeling standard.  Technical arguments that some
other approach (such as MTA labeling) would be better are beside the 
point.  We've been presented a political test -- having been asked for
input in the CAN-SPAM draft, can we come back with something that assists
the FTC and the legislators?  If we don't, (a) the labeling standard will
be written -- probably badly -- by somebody else, and (b) we'll blow
our credibility.

3. Hector Santos has a point about strict construction of the RFCs being.  That
point should not get lost in arguments about VRFY vs. LMAP.

4. LMAP seems neglected recently.  This is bad.  We're being distracted 
by stuff that (I think) is less important than putting an IETF stamp on
*some* LMAP design.  I have my own preferences but I'm not going to push
them here.  The point is we need to have a road forward.

Rather than try to settle on one minimax, I think we ought to be working 
towards at least three standards-track RFCs:

1. An LMAP standard.

2. A labeling standard.

3. An RFC supplementing RFC2821/RFC2822 describing things like VRFY
   requirements (if we choose that path) and MTA labeling (if we choose
   that path).

I have a draft RFC for labeling; I haven't seen any arguments with the
content of the draft, it's all metadiscussion of whether we should
have a labeling standard or do something else.  But there is no reason
for that to be an exclusive-or -- we need to have a labeling standard
ready to hand the FTC in case CAN-SPAM passes.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 1 Dec 2003 15:11:58 -0500

----- Original Message ----- 
From: "Eric S. Raymond" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>

> from us -- it's not politically viable, we'd just blow our credibility.

Hear, hear!    Lets keep in mind also that the premise we must work with is
adherence with the current standard which means backward compatibilty.

> be written -- probably badly -- by somebody else, and (b) we'll blow

From the developer perspective of the SMTP server,  I don't view this as a
technical issue to be dealt with at the SMTP level.   I view it as a
sysop/admin Option to be provided as part of the configuration that might
interface with with a POST-PROCESSING concept.  In other words, once the
DATA is received, the transaction is technically complete.

In our case, a HOOK at the DATA state is offered to run a 3rd party
mail-filtering process with rules defined by the sysop/admin.   The RFC
already gives us the ability to provide a rejection DATA response code (4xx,
5xx).  It discusses some examples dealing with header comformity but I
recall when we added the HOOK, there was many questions as to what responses
were applicable.   For example, in our case, our design concluded with the
possible responses:

                250  Message accepted for delivery.
                250  Message accepted, delivery pending
                4xx   Message rejected by mail filter. You may try again.
                5xx   Message rejected by mail filter

as 3rd party developers began to implement the hook,  it needed more
flexibility, so now the SMTP Data Hook offers a way to provided hook-defined
responses.

The RFC does indicate that SMTP servers make response code flexible.  So
this change complied with this recommendation.

How does it apply to LABELING?

In lieu of a protocol change, i.e, a new command:   SUBJECT: xxxxxxxx, to be
provided before the DATA stage, we are left with DATA analysis to perform
this function.

So a SMTP product can provide the sysop a configuration option:

            [CAN-SPAM TAGS]
            ADV:PORN=REJECT
            ADV:DRUGS=ACCEPT

etc.  But this will only with vendors modifying their SMTP software.

To make it work with legacy systems,  the DATA is accepted and handled by
NON-SMTP post mail processing methods.

So because of this, it is not really a SMTP protocol issue in my view.

> point should not get lost in arguments about VRFY vs. LMAP.

From a technical aspect, I strongly belive it is required.  But more
importantly, I envision legal issues if SMTP is enhanced in such a way that
systems DO begin to filter/block systems from delivering mail that
"mistakes" can occur (or NOT), but nonetheless, done so effectively that a
commercial spammer sues for tortious interference.  I know if I as was the
commercial spamming business sending in my view, legitimate spam, and your
software was blocking it,  I will be looking to sue someone.   With
CAN-SPAM,  it makes this possibility even stronger.

So the SMTP specification must make it VERY clear every possible functional
flow operation based on comformity of the specs.   I believe when it is all
said and done, it boils down to trusted clients with valid return addresses
with strict and specific guidelines on what is considered valid and when it
is considered valid.

> *some* LMAP design.

LMAP can help address it.  Anything that does more "checking" per se, will
work.  But it requires additional DNS administration which does not fit the
current SMTP frame work, hence it will not be immediately adopted.   Oh, I
can surely add support for it, but it doesn't help if others do not or are
slow to do so.

One improvement to LMAP can be to use the subdomain concept to provided LMAP
information. That way SMTP DNS operations do not need to change and keeps it
at 1 lookup,  for example:

         current:   mx1.whoever.com
         LMAP:    mx1.lmap.whoever.com

This way, all it will take at the SOFTWARE level is small change to check
for the lmap sub-domain.

I have no problem with this, but nothing is going to work unless the specs
are changed to allow for strict SMTP checking.

---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com

---

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

Hector Santos <[email-masked]>:
> From the developer perspective of the SMTP server, I don't view
> [labeling] as a technical issue to be dealt with at the SMTP level.

You're right.  It isn't.

---

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

Matthew Elvey <[email-masked]>:
> Eric, if your draft continues to offer a labeling scheme for CE instead 
> of UCE, I'm going to create a competing draft.

Unecessary.  My draft uses CAN-SPAM's definition of CE, which
explicitly excludes transactional and relationship email.  That is,
CAN-SPAM's "CE" is your "UCE".
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 01 Dec 2003 16:14:58 -0500

"Eric S. Raymond" <[email-masked]> wrote:
> 4. LMAP seems neglected recently.  This is bad.

  I've been busy, and the authors of the various related drafts have
resisted combining their proposals.  I hope to have more LMAP updates
in the future.

>   We're being distracted by stuff that (I think) is less important
> than putting an IETF stamp on *some* LMAP design.  I have my own
> preferences but I'm not going to push them here.  The point is we
> need to have a road forward.

  <shrug> There is significant opposition to doing *anything*; with
the excuse that the proposal (whatever it is) is not perfect, or will
cost too much to deploy, or that it hasn't been demonstrated to be
useful, etc.

  There is so much opposition to LMAP related solutions that I'm
skeptical if it (or any proposal) will ever be approved by anyone.
I'm still involved in ASRG, because I have the naive belief that we
can do *something* about the problem, other than sticking our
collective heads in the sand.

  Alan DeKok.

---

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

> collective heads in the sand.

We are trying to re-organize and move the group forward. While it may 
seem that no useful activity is going forth, we are working actively 
behind the scenes to make things happen. We are hoping to reorganize the 
group along the lines of a multiple subgroups, each focuses on a 
specific task, and consisting of a small number of a participants that 
can work effectively together away from the noise of the main list. We 
are also working on getting different industry players involved, so they 
can contribute. We also are working on setting up or figuring out a way 
on how to be able to evaluate proposals.

Please bear with us for some time as we try to move this forward.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"One who watches the wind will never sow, and one who keeps his eyes on 
the clouds will never reap" (Ecclesiastes 11:4)
-------

---

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

Yakov Shafranovich <[email-masked]>:
>  [...]                             We are hoping to reorganize the 

As should now be clear. I am volunteering to lead the labeling subgroup,
if there is one.

> Please bear with us for some time as we try to move this forward.

Sorry, my intention was not to add to your troubles.  I will cheerfully 
cooperate with the process.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Chris" <[email-masked]>
Date: Tue, 2 Dec 2003 10:24:34 +1030

> Please bear with us for some time as we try to move this forward.

Sorry Yakov I did not get this far before shooting off my "to poll or not to
poll"

I will wait to see what you shake out of the bushes first

Regards
Chris

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
> Shafranovich
> Sent: Tuesday, December 02, 2003 9:32 AM
> To: Alan DeKok
> Cc: [email-masked]
> Subject: Re: [Asrg] 0. General -- the state of play
>
>
> Alan DeKok wrote: