Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com>:
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.
(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>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg