Marc A. Pelletier <marc(_at_)ctrl-alt-del(_dot_)ca>:
On Friday 14 November 2003 11:36, Eric S. Raymond wrote:
1.3.5 Challenge/Response System (RCD)
+A challenge-response system is a technique that requires a mail sender
+to authenticate itself by computing and returning an acceptable
+response from a piece of data presented by the receiver.
+Challenge-response authentication may be used to demonstrate that
+the sender knows a shared secret qualifying it as one that has the
+receiver's consent, or that the sender has paid a toll in
+computational or other resources for the privilege of sending to
Perhaps also worth mentionning:
!the receiver, or possibly in other ways not anticipated here.
!the receiver, or that sending the message required interaction
+with a human being, or possibly in other ways not anticipated
+here.
Agreed. I consider this a friendly amendment.
+Most users implicitly consent to receive non-commercial communications
+from individuals, and implicitly withhold consent to receive
+unsolicited bulk email. Explicit consent to recieve solicited bulk
+email (e.g. mailing lists) is also common.
This finds itself paraphrased throughout the document, but I think it raises
the usual concern about the definition of spam in general. What about email
of a commercial nature but sent to one or many users with the reasonable
expectation that they will be interested? Or manualy sent email of a nature
where expectation of consent is unreasonable (Say, I pick the support email
of some pro-foo web site and email them anti-foo hate mail)?
That's why both "unsolicited" and "bulk" are important qualifiers in this
description of a standard policy. Your anti-foo hate mail has implicit
consent under the standard policy because, though it's unsolicited, it
is not bulk.
I'm *deliberately*, not accodentally, leaving the minor edge cases unspecified
here. If we overdefine the standard policy people will blow holes in it.
This sounds like a much more reasonable definition to me (minus the
paraphrase that follows). In fact, the whole "justified
expectation" concept sounds to be like a very valuable premisce when
trying to define spam in the first place. Perhaps we should spend
some brain cycles to refine it?
OK, what needs refining?
By the way, I didn't completely pull the concept of "justified
expectation" out of thin air. I'm interested in analytic philosophy,
and there is a notion from there that in order to be regarded as
knowledge a theory must not only be predictively correct, but be
*justified* -- that is, the theorizer must have causal grounds to
believe it that connects to his other knowledge.
1.3.8 Commercial E-mail (RCD)
+Commercial email is any electronic mail sent for the purpose of
+promoting a product, service or profit-making enterprise; or of
+soliciting a business relationship.
Yes, and that is part of my problem with the definition of spam as
we usually know it. If I send *one* email announcing my newfangled
foo-manufacturing-tool to a list of businesses or individuals that I
have collected from foo-manufacturing websites, I have a reasonable
expectation that they might be interrested. Indeed, I would doubt
that the recipients would feel the message /was/ spam unless they
started seeing multiple copies filling their inbox.
Fine, but we haven't gotten to talking about spam yet. Just commercial
email, not all of which (as you point out) is spam.
1.3.31 Spammer (RCD)
+A spammer is a person or organization that habitually sends spam, that
+is email for which the sender has no reasonable expectation that the
+targets will consent to recieve it.
I'd use "reasonable" or "justified" throughout. I would tend to prefer
justified, myself, but alternating is confusing if the indended meaning is
the same.
Fair point. I would be friendly to a change that used "justified" everywhere.
+Most users implicitly consent to
+receive non-commercial communications from individuals, and implicitly
+withhold consent to receive unsolicited bulk email; the justified
+expectation should be formed in light of this standard policy.
Again? :-) Even if we want to keep that definition of "default"
expectations, it should probably be in one place only; otherwise
they may get out of sync as we revise the document.
I thought of that. But I couldn't think of any obvious tag or term to put
that policy description under.
+1.3.38 Tumbler
Nice terminology. Adopted. :-)
Etymological note: I got this one from the old Xanadu hypertext
project. They used it for the unique IDs, analogous to URLs, in their
system. Using it for variant segments in spam is a bit original of
me. What both kinds of tumbler have in common is that their most
important characteristic is uniqueness rather than whatever is encoded
into them. I would also call an RFC822 message ID a tumbler.
2.4.1 Rational:
Rationale?
Not my error :-)
Otherwise all very nice, IMO, and a very good foundation on which to build.
Thanks. Put the quality down to all the practice I got maintaining the
Jargon File. (No, that's not a joke.)
--
<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