Subject: [Asrg] Propposed additions and changes for draft-irtf-asrg-requirements

From: "Eric S. Raymond" <[email-masked]>
Date: Fri, 14 Nov 2003 11:36:45 -0500

--- draft-irtf-asrg-requirements-00.txt	2003/11/14 14:57:05	1.1
+++ draft-irtf-asrg-requirements-00.txt	2003/11/14 16:36:28
@@ -278,18 +278,73 @@
 
 1.3.1     Anti-spam (Requires consensus definition - RCD)
 
+An anti-spam technique is any method which assists in the suppression
+or rejection of unsolicited bulk email.  Such techniques include, but
+are not limited to: methods for mail-sender identification and
+authentication; content-based spam recognition; graylisting;
+challenge-response systems; hash-cash and other methods for imposing
+transmission costs on senders.
+
 1.3.2     Bulk E-mail (RCD)
 
+Bulk email is email sent in volume, as duplicates or near-duplicates
+distinguished only by tumblers.  Fewer than a dozen recipients is not
+generally considered bulk volume; more than fifty generally is.  In
+between is a gray area, which however is seldom relevant to anti-spam
+efforts as they are generally concerned with stopping unsolicited bulk
+mailings of much higher volume (e.g. in the thousands or millions).
+Bulk mail may be solicited (as when people join a mailing list and
+thereby consent to receive it) or unsolicited.
+
 1.3.3     Caller (RCD)
 
 1.3.4     Callback (RCD)
 
 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
+the receiver, or possibly in other ways not anticipated here.
+
 1.3.6     Consent (RCD)
 
+An email user explicitly consents to receive mail when he or she records with
+a potential sender or sender's agent a willingness to receive mail from 
+that sender meeting a specified range of topic or content criteria.
+Consent is a credential given to the sender but owned by the
+consenting party, and may be withdrawn.  
+
+An email user may also implicitly consent to receive mail by allowing
+certain categories of mail from senders with which no explicit consent
+has been registered.  The key point about both kinds of consent is
+that they may be withdrawn.
+
+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.
+
 1.3.7     Consent Based Communications (RCD)
 
+A consent-based communications system is one in which receivers may
+set and enforce a policy on what communications they wish to have
+sent to them in order not to be overwhelmed by unsolicited and unwelcome
+commmunications.  The premise of consent-based systems is that the
+user may withdraw consent, at which point senders have an affirmative
+duty to respect the user's wishes and the system may enforce upon
+them an inability to send to that user.
+
+An individual consent-bassed communication is one for which the sender
+has a justified expectation of consent by the receiver.  Most users
+implicitly consent to receive non-commercial communications from
+individuals, and implicitly withhold consent to receive bulk
+commercial email; the justified expectation should be formed in light
+of this standard policy.
 
 Williams              Expires:   April 2, 2003            [Page 5] 
 Internet-Draft            Requirements          October  2, 2003
@@ -297,6 +352,10 @@
 
 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.
+
 1.3.9     Domain Name System (DNS)
 
  A system for associating character based names with 
@@ -334,6 +393,9 @@
 
 1.3.13    Legitimate Messaging (RCD)
 
+Legitimate messaging is that for which the sender has the explicit or
+implicit consent of the sender.  
+
 1.3.14    Message Content
 
  That part of a messaging transaction that contains data as
@@ -342,6 +404,14 @@
 
 1.3.15    Message Envelope Forgery (RCD)
 
+Message envelope forgery occurs when a sending program misidentifies
+the sender during the email protocol transaction from the receiver.
+It may be, and often is, combined with message header forgery; both
+are common traits of spam.  The usual purpose of such forgery is to
+fool the receiver into thinking the message comes from a sender with
+good reputation (e.g.  not a criminal or habitual spammer) so that it
+will not be rejected before it is read.
+
 1.3.16    Message Envelope Protocol
 
  The protocol used during message transfer to insert message
@@ -363,6 +433,14 @@
 
 1.3.18    Message Header Forgery (RCD)
 
+Message header forgery occurs when a sending program misidentifies the
+sender in the RFC822 or RFC2822 mail headers.  It may be, and often
+is, combined with message envelope forgery; both are common traits of
+spam.  The usual purpose of header forgery is to fool the receiver into
+thinking the message comes from a sender with good reputation (e.g.
+not a criminal or habitual spammer) so that it will not be rejected
+before it is read.
+
 1.3.19    Message Origination
 
  The process of inserting an original or revised message into
@@ -424,6 +502,13 @@
 
 1.3.25    Non Consent Based Communication (spam) (RCD)
 
+A non-consent-based communicatoon (idiomatically, spam) is one for
+which the sender does not have a justified expectation that the target
+will consent to receive it. 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.
+
 1.3.26    Open Relay MTA
 
  An MTA which is configured to relay mail for local domains and
@@ -434,8 +519,22 @@
  
 1.3.27    Opt-In (RCD)
 
+An opt-in mailing list is one which reqires an explicit consent or
+sign-up before the user will be sent mail.  All legitimate mailing
+lists are of this type.
+
 1.3.28    Opt-Out (RCD)
 
+An opt-out mailing list is one for which target addresses are
+collected by the sender or some third party, and from which recipient
+may in theory withdraw by explicit withdrawal of consent.  In
+practice, so many operators of so-called "opt-out" lists ignore 
+attempt to opt out -- and (worse) use the addresses opt-out requests as 
+targets in other spam lists -- that most mail users will no longer
+touch an opt-out button.  Because of this trap, opt-out lists have
+come to be considered a spam technique and their operators presumptive
+spammers.
+
 1.3.29    Recipient/Receiver
 
  A computer system, application or process that is the final,
@@ -456,6 +555,13 @@
 
 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. 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.
+
 1.3.32    Relay MTA
 
  An MTA configured to participate in a store-and-forward 
@@ -498,7 +604,25 @@
 
 1.3.36    Unsolicited Bulk E-Mail (RCD)
 
-1.3.37    Unsolicited Commercial E-Mail (RCD)
+Unsolicited bulk email is bulk email for which the sender does not
+have a prior indication of consent from the targets.  This category 
+almost coincides with spam and is generally considered the most
+serious kind of spam.
+
+1.3.37 Unsolicited Commercial E-Mail (RCD)
+
+Unsolicited bulk email is commercial email (whether bulk or not) for
+which the sender does not have a prior indication of consent from the
+targets. 
+
+1.3.38    Tumbler
+
+A tumbler is a section of text inserted in instances of bulk email
+(often in the Subject header) which varies between instances in a 
+way irrelevant to the semantic content of the message.  Spammers use
+tumblers to defeat spam-recognition methods based on exact hashing and
+to dilute the effectiveness of Bayesian and other content-based spam
+recognition techniques.
 
 1.4  Anti Spam Technical Framework
  
@@ -607,11 +731,11 @@
 
 2.4.1     Rational:
  
- Any solution to the problems with spam should be easily
+ Any solution to the problems with 'spam' should be easily
  deployed to facilitate either incremental or wide-spread
  adoption.  Existing systems will likely continue to be used,
- thus a solution that leverages existing technology or MTS anti-
- spam implementations will also speed introduction.  A proposal
+ thus a solution that leverages existing technology or MTS 'anti-
+ spam' implementations will also speed introduction.  A proposal
  that relies on non-existent infrastructure or technology is not
  likely to be deployed.
 
@@ -789,7 +913,7 @@
  
  One of the most pernicious issues involving [spam] are related
  to accountability of the [spammers] who provide invalid or
- simulated information in order to game the system provided by
+ simulated information in order to "game the system" provided by
  the current MTS.  Designers MUST describe the issues of
  accountability addressed by their proposal.  Message
  origination and message formatting forgery must be considered
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The possession of arms by the people is the ultimate warrant
that government governs only with the consent of the governed.
        -- Jeff Snyder

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

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 14 Nov 2003 12:47:31 -0500

> +++ draft-irtf-asrg-requirements-00.txt	2003/11/14 16:36:28

Very nice stuff.  A couple comments and minor nits..

> +them an inability to send to that user.

I would worry that that text could be read differently depending on
one's frame of mind.  It could be read as a justification for opt-out
spam.  Perhaps change "wish to have sent" to "allow to have sent"; and
mention something about the default consent state (i.e., the default is
"non-consent").  Otherwise it looks like later withdrawal is the
default.  I realize that the following paragraph does address that a
little, but the above appears to give a complete definition of the
"premise of consent-based systems" as one in which the user can withdraw
consent.  Perhaps "A premise" or "Part of.."

> +An individual consent-bassed communication is one for which the sender

based

> +which the sender does not have a prior indication of consent from the

The text does not flow from the heading.  Seems like it should be
"Unsolicited Commercial E-Mail is email (whether bulk or not)"...

> +1.3.38    Tumbler

Interesting term.

>  2.4.1     Rational:

Rationale

>   One of the most pernicious issues involving [spam] are related

is related

mm

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 14 Nov 2003 12:46:14 -0500

I forwarded the comments to Eric Williams who is the author of the 
requirements document. Thank you very much for your comments.

Also, just a friendly reminder to follow the mailing list guidelines, it 
makes things easier to follow on a large volume list such as this one 
(guidelines are at 
http://www.irtf.org/asrg/asrg_mailing_list_information.htm).

Yakov

> +++ draft-irtf-asrg-requirements-00.txt	2003/11/14 16:36:28

<snip>

---

From: "Marc A. Pelletier" <[email-masked]>
Date: Fri, 14 Nov 2003 19:13:56 -0500

> +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.

I'm thinking schemes where (part of) the challenge is an hard-to-ocr
image, the contents of which need to be part of the response.  A
scheme which is in increasingly common use on web sites to avoid
automated form submission but that I've yet to see used for
email C/R.

> +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)?

All that to say that...

> +has a justified expectation of consent by the receiver.

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?

> +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.

If I collect the email from a foo-related newsgroup, say, then my "justified 
expectation" is more tenuous.  It vanishes entirely if I buy a mailing list 
or spider randomly for emails from the web.

> +expectation should be formed in light of this standard policy.

I'd just drop the bit about "most users".  I'm not sure it's helpful and it 
tends to partition spam into classes, which has always caused problems.

> +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.

> +Most users implicitly consent to

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.

> +1.3.38    Tumbler

Nice terminology.  Adopted.  :-)

>  2.4.1     Rational:

Rationale?

Otherwise all very nice, IMO, and a very good foundation on which to build.

-- Marc A. Pelletier

---

From: "Eric S. Raymond" <[email-masked]>
Date: Fri, 14 Nov 2003 15:05:41 -0500

> +with a human being, or possibly in other ways not anticipated

Agreed.  I consider this a friendly amendment.
 
> 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.

> 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.

> justified, myself, but alternating is confusing if the indended meaning is 

Fair point.  I would be friendly to a change that used "justified" everywhere.
 
> 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.

> 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.

> 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>

---

From: "Marc A. Pelletier" <[email-masked]>
Date: Sun, 16 Nov 2003 00:03:00 -0500

> > some brain cycles to refine it?

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.  :-)

> that policy description under.

How about "Presumption of consent"?

> 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

---

From: "Marc A. Pelletier" <[email-masked]>
Date: Mon, 17 Nov 2003 23:43:13 -0500

On Sunday 16 November 2003 11:21, you (ESR) wrote:
> > expectation that the recipients (however many) are not going to perceive
> > the message as spam."
>
> Interesting idea, but that double negaive is confusing and has to go.

Grammatically, yes, but I'd be loathe to reverse the sense of the statement.  
If we were trying to draft a legal document (which I realise we're not) this 
would be an 'active defense'; we're not saying what spam is, but we're 
allowing one way to determine what isn't.

"A sender is spamming if he sends a message without the justified
expectation that the recipients (however many) are not going to perceive
the message as spam."

How is that?  English is not my native language, so while I still perceive two 
negations it might still be grammatically sounder (and clearer)?

I'm a bit worried, though, because I think that also changes the meaning in a 
sublte and undesirable way; am I the only one to read that version as 
defining a restrictive metric for spam rather than defining a "this is not 
spam and here's why" defense?

Though if this is acceptable, it allows us to clean up the statement and take 
the sender out entierly:

"A message is spam if it was sent without the justified
expectation that the recipients (however many) are not going to perceive it as 
spam."

Stiill two negatives in there, though.  The problem is that "[...] was sent 
with the justified expectation [...] are going to perceive it as spam." 
doesn't mean the same thing at all even though the two negatives are 
reversed.

You are a considerably better wordcraft in english than I, so I appreciate 
your input on this.

-- Marc A. Pelletier

---

From: "Denny Figuerres" <[email-masked]>
Date: Mon, 17 Nov 2003 18:58:53 -0500

FWIW:  I think trying to "define spam" is a bit of a futile exersize as it
is based on context.
Here's a try at some way of stating it:

A message is SPAM when the recipients have no interest in reciving the
message 
and have not requested or authorized the sender to transmit such messages to
them.

Keys:  
A) did not ask for it.
B) do not want it.
C) has no "Value" to recipients.
D) sender generaly not known to recipients.

HTH

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Marc A. Pelletier
> Sent: Monday, November 17, 2003 11:43 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Asrg] 3. Requirements - Proposed Changes for Document
> 
> > > expectation that the recipients (however many) are not going to 
> > > perceive the message as spam."
> >
> If we were trying to draft a legal document (which I realise 
> we're not) this would be an 'active defense'; we're not 
> saying what spam is, but we're allowing one way to determine 
> what isn't.
> 
> "A sender is spamming if he sends a message without the 
> justified expectation that the recipients (however many) are 
> not going to perceive the message as spam."
> 
> How is that?  English is not my native language, so while I 
> still perceive two negations it might still be grammatically 
> sounder (and clearer)?
> 
> I'm a bit worried, though, because I think that also changes 
> the meaning in a sublte and undesirable way; am I the only 
> one to read that version as defining a restrictive metric for 
> spam rather than defining a "this is not spam and here's why" defense?
> 
> Though if this is acceptable, it allows us to clean up the 
> statement and take the sender out entierly:
> 
> expectation that the recipients (however many) are not going 
> to perceive it as spam."
> 
> Stiill two negatives in there, though.  The problem is that 
> "[...] was sent with the justified expectation [...] are 
> going to perceive it as spam." 
> doesn't mean the same thing at all even though the two 
> negatives are reversed.
> 
> You are a considerably better wordcraft in english than I, so 
> I appreciate your input on this.
> 
> -- Marc A. Pelletier
> 
>

---

From: "Marc A. Pelletier" <[email-masked]>
Date: Tue, 18 Nov 2003 00:24:06 -0500

>  FWIW:  I think trying to "define spam" is a bit of a futile exersize as it

And, indeed, that is one of the reasons I feel it is important to define it!  
Part of the problem is that there are, and will be, "punitive" measures taken 
against spammers.  Anyone can take some random message and claim it is spam 
then point an accusing finger at the sender.  Conflict ensues.

In fact, detractors of many blacklists point to this as a major problem, and I 
would tend to agree.

> and have not requested or authorized the sender to transmit such messages
> to them.
>
> Keys:
> A) did not ask for it.
> B) do not want it.

I'm trying to define spam in a way that /specifically/ excludes the 
recipient's opinion about a particular message.  A) and D) I think most 
everyone can agree on as minimal criterion for most sorts of spam, but B) and 
C) are strictly subjective, and thus subject for abuse.

For instance, if I have a web site about show dog breeding and someone mails 
me poodle breeding hints, the sender was justified in thinking I might not 
see it spam regardless of whether I think poodles are horrible little 
monsters or not.  Arguably the same for a dog breeding supplies 
advertisement.

That justification would doubtless vanish if it's penile enlagement herbal 
supplements.  So we're not talking about independence from contents, but 
about how I was chosen as a recipient.

In fact, if my address had been chosen (on purpose) from a website where I 
decry my despair at being unable to purchase all-natural herbal alternatives 
to viagra, the sender *would* be justified in sending me what we would all 
normally agree is spam on that topic.

> > -----Original Message-----

Please Oh Please Oh Please don't top-post!

-- Marc A. Pelletier

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 17 Nov 2003 20:17:38 -0500

> Please Oh Please Oh Please don't top-post!

Historically all discussions on the definition of spam in the group have 
not come to a fruitful conclusion. According to the technical 
considerations document, the term "unsolicited bulk email" is used as a 
working definition. See the following:
	http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt
http://www.opengroup.org/messaging/public/oct-2003/spam/shafranovich.pdf 
(sections 2.1-2.3)

Yakov

---

From: "Eric S. Raymond" <[email-masked]>
Date: Mon, 17 Nov 2003 20:30:45 -0500

> http://www.opengroup.org/messaging/public/oct-2003/spam/shafranovich.pdf 

In case there is any doubt in the matter, I am fully behind this definition and
have no desire to take us down terminological black holes.  My glossary-writing
was intended to support it, not dispute it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: [email-masked] (John R. Levine)
Date: 18 Nov 2003 08:29:05 -0000

> Historically all discussions on the definition of spam in the group
> have not come to a fruitful conclusion. According to the technical
> considerations document, the term "unsolicited bulk email" is used
> as a working definition.

Alow me to second that sentiment.  It's not very useful to talk about
dealing with spam since the definitions people use range from
"multiple substantially similar items of unsolicited commercial e-mail
sent to more than N people in less than M time" to "any mail I don't
want" and everyone knows that his definition is right and all the rest
miss the point.

Any anti-spam technical proposal should start by saying as
specifically as possible what abuse it's intended to prevent or
combat.  The various LMAP proposals, for example, appear to me to be
intended to detect forged domains in e-mail return addresses.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner
"More Wiener schnitzel, please", said Tom, revealingly.

-- 
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711
[email-masked], Village Trustee and Sewer Commissioner, http://iecc.com/johnl, 
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail

---

From: "Marc A. Pelletier" <[email-masked]>
Date: Tue, 18 Nov 2003 13:44:51 -0500

> want" and everyone knows that his definition is right and all the rest

*sigh*

Obviously, you people have been badly burned by flames on the topic before 
because you obviously did not read what I was saying at all before your knee 
jerked.  It's understandable, but /please/ take a moment of your time to 
consider what I'm saying.

The *point* of my exercise was to define spam in a way that makes it 
*independent* on what the recipients define as spam (and, indeed, the reason 
for trying to come up with a definition is the (to me) obvious impossibility 
of defining spam consistently between individuals).

While it is indeed unnecessary to define "spam" when examining a technical 
measure designed to alleviate a specific abuse of a communication 
infrastructure, it remains necessary to do so whenever we want to compare 
data points, quantify the problem, or even try to communicate amongst each 
other and/or the rest of the world.

And, wether you like it or not, we are defining spam both implicitly and 
explicitly by communicating here-- but in a manner which is ambiguous at best 
and contradictory at worse.  Indeed, vast tracts of the requirement document 
go about defining various sorts of spams simply because it attempts to 
discuss the general problem we are all here to try to solve.

It is useful to discuss specific kinds of messages likely to be perceived as 
spam when we are discussing specific measures (like, indeed, "unsollicited 
bulk commercial email") because they share common properties.  But I think 
that attempting to pegging the phenomenon of spam to any one such definition 
is dangerous because we then risk colouring our view.

My latest attempt is:

"A message is spam if it was sent without the justified expectation that the 
recipients (however many) are willing to receive it."

[for those of you keeping track-- you may notice I removed the double negative 
by making a leap of faith:  that a recipient is unwilling to receive messages 
he percieves as spam, and willing otherwise]

This holds interesting properties:

  - any message containing forged information or anti-anti-spam obfuscation 
becomes spam almost automatically [you cannot justify expecting the 
recipients are willing to receive something if you feel the need to include 
end-runs around measures designed to prevent reception!], but...

  - even if forged to try to ensure anonymity, a message sent by an individual 
to a recipient that is relevant is not spam [the omnipresent "human rights 
activist under an unfriendly governement trying to communicate with the 
press" counter-example]

  - messages sent to an harvested ("opt out") list become spam [you cannot 
justify expecting someone you know nothing about is willing to receive 
anything]

  - legitimate mailing lists are off the hook [expecting people who signed up 
for a mailing list are willing to receive the mailings is justified]

  - it's completely independent of the communication channel.  It covers SMS 
just as well as email.  Indeed, it would also properly classify a group of 
vickings drowning out your attempts to talk in a restaurant by loudly 
chanting.

At any rate, when I apply that definition to my own personal view of what spam 
is when it hits my mailbox, it matches 99% of the time-- and the rare piece 
of mail that doesn't can be argued to not having been /meant/ to be spam.  Do 
the exercise yourself.  When you receive something, ask yourself "did the 
sender have justified expectation I would be willing to receive this"?  I'm 
confident your answer will be "no" (almost?) all the time if the message fit 
your personal definition of spam and "yes" for all other messages.

My definition ends up being *completely useless* when trying to discuss 
technical measures to prevent spam, because it does not, and should not, 
define "justified expectation" and "willing" in any technically implementable 
manner (although consent-based communication is exactly trying to define 
both).  But is *is* useful when we want to discuss the general problem, or 
when we want to compare various classes of spam.

-- Marc A. Pelletier

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 18 Nov 2003 11:16:55 -0500

> intended to detect forged domains in e-mail return addresses.

  The various proposals, and the LMAP dicussion document define
exactly what problems they're trying to solve: forgery of names in
EHLO/HELO, and MAIL FROM.

  The worst cases of such forgeries (from a monetary view) are "joe
jobs", and the "please send us your account information" messages.
I'm hesitant to call them "spam", because the abuse of email is a side
effect of the underlying criminal behaviour: fraud.

  Other forgeries are caused by worms and viruses.  I'm also hesitant
to call these "spam", as the abuse of email is a side effect of the
underlying criminal behaviour: a desire to infect machines.

  Messages related to businesses asking people "please buy from me"
fall more obviously into the "spam" category, IMHO.  The LMAP related
proposals do nothing to prevent these messages, and the proposals are
not intended to prevent these messages.

  So to a large extent, the LMAP proposals don't deal with spam.  They
deal with preventing and/or tracking down criminal behaviour.

  Alan DeKok.

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 18 Nov 2003 16:41:24 +0000

Not meaning to presume on the role of the chairs...
It would probably be useful if those who haven't taken the trouble to read
the charter of this group - did so.

http://www.irtf.org/charters/asrg.html

It might also be instructive to check out the archives of this list.
Here's a good one:
http://www1.ietf.org/mail-archive/working-groups/asrg/current/msg07341.html

Spam definitions? No thanks. We have a "consent-based communication" model.
Spam is the other stuff :-)

Rgds,
JK

--

---

From: "Marc A. Pelletier" <[email-masked]>
Date: Tue, 18 Nov 2003 17:05:03 -0500

> http://www.irtf.org/charters/asrg.html

I have.  The charter simply notes the problem defining spam and punts on the 
problem.

> Spam is the other stuff :-)

Fair enough.  Established order has spoken and dissension is unwelcome.  The 
message is clear, and I will act accordingly.

