Subject: [Asrg] Summary/outline of why the junk button idea is pre-failed

From: Rich Kulawiec <[email-masked]>
Date: Tue, 2 Mar 2010 08:18:10 -0500

I'm going to try to summarize and enumerate some of the arguments against
the general idea of a report-as-spam button.  My position is that several
of these points (individually) make the case that it's a truly bad idea
and should be abandoned immediately and permanently, and that collectively,
they're an overwhelming rationale.  Others differ, of course.

This is a *summary* and not an attempt to provide every nuance
of every argument, so nitpicking is discouraged.  You may rest
assured that I read the traffic on this list and have been paying
close attention to the spam problem for the past several decades. ;-)

1. User incompetence

	Users have spent the last quarter-century conclusively proving
	that they cannot reliably discern spam from non-spam.  They stack
	the pile of evidence higher every day, by misclassifying spam
	as non-spam and vice versa, by replying to spam, by trying to
	unsubscribe from spam, by falling for phishes, by handing over
	valuable information to spammers, etc.	How many "unsubscribe"
	requests do we see sent to entire mailing lists, even by
	supposedly-mail-literate technical personnel?  How many people
	on public mailing lists cannot distinguish between on-list and
	off-list replies?  It's not reasonable to expect that anyone who
	has failed to master these rudimentary email tasks will be able
	to distinguish spam from non-spam, especially when some spam is
	more competently composed and delivered than some non-spam.

	This is, I'm sorry to say,  not a solvable problem.  And it will
	steadily get worse as more (less-experienced) people get online,
	and as spammers get craftier: evolutionary pressure on spammers
	is clearly selecting for the smarter ones.

	This can't be avoided by educating users: "educating users"
	is one of Marcus Ranum's six dumbest ideas in security for very
	good reason.  In the case of spam, we KNOW it has failed because
	we wouldn't have much of a spam problem to worry about if it
	had worked even modestly well.

2. User time

	Let's assume that #1 is completely wrong: let's assume that
	most/all users are competent spam/non-spam classifying engines.
	Let's further assume that they're so proficient at it that they
	can do so in 5 seconds per message.

	Based on both these incredibly over-optimistic assumptions, we can
	then calculate how much end-user time will be spent performing
	this classification task and hitting the button.  6.3 million
	decisions/pushes equates to about a man-year, which means that even
	a single small spam run (say 300 million attempts, 3% delivery rate,
	thus 9 million deliveries) can easily chew up well over a man-year
	of time.  Do the math.

	Part of the reason we try to stop spam/spammers is to prevent
	them from using up end-user time.  We should not be tasking
	users with this, as it neatly undercuts part of what we're
	trying to do.

3. User exposure

	Many clueless users, unfortunately, use web browsers or otherwise
	HTML-enabled mail clients to read their mail.  (Of course we can
	safely presume that competent professional postmasters or abuse
	desk personnel don't do this, but the report-as-spam button is
	intended for the masses, and they, sadly, do.)

	It is certain that in the process of trying to perform classification
	tasks, they'll click on links "just to see what's there".  This
	not only provides very useful information to spammers, but it will
	assist phishers, trojan downloaders and others whose goal isn't
	really spamming per se, but using spamming to penetrate
	systems/networks or perform reconnaissance on them.

4. User influence on security policy

	Anti-spam defenses are similar to firewall rules: they control
	site security.	End-users should not be permitted to override
	or otherwise modify firewall settings: neither should they
	be permitted to override or otherwise modify anti-spam settings.
	First, because it's not their job, second, because they're
	not responsible for the consequences, third, because they
	lack expertise in this area.

	(This is not to say that they shouldn't have input.  But all such
	input should be manually, carefully reviewed by qualified and very
	skeptical personnel before any decisions are made about using it.)

5. Duplicates existing functionality

	All competently-run sites support the RFC 2142-stipulated
	"abuse" role address and have appropriately experienced,
	trained, qualified and diligent staff reading every message
	sent there.  It's trivially easy for any user to forward
	questionable mail traffic (with full headers of course) to
	the abuse address of their own mail provider, who can then
	decide what to do about it.  These personnel are far better
	situated to decipher headers, correlate against logs,
	assess threat severity, etc.  They're also much less likely --
	presuming that they're competent -- to hand over useful
	information to the enemy.  See next point as well.

6. Free useful intelligence for spammers

	It's great when your enemy hands you useful information.

	It's even better when they expend considerable time and effort to
	do so.	Spammers can quite easily rig this methodology to provide them
	with a wealth of actionable intelligence -- and some of them will.
	We should not be building mechanisms that directly support the enemy.

7. Creating more Internet mail traffic is a bad move

	We're drowning in (as a more generic term than "spam") junk
	SMTP traffic.  The last thing we should do is create more of it.
	Every possible thing we do to fight spam should dampen the response,
	not amplify it.

	This (sending outbound traffic) also violates a fundamental
	principle of abuse control: do not allow attackers to generate
	outbound traffic from *your* site to destinations of
	*their* choosing.  This never ends well.

8. Report-as-spam button repurposed as weapon

	We've already seen how spammers have repurposed any number of
	ill-conceived anti-spam concepts (e.g., SAV) as weapons.
	They'll do that with this too, should it profit them to do so.
	I trust at least a few methods are obvious on inspection;
	there's also a few non-obvious ones that I will not be discussing
	on a public mailing list, some of which relate to the next point.

9. The zombie problem

	There are, at bare minimum, 100 million fully-0wned systems
	out there.  I've seen estimates as high as 250M (Cerf) and more
	moderately, 140M (Kletnieks).  My back-of-the-envelope
	estimate is currently 200M.  And climbing.

	It doesn't really matter.  Whatever the number is, it's enormous,
	and growing steadily.  And abusers who now own those systems *also*
	own every report-as-spam button that those users have access to,
	e.g., if they have a work email account, home email account,
	freemail account, then they fully control all three.  They can
	suppress pushes; they can create pushes.  They can generate
	ersatz traffic in order to suppress or create pushes related
	to it.  They can manipulate this any way, every way, they wish.

	They can create additional email accounts -- at their own ISP
	(many consumer ISPs offer 5 per household and similar) or at
	freemail providers just to have more buttons to push more often.
	Or *not* to push, which is just as important.

	Moreover, they can do this easily and cheaply, and far faster
	than real live users can.  And they can do it in much greater
	numbers -- surely it is extremely unrealistic to expect all
	users, or a majority of users, to use such a button,
	even if furnished to them.

	Which means that spammers can easily dominate the statistics by
	as much as they wish.  They could, on a whim, account for 10% or 50%
	or 90% or 99% of them.  Of course, *today* there is little reason
	for them to bother.  But if we (again, very over-optimistically)
	presume that a report-as-spam mechanism is deployed tomorrow
	without any of the *other* issues listed above, THEN they will
	have a reason to.  Spammers have long since proven that they can
	and will innovate when they need to -- and quickly.

Summary of the summary:

I think any of 1, 6, 7, 8, and 9 alone are sufficient to kill the
idea outright.  9 kills a lot of ideas outright: it's the elephant
in the room that lots of people like to ignore or wishful-think away
because it neatly undercuts what they're proposing.  6 is often
badly under-estimated by those who haven't put in the time required
to study the enemy.

I think 2 and 3 are strong points but not sufficient to kill it.

I think 4 is arguable, but sites which allow users to override system
and network administrators tend to show up on the dataloss mailing
list and similar.  It's a very bad move to allow users to make any
decision related to security: they will invariably choose poorly.
(e.g., Knight-in-cave-after-bad-guy-dies-horribly: "He chose...poorly".
Yeah.  Like that.)

We've had 5 for years; what we unfortunately don't have are sites
that operate their abuse desks properly.  A button is not a substitute
for diligent staff who are willing to individually investigate every
single abuse report. This is called "baseline competence" and it's quite
reasonable to expect it of every operation, regardless of size.

Could *some* of these be mitigated?  Yes.  Rate-limiting, DNS bogusing,
firewalling, and other mechanisms might be able to at least slow down some
of the resulting attacks and abuse.  (For example, DNS bogusing can be
used to prevent users on intranets from resolving the hostnames of
known-phishing sites, thus probably preventing them from accessing their
web sites.  Of course this won't work for users who are reading their
work email from home and using their ISP's resolvers.)  But there's no
fixing 1, 2, 6, 8 or 9.

Bottom line: widescale deployment of this builds a mechanism that spammers
will own the moment they choose to do so.  I can't say for certain what
they'll choose to do with it, but it would be silly to think that whatever
they do with their brand-new toy will be for *our* benefit.

---Rsk

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 2 Mar 2010 08:40:33 -0500 (EST)

> close attention to the spam problem for the past several decades. ;-)

This message ignores the existence of TIS buttons on existing MUAs for 
webmail operators, and the actual experience that those operators have.

> 	had worked even modestly well.

Users are incompetent, that is why the existing systems use a single hit 
on the TIS button only to affect mail to the user hitting the button, and 
only affect mail to other users if a large number of users hit the button.

> 	users with this, as it neatly undercuts part of what we're

I can do spam at 1 second per message or less, and with the TIS button I 
will get less spam, saving even that second.

> 	systems/networks or perform reconnaissance on them.

It is mere speculation that the existence of the button will cause more 
clicks on malware - I don't see why it should, and in any case if the MTA 
acts on the TIS reports, there will be fewer opportunities for users to 
make this mistake.

> 	skeptical personnel before any decisions are made about using it.)

Please see Hanna Arendt "The Authoritarian Personality" for an explanation 
of this claim. Really, if you reject all user influence you will not have 
happy users.

> 	information to the enemy.  See next point as well.

I have never gotten a usefull spam complaint from a user, but it isn't 
because the messages weren't spam. It was always because the user didn't 
include the headers. All users find it difficult to include headers with 
forwarded messages, and will always drop the issue when asked to resend 
with headers. The TIS button solves this problem.

> 	We should not be building mechanisms that directly support the enemy.

Really, this is all supposition and there is no evidence that any spammer 
cares. There are many claims that spammers must care, but no examples of 
cases where they actually did care.

> 	*their* choosing.  This never ends well.

If even a small proportion of the TIS hits result in action, the total 
traffic will decrease. If the proportion of hits resulting in action is 
too small, then users will stop hitting the button and there will be 
little traffic increase.

> 	on a public mailing list, some of which relate to the next point.

Has this happened on any of the services that currently offer TIS buttons? 
How have they handled that?

>...

As long as there are zombies, no anti-spam or indeed and security related 
protocol is hopeless. But such protocols are necessary if not sufficient 
and we shouldn't refuse to take action merely because MS refuses to do its 
part. Indeed, their excuse for not taking any action is the same - as long 
as the rest of the internet is insecure why should they be any different?

>...

Daniel Feenberg

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Tue, 02 Mar 2010 14:52:30 +0100

I'm top posting to give a short answer. Sorry.

I do research on anti-spam filters. Some ideas I investigate are related to
having user feedback, reliable or not. For my requirements, John is right :
I just need two kind of feedbacks : this is ham/wanted or this is spam/unwanted.
This is ok for me.

I may agree with some of your arguments. But OK, you're not interested in
having user feedback. Other people are. So, let they get it. If you think
this is useless, just don't use it. It's an option : MAY, not MUST.

Regards,

JM

Rich Kulawiec wrote:
> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg
> 

--

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 02 Mar 2010 15:46:01 +0100

On 02/Mar/10 14:40, Daniel Feenberg wrote:
>> This is a *summary* and not an attempt to provide every nuance of every argument, so nitpicking is discouraged.  You may rest assured that I read the traffic on this list and have been paying close attention to the spam problem for the past several decades. ;-)
>
> This message ignores the existence of TIS buttons on existing MUAs for webmail operators, and the actual experience that those operators have.

In addition, it apparently assumes that users send reports directly to 
spammers.

> I have never gotten a usefull spam complaint from a user, but it isn't because the messages weren't spam. It was always because the user didn't include the headers. All users find it difficult to include headers with forwarded messages, and will always drop the issue when asked to resend with headers. The TIS button solves this problem.

+1, we're just talking about a neat and convenient tool to send 
complaints. Extra optimizations, such as using an IMAP flag to 
simultaneously synchronize with server's Bayesian data, move a message 
to a different folder, _and_ send the complaint, are possible for more 
competent users.

If spammers want to abuse abuse@ mailboxes, they can do so now, 
without having to wait for those buttons. The button makes that job 
easier for the user. The spammer (or 0wner) probably has easier ways.

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 2 Mar 2010 09:55:50 -0500

> this is useless, just don't use it. It's an option : MAY, not MUST.

You're missing most, if not all, of the point.  I suggest you re-read
my message with this idea in mind:

The primary beneficiaries of a standardized, widely-deployed mechanism
for a report-as-spam-button are spammers/abusers: they will own it
the moment they choose and will do whatever they want with it -- which is
unlikely to be good for us *whether we're using such a mechanism or not*.

Were the consequences of this confined solely to those operations who
might use such a mechanism, this *might* be tolerable: I could argue
that they fully deserve the pain they're inflicting on themselves, and
that perhaps Pavlovian conditioning would eventually kick in and get
them to stop.  Maybe.  But that's unfortunately not the case: site A's
decision to use this makes them a conscriptable-at-will attacker of
site B for all values of {A, B}.

I *strongly* recommend your attention to the discussion several years
ago on spam-l of the consequences of Verizon's choice to use outbound
SAV, wherein we all (well, maybe not "all", but those who were paying
attention) got a painful object lesson in how spammers will quickly
notice, study and employ ill-considered methodologies to their advantage.
There are some instructive points about that experience that directly
apply here -- and which should give considerable pause to anyone familar
with them.

---Rsk

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 02 Mar 2010 16:44:12 +0100

> unlikely to be good for us *whether we're using such a mechanism or not*.

Would that assertion still hold, in your opinion, if 
"report-as-spam-button" is replaced by "abuse-reporting-address"?

> apply here -- and which should give considerable pause to anyone familar

What is the similarity between SAV or similar "callback" mechanisms 
and reporting something as spam?

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 2 Mar 2010 10:56:38 -0500

On Tue, Mar 02, 2010 at 08:40:33AM -0500, Daniel Feenberg wrote:
> This message ignores the existence of TIS buttons on existing MUAs
> for webmail operators, and the actual experience that those
> operators have.

No, actually, it takes that into primary consideration.  It simply
extrapolates out to Internet scale by asking "what if everyone did this?"

Well, and then by extrapolating what we know of past spammer behavior
and current spammer capabilities.

> Users are incompetent, that is why the existing systems use a single
> hit on the TIS button only to affect mail to the user hitting the
> button, and only affect mail to other users if a large number of
> users hit the button.

A) it shouldn't even affect mail to that user and B) large numbers
of incompetent users -- which is what we have -- do not en masse
magically become competent.

Like I said, if the masses had even *minimal* competence, then
we would have a far smaller problem.  They're not.  We don't.

> I can do spam at 1 second per message or less, and with the TIS
> button I will get less spam, saving even that second.

You're not a typical user.  Not even close.  I can do that too,
and can even do so very reliably just by scanning Subject: lines.
(Especially since procmail pre-sorts all my incoming traffic.)
But this is *extremely* atypical.  Ordinary users can't do this,
and they're never going to be able to do this.  I think even
"5 seconds per" is extremely optimistic, based on a few
first-hand experiments and innumerable impromptu observations.

> It is mere speculation that the existence of the button will cause
> more clicks on malware - I don't see why it should [snip]

It's obvious on inspection, isn't it?  If you task users with classifying
spam-vs-not-spam, some of them will accept the task.  Then they'll try
to perform it.  Oops.

More generally that just this TIS-button discussion: every additional
second that a user spends with a spam up on their screen is an
additional risk.  We should be attempting to -- at every step --
*minimize* that time.

> Please see Hanna Arendt "The Authoritarian Personality" for an
> explanation of this claim. Really, if you reject all user influence
> you will not have happy users.

A) I'm not trying to have happy users.  I'm trying to have to have
secure users (and systems and networks). 

B) At no point did I say that all user influence should be rejected.
What I said that is that user-initiated spam/abuse reports should be
reviewed by qualified personnel.  There's no technological substitute
for clueful eyeballs.  And to clarify/emphasize, those clueful eyeballs
should be local to the user, and should be reviewing everything before
it escapes the local operation.  (Doubly so given that in many operations
the abuse is coming from inside.)

> I have never gotten a usefull spam complaint from a user, but it
> isn't because the messages weren't spam. It was always because the
> user didn't include the headers. All users find it difficult to
> include headers with forwarded messages, and will always drop the
> issue when asked to resend with headers. The TIS button solves this
> problem.

A) I receive quite useful spam complaints from users because I find
that requiring them to clear the bar labeled "figure out how to send
the message with full headers" is an *extremely* good way to have
the modestly-clueful ones self-select.  Many, many years of this
practice have shown that there is a high correlation between the
accuracy of the reports provided and the user's ability to do this.

B) A far easier, less risky, more universally-useful solution to
the header problem is "strongly encourage MUA authors to provide
a very very simple and very very obvious method to display all headers".
This doesn't require the invention of anything, the standardization
of anything, the deployment of anything: in nearly all cases, it
just means "make pre-existing functionality much much more visible".
Yes, this undercuts (A) in part but it does still leave users with
the need to remember abuse@$MYDOMAIN and that has also proven itself
to be a reasonable vetting process for complaint accuracy.

> Really, this is all supposition and there is no evidence that any
> spammer cares. There are many claims that spammers must care, but no
> examples of cases where they actually did care.

I suggest reading the archives of spam-l for example after example --
and those are just the ones publicly discussed and on just one list.

> If even a small proportion of the TIS hits result in action, the
> total traffic will decrease. If the proportion of hits resulting in
> action is too small, then users will stop hitting the button and
> there will be little traffic increase.

This is wrong: as I pointed out, abusers can generate an arbitrary
number of TIS hits.  Presuming that only (human) users will hit
the button is an error.

> Has this happened on any of the services that currently offer TIS
> buttons? How have they handled that?

You're missing the point.  It's probably not, as yet, worth the 
valuable time of attackers to do so.  That's because the TIS buttons
are isolated, they're not standardized, etc.  If I were an attacker,
I wouldn't trouble myself (much) to bother with them either.  But
if they were pervasive and standardized -- thus not only a far larger
target but one requiring much less programmatic effort to hit -- then
I probably would.

One of the repeated mistakes made in the anti-spam field over the
past twenty years -- and I'll admit to making it too -- is to presume
that just beause spammers aren't doing something today, that they can't
do it tomorrow.  Spammers have proven to us that once something starts
to catch on, they will invest the time to figure out if they can turn
it to their advantage.

> As long as there are zombies, no anti-spam or indeed and security
> related protocol is hopeless.

This is half-wrong and half-right.

A)  There are quite effective measures which can be used, and some of
them *are* being used: in particular (a) blacklisting (b) firewalling
(c) null-routing and (d) BOGUS'ing.  Used properly -- which is of
course the trick -- these are high-accuracy, low-cost, difficult-to-game,
difficult-to-repurpose-as-weapon tactics that provide excellent protection
not just against spam (directly) but against second-order attacks that are
auxiliary to spam.

B) While the zombie problem persists, nothing that comes from an
end-user system can really be trusted -- which is why it should never
be an input to any kind to an anti-spam or anti-abuse or security mechanism
UNLESS it is carefully reviewed by a human being before it goes anywhere.
We already have a massive abuse problem as a result of exactly that issue:
SMTP spam from zombies is just one component of it.  I think it's crazy
to believe for even a moment that the same abusers who've spent years
aquiring those zombies, organizing them into botnets, refining the code
that runs on them and makes more of them, will just sit on their hands
and do nothing if they're given this new capability.  Of COURSE they'll
use it.  And my guess is that -- given the ingenuity they've shown over
the past decade -- they'll use it for something even worse than the
things I can think up, and I can think up some fairly nasty stuff.

---Rsk

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 2 Mar 2010 16:09:16 +0000

>       users with this, as it neatly undercuts part of what we're

I don't think your numbers are very realistic (neither the 3% delivery rate for large campaigns, nor the 100% of users that will click the TIS button), but more importantly, how is this supposed to take longer than the alternative for unwanted messages of any kind: clicking the Delete/Trash button? In GMail, for instance, both buttons are right next to each other.

I think the only conclusion one can draw from the above is that reporting a message as spam shouldn't be more difficult that deleting a message. But then, if it were more difficult, most people simply wouldn't use that button.

Martijn.

PS unrelated to the above, but to save myself from thinking whether it's worth sending a reminder at all: CFP for VB2010 (conference on (anti-) malware/spam, 29 Sep-1 Oct, Vancouver) closes this coming Friday. http://www.virusbtn.com/conference/vb2010/call/index

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

---

From: der Mouse <[email-masked]>
Date: Tue, 2 Mar 2010 11:01:08 -0500 (EST)

> and current spammer capabilities.

And, as you know (or should), any datum obtained by extrapolation is of
at least slightly doubtful value.

Not that we (FWVO "we") shouldn't extrapolate.  But we shouldn't
confuse extrapolations with facts.

> [...] and B) large numbers of incompetent users -- which is what we
> have -- do not en masse magically become competent.

Actually, at many tasks, they do.  Not individually, of course, but en
masse; individuals' input needs statistical processing to produce the
more-competent output, though this can sometimes be as simple as just
taking the mean.  (See _The Wisdom Of Crowds_.)

> that just beause spammers aren't doing something today, that they
> can't do it tomorrow.

Indeed.  But it is equally wrong to presume that just because they can
do something, they will.  And, even if they do, this is not a static
field; even something that ultimately gets defeated may be useful,
either in the interim or in what it teaches us.

> Spammers have proven to us that once something starts to catch on,
> they will invest the time to figure out if they can turn it to their
> advantage.

Some of them.  Spammers are no more a homogenous class than
anti-spammers are.  This - FWVO "this" - may well prove to be useless
against certain classes of spammer, possibly even actively harmful.
But that is not to say that it will be useless against all spammers,
nor that it won't prove to have overall positive value.  (Not to say
that it will, either, of course.)

Of course, that's all generalities.  As for the specifics of this
particular instance, I see this as a space in which standardization is
actually a bad thing.  Even stipulating that your extrapolations are
dead on, your dismal outlook is predicated upon there being one
widely-deployed system; postulating dozens of TiS systems, each
slightly different and incompatible, leads me to a much more hopeful
outlook.  And that's what research often is: trying dozens of things to
see what we can learn from them.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 2 Mar 2010 11:41:53 -0500

On 3/2/2010 8:18 AM, Rich Kulawiec wrote:

I'm going to try to keep this brief, and at the same time avoid 
nitpickery.  I've put a point-by-point non-nitpickery response after 
"----", but, you can avoid reading that entirely and stick directly to:

It's not as if the industry doesn't lack ample experience with TiS 
buttons.  If TiS is as bad as you say, would anybody that matters still 
be using it?

Verizon abandoned SAV.  Did AOL, Gmail, MSN, Yahoo abandon TiS?  Nope.

I'm going to take a huge leap in suggesting that those guys are pretty 
smart, and if they still like them after a few bazillion man-years 
accumulated experience, they're probably right, and it is useful.

Especially when it agrees with my experience ;-)

You can stop reading now if you wish.
------------------------------------------------------------
>          that they cannot reliably discern spam from non-spam.

This flies directly opposite to my experience, and the experience of 
vastly larger environments than you or I.  They must know something, 
doncha think?

Certainly there are, er, lots of stupidities, but statistically, they 
still are a small fraction, and using statistical methods they can be 
ignored.

>          this classification task and hitting the button.

You're assuming that this "classification task" is something that the 
end-user isn't doing already.  They already are.  At worst, we're adding 
a button press.

This argument is only relevant if the TiS button is to be used _instead_ 
of filtering/if the TiS button isn't allowed to affect filtering in any 
way.  Nothing could be further from the truth.  It is an adjunct to 
filtering, where the time is only spent on the email the filters 
_missed_, with a goal of _both_ refining the filters yet further (to 
reduce the miss rate) as well as pushing the spam fight back to the 
originators (to stop the spam being sent at all).  Both are necessary, 
and both will _reduce_ the total amount of end-user time spent.

>          tasks, they'll click on links "just to see what's there".

They're already doing this now.  A TiS button won't make it any worse.

>          or otherwise modify firewall settings

Strawman argument:

This presumes that the site administrator allows this to happen, and 
secondly, that filter decisions directly follow _every_ TiS button hit. 
  They don't need to, and I don't know of any filtering environment that 
does.

>          sent there.

First, this reverses the role of "abuse".  Abuse is for abuse 
_originating_ at the site, which is of no help for abuse _received_ at 
the site.  Secondly, existing abuse implementations just about always 
fail in this regard because a humungous chunk of the population doesn't 
have mail readers capable of constructing adequate abuse reports (eg: 
missing headers).  We could, if we wished to, simply piggyback on 
RFC2142 (and email to abuse, losing the ability to triage the reports), 
but the standardization effort is still of value to provide actionable 
reports.  Because most of them aren't now.

>          It's trivially easy for any user to forward
>          questionable mail traffic (with full headers of course)

Aye, there's the rub - it's _not_ trivially easy now.  There's no 
standard of what abuse forwards look like, and in the majority of cases, 
there are _no_ full headers.  Forwarding full headers in outlook isn't 
trivial nor easy, and half the time _still_ get mucked up when the user 
tries to do it right thru no fault of their own (thank your favourite 
software manufacturer for that).

The very best of the forwarding mechanisms are inconsistent and 
difficult to process.  The worst of them are totally unuseable, and 
unfortunately the most numerous.  It needs a standard format, at least, 
if it's to be done at all.

>          It's great when your enemy hands you useful information.

This presumes, of course, that spam reports go to spammers.

Please explain to me how my TiS button leaks information to spammers.

> 7. Creating more Internet mail traffic is a bad move

This asserts a model of not reporting spam, and thereby limiting 
yourself to JHD at a server (or worse, user) level.

This is a step backwards that we must not take.  We have to move the 
fight back up the chain.

>          ill-conceived anti-spam concepts (e.g., SAV) as weapons.

Please explain how spammers use SAV as a weapon.  They're not, because 
they can't and/or it doesn't have ROI versus simpler things they already 
have at their disposal.

Sure, a spammer could use Verizon SAV to, say, DOS my mail servers.  But 
it's is trivially easy to defend against.  Now, instead, the spammer 
gets their botnet to DDOS me directly.  That's a lot harder to stop, and 
simpler for them to implement.

Yes, of course there are examples of anti-spam mechanisms repurposed as 
weapons.  Eg: the late unlamented BlueFrog.

But at this stage of the game, presuming that the nebulous spec we're 
talking about is of necessity reusable as a weapon is absurd.  We can't 
say that until we know what "it" is.

All of the big/high value targets have TiS buttons now.  Many spammers 
_only_ spam/care about the big boys.  Please explain how spammers are 
using TiS buttons as a weapon against the big boys.  They aren't.

> 9. The zombie problem

By that argument, the war is lost, all the machines are pwned anyway, 
_nothing_ is useable or trustworthy, and the Internet should turn off 
the lights.

We're not at that state (yet), so the argument doesn't hold.

I should point out, by way of demonstration, that if the argument is 
true, then port 25 blocking doesn't work.  All the bots would be using 
the user's SMTP server, and port 25 blocking wouldn't help.  Right?

Wrong.  Port 25 blocking does work.

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 2 Mar 2010 12:12:58 -0500 (EST)

On Tue, 2 Mar 2010, Rich Kulawiec wrote quite a lot. I don't propose to 
answer it directly - he doesn't introduce any new evidence or new 
arguments, just asserts his old arguments more loudly. Everyone reading 
the exchange is entitled to evaluate the arguments for themselves in the 
light of their own experience.

There is one argument, not made by Kulawiec that does deserve a response. 
That is the underlying problem with the TIS button that is real. It will 
generate ARFs that are really just list-unsubscribe requests from 
perfectly legitimate sources. It will generate these in large numbers and 
it will be impractical to reduce them with user education. Anyone 
proposing to process the flood of such messages will have to come up with 
an economical way of doing so that doesn't inconvenience the list owners. 
In fact, I think most of the opposition to the TIS button comes from the 
owners of such lists who feel they would be the victims. To some extent 
they are justified - they are following the rules, why should they pay a 
penalty. But if the penalty were a small change in their operation, say an 
improvement in the standardization of list-unsubscribe headers - it might 
be justifiable.

Since any operator can just ignore the reports, it is unreasonable to 
claim that the TIS button will cause extensive damage to anything. They 
might be ineffective, but I don't think so.

Daniel Feenberg

---

From: Michael Thomas <[email-masked]>
Date: Tue, 02 Mar 2010 10:14:45 -0800

+1. Rich's polemic is *way* off the rails. Manifestly, as Chris points 
out about ISP's with their TiS buttons.

Mike, not to mention OL, Thunderbird...

Chris Lewis wrote:
> buttons.  If TiS is as bad as you say, would anybody that matters 
> still be using it?
>
> end-user isn't doing already.  They already are.  At worst, we're 
> adding a button press.
>
> This argument is only relevant if the TiS button is to be used 
> _instead_ of filtering/if the TiS button isn't allowed to affect 
> filtering in any way.  Nothing could be further from the truth.  It is 
> an adjunct to filtering, where the time is only spent on the email the 
> filters _missed_, with a goal of _both_ refining the filters yet 
> further (to reduce the miss rate) as well as pushing the spam fight 
> back to the originators (to stop the spam being sent at all).  Both 
> are necessary, and both will _reduce_ the total amount of end-user 
> time spent.
>
>> 3. User exposure
>
> secondly, that filter decisions directly follow _every_ TiS button 
> hit.  They don't need to, and I don't know of any filtering 
> environment that does.
>
> fail in this regard because a humungous chunk of the population 
> doesn't have mail readers capable of constructing adequate abuse 
> reports (eg: missing headers).  We could, if we wished to, simply 
> piggyback on RFC2142 (and email to abuse, losing the ability to triage 
> the reports), but the standardization effort is still of value to 
> provide actionable reports.  Because most of them aren't now.
>
> standard of what abuse forwards look like, and in the majority of 
> cases, there are _no_ full headers.  Forwarding full headers in 
> outlook isn't trivial nor easy, and half the time _still_ get mucked 
> up when the user tries to do it right thru no fault of their own 
> (thank your favourite software manufacturer for that).
>
> unfortunately the most numerous.  It needs a standard format, at 
> least, if it's to be done at all.
>
> they can't and/or it doesn't have ROI versus simpler things they 
> already have at their disposal.
>
> Sure, a spammer could use Verizon SAV to, say, DOS my mail servers.  
> But it's is trivially easy to defend against.  Now, instead, the 
> spammer gets their botnet to DDOS me directly.  That's a lot harder to 
> stop, and simpler for them to implement.
>
> Yes, of course there are examples of anti-spam mechanisms repurposed 
> as weapons.  Eg: the late unlamented BlueFrog.
>
> talking about is of necessity reusable as a weapon is absurd.  We 
> can't say that until we know what "it" is.
>

---

From: Steve Atkins <[email-masked]>
Date: Tue, 2 Mar 2010 10:38:39 -0800

On Mar 2, 2010, at 9:12 AM, Daniel Feenberg wrote:

> 
> 
> On Tue, 2 Mar 2010, Rich Kulawiec wrote quite a lot. I don't propose to answer it directly - he doesn't introduce any new evidence or new arguments, just asserts his old arguments more loudly. Everyone reading the exchange is entitled to evaluate the arguments for themselves in the light of their own experience.

+1

> 
> There is one argument, not made by Kulawiec that does deserve a response. That is the underlying problem with the TIS button that is real. It will generate ARFs that are really just list-unsubscribe requests from perfectly legitimate sources. It will generate these in large numbers and it will be impractical to reduce them with user education. Anyone proposing to process the flood of such messages will have to come up with an economical way of doing so that doesn't inconvenience the list owners.

They'll only be sent if the list owner has signed up for the ISPs feedback loop. If the list owner believes the FBL reports will inconvenience them, they need not request them.

As a ludicrous extreme, if the list owners are sending email that is so offensive that every single recipient hits the "TIS" button then they'll have to be able to deal with no more inbound email than they're sending outbound (and that only very briefly).

More realistic numbers are at least two or three orders of magnitude lower than that. If you're sending a million messages a day, all to ISPs that you have signed up for feedback loop reports, then you might have to deal with a couple of thousand feedback loop reports. That's a level of traffic that's trivial to handle for a company that can manage a database and MTA to send a million messages in the other direction.

> In fact, I think most of the opposition to the TIS button comes from the owners of such lists who feel they would be the victims. To some extent they are justified - they are following the rules, why should they pay a penalty. But if the penalty were a small change in their operation, say an improvement in the standardization of list-unsubscribe headers - it might be justifiable.

Most of the senders I've talked to think that the reports from the TIS button at, eg, AOL are _great_. ESPs especially so.

The marketers who object to the TIS button, tend to object to the concept that their important mail can be described as "spam" by the recipient at all. Whether that button sends a feedback loop report, adjusts MUA-level filters, adjusts MTA-level filters or nothing much at all is very much secondary to them.

> 
> Since any operator can just ignore the reports, it is unreasonable to claim that the TIS button will cause extensive damage to anything. They might be ineffective, but I don't think so.
> 

Cheers,
  Steve

---

From: Barry Shein <[email-masked]>
Date: Tue, 2 Mar 2010 13:48:37 -0500

I don't know that I'm generally against the idea but I'd like to add a
to Rich's list, not unique or new, but since I do this sort of thing
for a living...

I don't see the problem as users being "stupid", sometimes we all are
of course.

I just think they quickly re-purpose something like a spam button to
their own wishes.

Practically all the spam-button reports we get from AOL are just
attempts to unsubscribe to some mailing list they subscribed to.

    Aside: Most of the rest are just misfires or who knows what, why
    do people hit the spam button to a mail from someone with the same
    last name as theirs informing them that Uncle Albert is out of the
    hospital?  Happens a lot, not sure why, an emotional spasm?  They
    hate their uncle or their sister sending the mail? Anybody's
    guess.

Anyhow, they've repurposed the spam button to mean the "stuff I don't
want" button, for whatever whim of "I don't want" which suits them.

And why not?

There's no feedback on the feedback.

No one has the time or inclination to say "that wasn't spam, you're
just trying to unsub a list, you're abusing the anti-abuse feature!"

No, you just manually unsub them when it happens or else they'll hit
the AOL spam button over and over, sometimes many times for each
message (I don't think AOL filters that very well) clearly getting
more annoyed I guess that they're not being serviced quickly enough.

And the ridiculous ones you ignore.

I'd characterize the problem with the design as one of wishful
thinking, imagining people will get with the program and use it as you
hope, with no feedback to nudge them back on the path.

911 dispatchers complain about people calling for inappropriate
reasons.

And they can actually arrest you or fine you for abusing 911!

In summary, the idea has all the problems of the system it intends to
fix.

That is, how about we just give them email, but encourage them to use
it appropriately! Oops, or did I mean a spam button?

And then they don't.

And we can't do much about it.

-- 
        -Barry Shein

The World              | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 2 Mar 2010 14:28:23 -0500

> attempts to unsubscribe to some mailing list they subscribed to.

Which, if we spec "ARF" works out just fine, because the list 
unsubscribe headers will be in the report if the report recipient 
chooses to apply them.

> There's no feedback on the feedback.

That's _not_ the business nor the burden of a feedback _format_ 
specification.

Receivers have ample opportunity to apply feedback and other heuristics, 
automated or otherwise.

Most already do.  Spamcop does.  We do.

> just trying to unsub a list, you're abusing the anti-abuse feature!"

The ISPs have a bazillion man-years experience with TiS.  Do you not 
think they've gotten that figured out?

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 2 Mar 2010 14:32:39 -0500

> an economical way of doing so that doesn't inconvenience the list owners.

Having the report recipient automatically utilize the list unsubscribe 
headers present in the headers immediately comes to mind.

> improvement in the standardization of list-unsubscribe headers - it might

I think most of us would be satisfied with improvements in the 
_adoption_ of the existing list unsubscribe headers.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 2 Mar 2010 11:38:01 -0800

On Mar 2, 2010, at 11:32 AM, Chris Lewis wrote:

> Having the report recipient automatically utilize the list unsubscribe headers present in the headers immediately comes to mind.
> 
> I think most of us would be satisfied with improvements in the _adoption_ of the existing list unsubscribe headers.

The existing spec is too loose to really be usable automagically, which means that the only thing that can be usefully adopted is a subset of RFC 2369. Vagueness about what that subset should be is one thing hindering adoption. (Redundancy as compared to in-body unsub links and out of band FBL reports is another, I suspect).

Cheers,
  Steve

---

From: Daniel Feenberg <[email-masked]>
Date: Tue, 2 Mar 2010 15:38:39 -0500 (EST)

On Tue, 2 Mar 2010, Steve Atkins wrote:

>> There is one argument, not made by Kulawiec that does deserve a 
>> response. That is the underlying problem with the TIS button that is 
>> real. It will generate ARFs that are really just list-unsubscribe 
>> requests from perfectly legitimate sources. It will generate these in 
>> large numbers and it will be impractical to reduce them with user 
>> education. Anyone proposing to process the flood of such messages will 
>> have to come up with an economical way of doing so that doesn't 
>> inconvenience the list owners.
>
> They'll only be sent if the list owner has signed up for the ISPs 
> feedback loop. If the list owner believes the FBL reports will 
> inconvenience them, they need not request them.

My understanding is that the ARF from the TIS would not go to the list 
owner, but to the MTA that servers the user.  The feedback loop is one way 
the MTA could communicate back to the source of the message, but at least 
at first I don't think it would be the primary path. The list-unsubscribe 
header is more prevalent, and probably much easier for the list owner to 
implement. So unless that MTA can handle the list-unsubscribe 
automagically the TIS messages could be something of a burden. I 
understand that some webmail providers do handle TIS actions by executing 
the action specified in the list-unsubscribe header (if the header is 
present) but I am not really familiar with how they do so, or if it is 
difficult. It would be worthwhile getting some information on this point.

List-unsubscribe headers are not all that prevalent today, but if TIS 
buttons were more universal, they might grow in importance. There is a 
question if they are sufficiently standardized to do the job.

Daniel Feenberg

---

From: "BOBOTEK, ALEX (ATTLABS)" <[email-masked]>
Date: Tue, 2 Mar 2010 14:12:35 -0800

+1

In the real world, there is so much positive experience with spam
reporting.  Vipul's Razor (report-based spam filter) evolved into a
commercial filter now used by most major US-based ISPs.  Sure there are
problems that need to be dealt with (e.g., unsubscribe, gaming, random
human errors), but rather effective solutions (including but not limited
to those involving reporter reputation, low-pass filters, and a "Not
Spam" button) have been found.  

In OMA (SpamRep abuse-reporting standards activity), the accepted wisdom
is that the reporting protocols should be standardized, but that the
backend processing (interpreting the reports) and report destination
shouldn't (parenthetically, mechanisms for specifying destination and
authorizing forwarding may be within the scope of the OMA standards).  

Is there not enough of a plurality convinced of

* the benefits of reporting and
* the benefit of interoperability resulting from standardizing reporting

to proceed with standardizing abuse reporting?  

Regards,

Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Lewis
Sent: Tuesday, March 02, 2010 8:42 AM
To: [email-masked]
Subject: Re: [Asrg] Summary/outline of why the junk button idea is
pre-failed

a button press.

Strawman argument:

does.

have at their disposal.

---

From: Jose-Marcio Martins da Cruz <[email-masked]>
Date: Tue, 02 Mar 2010 23:42:23 +0100

> authorizing forwarding may be within the scope of the OMA standards).  

I agree with this : reporting protocols, buttons, ... OK !

Yes, What to do with report destination, interpretation, etc... This is an open issue which shall 
remain open to research and creativity of people working on the subject. There are a lot of 
different things to do with.

> to proceed with standardizing abuse reporting?  

I still don't think "abuse reporting" is the good name. It's more general than that. In my context, 
it's just user feedback about how a filter in a server handled a message.

Regards,

--

---

From: John Levine <[email-masked]>
Date: 3 Mar 2010 00:24:43 -0000

>> That is the underlying problem with the TIS button that is real. It
>> will generate ARFs that are really just list-unsubscribe requests
>> from perfectly legitimate sources. It will generate these in large
>> numbers and it will be impractical to reduce them with user
>> education. Anyone proposing to process the flood of such messages
>> will have to come up with an economical way of doing so that
>> doesn't inconvenience the list owners.

You say this like it's a new issue.  I get FBLs from a lot of large
providers, AOL, Yahoo, Comcast, Hotmail, Roadrunner, and a few others.
The vast majority of FBL reports are messages from COI lists.  A far
smaller number are forwarded spam that Spamassassin didn't catch on
the way out, and a very few are mystery complaints about normal mail.
The total number of reports is small, maybe two a week.  Considering
how large the mail systems are that already send me FBL reports, it's
hard to imagine that more widespread reporting would be more onerous.

The FBL reports are fed into a little perl script I wrote that
recognizes list mail, picks out the list name and recipient address,
and stuffs unsub commands to the list manager.  It's not a big deal.
It's entirely automated.  Anyone else with more than a trickle of FBL
reports should do the same thing.

>headers present in the headers immediately comes to mind.

You have a reputation problem, knowing whether it's a real list, or a
spammer trying to intercept complaints.  I suppose that it's at worst
harmless so long as the original recipient tracks the complaint rate
so they notice if it's a higher spam-like rate rather than a lower
unsub-like rate.

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Tue, 2 Mar 2010 20:21:40 -0500

> to proceed with standardizing abuse reporting?  

I tend to suspect that the potential benefits outweigh the drawbacks
which seem to fall into the range of "maybe useless" to "maybe mildly
annoying" to someone (e.g., an unsub magnet, which could be handled
better automatically.)

In contrast I was a critic of SPF, e.g., very early on because both
sides had to play, and it seemed like it just wouldn't accomplish very
much, if anything. The best DKIM proponents could come up with were
these mythical "reputation systems", usually in response to "why
wouldn't spammers just DKIM?", yet were advocating mandatory
implementation (well, implement or we won't accept your email, at
least in the beginning.)

This strikes me more like VERP in impact, if you want to play, then
play, if not, fine, the value to you (for large sets of "you") has to
be self-evident or else feel free to ignore it.

-- 
        -Barry Shein

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 03 Mar 2010 11:22:13 +0000

> extrapolates out to Internet scale by asking "what if everyone did this?"

I've found AOL feedback loop reports very useful. In fact, the false 
positives have been the most useful because they've given me the evidence 
to argue for better practice on our systems. That is, people have reported 
messages from subscribed forums - I've argued that the forum should have 
finer grained controls over email notifications (at thread level), and that 
the messages should contain links to the controls that they have.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 03 Mar 2010 11:28:22 +0000

> inconvenience them, they need not request them.

Where there's a list-unsubscribe button, the client should offer to 
unsubscribe rather than report the message. In fact, the button could even 
change its label.

If the user still wants to report the message as junk, then the 
administrator has the option of unsubscribing the user. But, note, the user 
in a better position to answer the question "is it just this message that 
you're objecting to, or all messages from this list".

In fact, that's a prime example of why you might want to distinguish 
between "block" and "report", and why the button needs to be labelled with 
a verb, not an adjective.

> As a ludicrous extreme, if the list owners are sending email that is so
> offensive that every single recipient hits the "TIS" button then they'll
> have to be able to deal with no more inbound email than they're sending
> outbound (and that only very briefly).
>
> More realistic numbers are at least two or three orders of magnitude
> lower than that. If you're sending a million messages a day, all to ISPs
> that you have signed up for feedback loop reports, then you might have to
> deal with a couple of thousand feedback loop reports. That's a level of
> traffic that's trivial to handle for a company that can manage a database
> and MTA to send a million messages in the other direction.
>
>> penalty. But if the penalty were a small change in their operation, say
>> an improvement in the standardization of list-unsubscribe headers - it
>> might be justifiable.
>
> Most of the senders I've talked to think that the reports from the TIS
> button at, eg, AOL are _great_. ESPs especially so.
>
> The marketers who object to the TIS button, tend to object to the concept
> that their important mail can be described as "spam" by the recipient at
> all. Whether that button sends a feedback loop report, adjusts MUA-level
> filters, adjusts MTA-level filters or nothing much at all is very much
> secondary to them.
>
>>

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 03 Mar 2010 11:30:44 +0000

--On 2 March 2010 15:38:39 -0500 Daniel Feenberg <[email-masked]> wrote:

> I understand that some webmail providers do handle TIS actions by
> executing the action specified in the list-unsubscribe header (if the
> header is present)

Yes, but in the case that I've heard of: only if the message is DKIM 
signed, I think.

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 03 Mar 2010 11:40:50 +0000

--On 2 March 2010 08:18:10 -0500 Rich Kulawiec <[email-masked]> wrote:

> and should be abandoned immediately and permanently, and that
> collectively, they're an overwhelming rationale.  Others differ, of
> course.
>

Crowd sourcing should be used to gather confidence in reports when they're 
many. Admin inspection can be used when they're few.

> 2. User time

Nobody is asking them to classify every message. This is tool that they can 
choose to use, or not. Indeed, the mechanisms that we're discussing are 
about how the user system can communicate classification to the 
administrator. This could be done by the user client filter. Remember, the 
user is already trusting the filter to hide email.

> 	systems/networks or perform reconnaissance on them.

That depends on where the reports go. On my system, they'll be coming to 
me.

> 	skeptical personnel before any decisions are made about using it.)

Ah, so that's not an argument against providing a junk button at all, 
merely a caution. Noted.

> 	questionable mail traffic (with full headers of course)

Right, but most don't know that the address exists, and don't know what 
full headers are. A junk button *could*  (A) expose the reporting mechanism 
to the user, and (B) ensure that the reports are useful by ensuring that 
they include full headers.

In fact, I think that you've just given a convincing argument FOR a junk 
mail button.

> to	the abuse address of their own mail provider, who can then

My reports won't be going to spammers. Have you really been reading this 
thread?

> 7. Creating more Internet mail traffic is a bad move

Agreed. That's why I'm advocating IMAP flags or annotations as a better 
solution.

> 	on a public mailing list, some of which relate to the next point.

Again, the mechanism should only generate reports to the administrator, and 
the administrator needs to have quality assurance mechanisms in place. 
You've suggested some. Others are available.

---

From: Dennis Dayman <[email-masked]>
Date: Thu, 4 Mar 2010 07:59:25 -0600

Interesting article

http://www.mediapost.com/publications/?fa=Articles.showArticle&art_aid=123574

-Dennis

---

From: Paul Russell <[email-masked]>
Date: Thu, 04 Mar 2010 09:16:06 -0500

> http://www.mediapost.com/publications/?fa=Articles.showArticle&art_aid=123574

The author is not interested in reducing or eliminating spam; he simply wants
tools to validate his delusion that his spam is not spam.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 4 Mar 2010 09:49:48 -0500

> tools to validate his delusion that his spam is not spam.

I wouldn't be quite so harsh.  But...  He completely glosses over a 
number of fundamental differences between 1-to-many _marketing_ and what 
is essentially bidirectional communications (eg: facebook), both 
technical and social, not the least being that the marketer has an 
enormous and irresistible incentive to cheat - as they already do (eg: 
bogus "testimonials" etc).

And furthermore, if they did implement a TINS that actually functioned 
(FSVOF), I think they'd be very disappointed by the turnout.

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 04 Mar 2010 15:34:29 +0000

--On 4 March 2010 09:16:06 -0500 Paul Russell <[email-masked]> wrote:

> The author is not interested in reducing or eliminating spam; he simply
> wants tools to validate his delusion that his spam is not spam.

Solicited marketing is not spam. For example, if I subscribe to my local 
cinema's weekly listings by email, then that email is solicited marketing. 
No problem there, as long as I can easily opt out again when I want to.

Furthermore, if the cinema has a variety of messages - weekly listings, 
film reviews, special offers, etc, then it would be a good idea to get 
feedback on what each subscriber likes, so that the cinema can target each 
message at people who like them.

Personally, I'd rather get that stuff from an RSS feed. But, it would still 
be nice if the feed had similar feedback mechanisms.

---

From: Barry Shein <[email-masked]>
Date: Thu, 4 Mar 2010 13:36:14 -0500

> tools to validate his delusion that his spam is not spam.

I'll reiterate into the mawing abyss: If he's not paying me to deliver
it, it's spam. Thumbs down.

   -b

---

From: Steve Atkins <[email-masked]>
Date: Thu, 4 Mar 2010 10:43:41 -0800

> it, it's spam. Thumbs down.

Then isn't all mail sent to your users spam, by that definition?

Cheers,
  Steve

---

From: Barry Shein <[email-masked]>
Date: Thu, 4 Mar 2010 13:46:16 -0500

> it, it's spam. Thumbs down.

I'll wildly guess I meant "yawning" not "mawing" which is only a word
in coffee-deficient-land.

   -b

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 4 Mar 2010 14:43:21 -0500

> in coffee-deficient-land.

I'll accept "mawing" as a short form for "into the maw of the".  Just 
this one time ;-)