Subject: RE: [Asrg] define spam

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 1 Apr 2003 11:09:17 -0500

On Monday, March 31, 2003 10:35 PM, Brad Templeton [SMTP:[email-masked]] 
wrote:
> On Mon, Mar 31, 2003 at 10:15:16PM -0500, Eric D. Williams wrote:
> > What came to me is this.  For at least what appears to be a metric in your
> > term
> > (over 100's messages) for injection into the MTS, where is this measured?
> >  Is
> > the system for measurement sensitive to temporal thresholds, e.g. I send 
one
> >
> > message 'spam' per hour for 100 days?
>
> This is a question of defining spam, as in "What is spam, that thou art not
> allowed to do it, or that laws or contracts may punish you for it?"
>
> That's quite different from the question of detecting spam, which is based
> on technical metrics.

Sorry, I thought the definition presented was an attempt to show the 
intersection of definitions of 'spam' and not the intersection of metrics used 
to detect 'spam'.  Though I realize that if you can find intersection for 
detection and definition you have definitely 'got spam', I think we must not 
set the bar too high for detection to miss the definition as related to other 
descriptors, e.g. consent agreement enforcement, origination forgery, etc. 
which I think are also being considered with in the context of 'spam'.

As you have stated previously:

On Friday, March 28, 2003 4:25 PM, Brad Templeton [SMTP:[email-masked]] 
wrote:
> On Fri, Mar 28, 2003 at 03:11:10PM -0500, Eric D. Williams wrote:
> > Thanks Dave. :-)
> >
> > Requirement 1)  The proposal MUST address the issue of RFC821 [or envelope
> > protocol] originating MTA/MUA authenticity.
>
> Hmm.  I would venture that that is just one tool against spam, and not a
> necessary one.  A working group on email authentication really is an
> independent issue.     I would consider this a MAY, not a MUST.
>
> Again, this is an implementation approach, not a goal.  Or rather, if SMTP
> envelope authentication is a goal in and of itself, it's not a goal of
> this RG, which is researching solutions to the spam problem.

Is the intent then to develop proposals for detecting 'spam' as it relates to 
the consumption of MTS resources for undesirable messaging?  That is a very 
slippery slope.  You must then determine the intent of the message or its 
desirability before it reaches it's recipient, no?

> > Or of single or many senders exploiting a temporal window to do their dirt.
> >
> >  Thus the traffic experienced is not a problem.  Does 'spam' not remain a
> > problem irrespective of the network bandwidth consumed by it's presence?
>
> As noted, the 4 problems caused by spam are server overload, ruination of
> mailbox S/N, creation of fear of putting your email address out, and dealing
> with both real and bogus complaints.
>

Ok.  I that is correct I am referring to #1 as an area of concern if the 
detection method is not sensitive to temporal manipulation to relieve the 
'traffic' issue, I would not concede that 'traffic' is not a significant 
determinant of 'spam' but that in defining 'spam' it is not necessarily an 
absolute identifier.  On #2 that is an affect of 'spam' true, but a overly 
chatty thread on an e-mail discussion list would also fit that metric so 
neither is it an absolute identifier (BTW, I know you are not trying to make 
these absolute identifiers I am just pointing this out for the sake of the 
following points).  #3 I think is also a subjective matter, if one can 
effectively determine the origination point for messages and can subsequently 
apply (by whatever means) an effective consent agreement (+/-) then the problem 
may be alleviated, I think in fact that is the genesis of the problem.  I am 
not sure what is meant by #4, could you explain?

> If you solve these 4 problems that is all that matters.  You refer to problem
> 1, network bandwidth, which is just one.
>
> However yes, I very definitely say, if you can solve the problem, it does
> not matter that some "unwanted" mail goes through.   It's not, I believe
> the goal to stop unwanted mail, just to stop getting so much of it that it
> makes your mailbox less useful/servers overloaded/etc.

I agree.

8<...>8

> So while one employee mailing 10 strangers a sales pitch may not be large
> enough to meet a volume threshold we might set for spam, it is a spam if the
> employee's boss told him, and many other employees, to do this.

So any nondescript marketing program may be considered as 'spam' (but only if 
sent to cold (non-consenting) contacts)?  I don't have a problem with that, but 
I do still have an issue with the determinability of 'desirability'.

> >
> > I concur, however this could also lead to (in a legal construct) a 
loophole.
> >
>
> Indeed, I point it out as one to close in creating a spam definition.
> Whether it is a problem depends on the threshold.  For example, if the
> threshold
> is low, like say 25, then even 1000 affiliates could only send 25,000 mails.
> Sounds like a lot, but do the math -- there are 50,000,000 mailboxes out
> there
> on spammer's lists.    If we cut the spammers of the world down to 10 million
> spams a day that get through, in aggregate, we're talking about getting only
> one every 5 days on average, which certainly takes back your mailbox.

For some yes for the targets (which is a subset of the total number of 
mailboxes) they may not have their s/n reduced. What about methodologies that 
'produce' the spam, these have definite (or at least determinable) traces with 
respect to the transport and enveloping, where does that information fit in?

> Still, I think the loophole can be closed, by saying that it's the count
> in a "campaign."   So an affiliate program is a campaign, and all mail by
> affiliates due to it would be counted in the total for the maker of the
> program.

I agree, based on your previous proffer of 'volume' or 'traffic' as an 
identifier (though not absolute).

> >
> > I don't know.  I think there is also the issue of 'spam' that appears to
> > come
> > from someone you know, e.g. a mailing list or a familiar name in the
> > recipients
> > domain e.g. [email-masked].  Of course we may have
> > countermeasures
> > to prevent message origination from off site with an 'internal' domain but 
I
> >
> > just don't see that as a universal case.
>
> That is not spam from somebody you know, that is spam forged to appear as
> spam from somebody you know.
>

Indeed, but that is the point I am making.  The issue I was addressing was the 
issue of whether there would be a usable opt-out option in such a case.  From 
someone you 'really' know and who originated the message v. the forged 822 
header, which likely is not connected to a viable or effective consent 
establishment mechanism (opt-out).  The problem is that a number of 'spam' 
messages with this construction are certainly not a mistake or correctable with 
an opt-out.  So where does that leave the recipient?  Certainly, we could 
assume that other violations have occurred (as in #1, #2) or the method of 
initiation of the 'campaign' but does that answer the question?

> > And the rest are blacklists? filters? blocks?
>
> Whatever systems people decide to use, of course.

Ok.

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