-- Marc A. Pelletier

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 18 Nov 2003 18:59:14 +0000

> I have. The charter simply notes the problem defining spam and punts on

Exactly - it punts on the problem to the *recipient*, which is of course
where the decision should be made.

[snip]

> message is clear, and I will act accordingly.
Ooh - I've never thought of myself as the establishment before.
This question has been dealt with on a number of occasions (by the chairs
and others). The point is that we're not really here to talk about "spam",
we're here to talk about how one might enable recipients to deal with what
*they* call spam. This will (I'd guess)include considerations of what
recipients call spam, i.e. the definitions (emphasis on plural) that may be
used.

Regards,
JK

--

---

From: Mark Baugher <[email-masked]>
Date: Tue, 18 Nov 2003 11:57:56 -0800

>I have.  The charter simply notes the problem defining spam and punts on the

As far as charters go, the asrg charter looked pretty good to me when I 
first read it.  It still does.  Having written a few charters before, I 
think it sets the framework well for the work that is underway.

>message is clear, and I will act accordingly.

A group that revises its charter frequently is taking a random 
walk.  Unless there is something wrong with the direction of the group, I 
think asrg should deliver some of the work that is described on its charter 
before opening discussions on changing it.  That is what we did in the 
Secure Multicast Research Group when it became clear to most of us that the 
charter was too narrow.  We delivered secure multicast technology to the 
IETF and then re-chartered the secure multicast RG to become the group 
security RG.

Mark

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 18 Nov 2003 17:43:39 -0500

Marc A. Pelletier wrote:
<snip>
> recipients (however many) are willing to receive it."

The working defition of spam in the ASRG is stated in the technical 
considerations document 
(http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt):

<snip>
For most working discussions, the term "Unsolicited Bulk Email" is 
sufficient.
<snip>

Your definition is basically another way to say "unsolicited". If I do 
not want it, its another way to say that it was unsolicited. That is the 
point that the charter of the group is addressing - consent based 
communications arises from the concept of solicited and unsolicited 
email, or consent and non-consent.

The bulk aspect of email may or may not be relevant, depending whom you 
ask. The same technical considerations document states regarding bulk:

<snip>
The salient point that it  is a mass-mailing ensures that discussion 
covers the broadest concern of the user and provider communities. Mail 
that is not in some real sense "bulk" cannot flood networks or mailboxes.
<snip>

The "bulk" aspect of email is what causes problems to ISPs and other 
organization, while the unsolicited concept gives headaches to 
individual users.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 18 Nov 2003 17:49:11 -0500

<snip>
> message is clear, and I will act accordingly.

<grin>I did not think we became communist yet, at least I haven't 
noticed all the extra perks party members supposed to get</grin>

In any case, the reason why we are trying to steer away from this, is 
because both inside and outside the group, definitions vary. Your 
original definition concentrated on the "unsolicited" aspect of spam, on 
the other hand the DMA's definition of spam is forged email. A consensus 
on what is spam exactly has not been reached by anyone inside or outside 
the group.

Additionally, as I stated in my other message, your definition is 
basically "unsolicited" which looks at the email from the individual 
users' perspective. "Bulk" on the other hand, is what bothers most ISPs, 
not unsolicited. Both must be taken into the account, and your 
definition is basically half of the ASRG working definition.

Yakov

---

From: Philip Miller <[email-masked]>
Date: Tue, 18 Nov 2003 19:36:25 -0500

Yakov Shafranovich wrote:
>> My latest attempt is:
>>
>> "A message is spam if it was sent without the justified expectation 
>> that the recipients (however many) are willing to receive it."
>>
> 
[snip]
> email, or consent and non-consent.

I think Marc's definition tries to be inclusive of both explicitly given 
consent, such as a confirmed mailing list subscription, and consent implicit 
in, for example, receiving an individually addressed email from someone 
previously unknown to you but containing content you wish to receive. Note 
that the latter is unsolicited but the intended recipient would be willing 
to receive it.

--
Philip Miller