On Friday 14 November 2003 15:05, you (ESR) wrote:
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?
I'm still trying to figure that out itself. The idea is stuck in my brain and
has raised the "attractive but incomplete" flag.
I think it all flows from my observation that spam lies entierly in the eye of
the beholder; what you would perceive as spam I might not, and vice versa.
While there are a few broad categories that most people would agree is spam
at all times, restricting the definition of spam to those-- or widening it
needlessly-- is harmful to anti-spam efforts in the long term.
So my idea is (please bear in mind that this has not yet matured):
"A sender is /not/ spamming if he sends a message with the justified
expectation that the recipients (however many) are not going to perceive the
message as spam."
This has nice properties. A mailing list maintainer is not spamming if he
took reasonable effort to insure subscriptions to his list are genuine (even
if some were falsified by some third party) because he is justified to expect
that the recipients wanted to receive the message and would perceive it as
spam.
Likewise, the sender of what we would call commercial spam cannot justify such
an expectation, regardless of how earnestly he beleives it is interesting,
simply by his overt admission (by anti-spam defeating measures part of his
message) that he does /does/ expect his recipients to consider his message
spam.
So, I'm thinking the right way to define spam is not about what the recipient
thinks is spam, but about what the *sender* beleives the recipients think is
spam.
I'm not being very clear, am I? That's what I meant about my idea not being
quite mature yet. :-)
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.
How about "Presumption of consent"?
+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.
I might make a finer distinction that "tumbler" might refer to a variant
segment whose /sole/ purpose appears to be uniqueness. Message IDs are more
properly serial numbers because they are used to associate the variant with a
specific message rather than simply differentiate it from the others. I have
once received a spam that, somehow, had not been expanded properly by the
mailer and there were instances of % expansion throughout, including a few
"%RANDOM_ALNUM(x)", so there is probably no association kept between the
individual tumbler values and the recipients.
The reason why I make a distinction in the first place is that there are other
sorts of unique IDs often imbedded in spam whose purpose seems likely to be
tracking the individual recipients (most often in image URLs so that an http
server gets to collect them without human interaction). I always presumed
those were meant to validate an email as "good" and thus increase its value.
Heh. Evil tought. Maybe one of us should write an otherwise good spam mass
mailer that tracks the *sender* by steganography in the tumblers (so it ends
up being /easier/ to blacklist them) and use the sales proceed to help
finance blacklists or the EFF.
I'm presuming spammers read this mailing list-- so this message is for you:
who knows, next time you buy one of your Tools of Evil, if that's not going
to be an undocumented feature? Ph34r the coder! :-)
-- Marc A. Pelletier
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg