On Monday, March 31, 2003 10:35 PM, Brad Templeton
[SMTP:brad(_at_)templetons(_dot_)com]
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:brad(_at_)templetons(_dot_)com]
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. postmaster(_at_)yourdomain(_dot_)com(_dot_) 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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg