Subject: Re: [Asrg] Adding a spam button to MUAs

From: Rich Kulawiec <[email-masked]>
Date: Wed, 27 Jan 2010 07:47:27 -0500

On Thu, Dec 17, 2009 at 12:06:21PM -0500, Chris Lewis wrote:
> I explained that to RSK about a year ago.  Guess he forgot.

No, but I do think you're right *and* I'm right.

You're right about the statistics.

I'm right about end-users: there is no way that any end-user should
ever be permitted to classify anything as spam/not-spam. [1]  They clearly
haven't got the slightest idea how to tell the difference...because
if they DID, the scope of the problem we face would be much smaller.
(It would still be non-zero: it's clear that many spammers don't care
whether users receive, read, save, or respond to spam.)

---Rsk

[1] It might not be unreasonable to permit them the privilege of flagging
something for review by someone equipped with appropriate expertise, although
that has privacy implications that I'm not entirely comfortable with.

---

From: der Mouse <[email-masked]>
Date: Wed, 27 Jan 2010 09:42:11 -0500 (EST)

> [...] there is no way that any end-user should ever be permitted to
> classify anything as spam/not-spam. [1]

> [1] It might not be unreasonable to permit them the privilege of
> flagging something for review by someone equipped with appropriate
> expertise,

Um, the people "with appropriate expertise" are often themselves end
users (eg, most of this list), forcing me to question your "any".

Besides, in sokme cases, nobody *but* the end-user is competent to
judge unsolicitedness; the very same email can be spam to one recipient
(who didn't ask for it) but ham to another (who did).

/~\ 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: Ian Eiloart <[email-masked]>
Date: Wed, 27 Jan 2010 14:59:00 +0000

> whether users receive, read, save, or respond to spam.)

I'm an end user, as is everyone on this list, and I resent that remark.

> something for review by someone equipped with appropriate expertise,
> although that has privacy implications that I'm not entirely comfortable
> with.

Well, flagging is all we're talking about. The review mechanism could be at 
least partially automated. You're right to flag privacy as an issue, but 
it's already an issue given that there are already widely deployed 
mechanisms for end users to flag mail as junk.

What this thread is about is the creation of standards to support those 
implementations, if I remember well.

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

---

From: Steve Atkins <[email-masked]>
Date: Wed, 27 Jan 2010 07:40:00 -0800

On Jan 27, 2010, at 4:47 AM, Rich Kulawiec wrote:

>  there is no way that any end-user should
> ever be permitted to classify anything as spam/not-spam. [1]

Given that pretty much all operational definitions of "spam" are based
on whether the email was unsolicited or unwanted, and the recipient is
typically the only person who is likely to be able to tell whether a particular
piece of email is something they wanted or asked to receive, I'm
pretty sure you've got that wrong.

Cheers,
  Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Jan 2010 16:44:04 +0100

On 27/Jan/10 15:59, Ian Eiloart wrote:
> Well, flagging is all we're talking about. The review mechanism could be
> at least partially automated. You're right to flag privacy as an issue,
> but it's already an issue given that there are already widely deployed

TIS buttons should clearly convey this point: the message being 
flagged and _disclosed_ is perceived as abusive and unwanted, the 
sender is unknown to the recipient/reporter, and he or she delegates 
the community at large to take whatever action they may deem 
appropriate. No privacy issues beyond that point, except for possibly 
redacting the reporter's address.

> implementations, if I remember well.

Yes, but considerations on how to further route and munch those 
complaints are also interesting.

---

From: "Andrew Richards" <[email-masked]>
Date: 27 Jan 2010 15:48:21 +0000

On Wednesday 27 January 2010 15:40:00 Steve Atkins wrote:
> typically the only person who is likely to be able to tell whether a
>  particular piece of email is something they wanted or asked to receive,
>  I'm pretty sure you've got that wrong.

Surely there's no real problem if someone mis-classifies a message as spam 
or non-spam: If I'm providing a mail service I would like to aggregate 
results so that when the same message is classified as spam several times by 
different users I'll start blocking similar messages - either doing this 
aggregation myself if I'm a big ISP etc., or using an external service 
providing this functionality.

cheers,

Andrew.

---

From: John Levine <[email-masked]>
Date: 27 Jan 2010 17:22:00 -0000

>redacting the reporter's address.

That's a good summary.  The question I originally brought up was how
to add a spam button to normal MUAs that was functionally similar to
the one provided by all the big webmail systems.

All they need to do is somehow send the message, or a pointer to a stored
copy of the message, back to the user's own mail system.  The tricky bit
is that MUAs have separate configs for inbound and outbound mail, so you
can't just send the message via the outbound channel or you may be sending
it to someone who's never seen it before.  For IMAP you could either
have a special folder (what AOL does with its IMAP interface) or a new
flag, for POP you'd have to invent a crock of some sort.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Jan 2010 19:39:42 +0100

On 27/Jan/10 16:48, Andrew Richards wrote:
> or non-spam:

However, the possibility of retracting a (mis-)classification may be 
useful in some cases.

> If I'm providing a mail service I would like to aggregate
> different users I'll start blocking similar messages

Hm... it is not straightforward to establish whether new messages are 
/similar/ to already received ones. Checking an authenticated id, e.g. 
for messages received "with ESMTP[S]A", would be easier.

> - either doing this aggregation myself if I'm a big ISP etc.,
> or using an external service providing this functionality.

I'd be interested in the external service, not only because I'm not a 
big ISP, but also for the sake of neutrality, transparency, etc.

Obviously, it has to receive abuse reports... Perhaps not all the 
world's ones, just some. Which ones, by sending domain?

Is this service a Mythical Global Reputation System (TMGRS)?

---

From: Douglas Otis <[email-masked]>
Date: Wed, 27 Jan 2010 18:46:05 -0800

> pretty sure you've got that wrong.
1) End-users are not always able to determine where an email 
originated.  Even with Authentication-Results included, this header 
omits the source IP address of the message, leaving the actual source 
uncertain.  So who is to blame?

2) Not all unwanted email falls into a definition of spam.  
Unfortunately,  when provided a limited set of options, pressing a "This 
is Spam" button likely communicates a message as unwanted or is 
considered junk, even when from a mailing-list previously opted in, or 
perhaps an auto-response in language the end-user is unable to read.  
After all, not all recipients share a common native language.

End-users can be a poor judge as to what is spam.  Abuse desks receiving 
complaints of unwanted email need to ascertain whether there is evidence 
of spam, such as content clearly in the commercial interest of the 
sender, and not the recipient, etc.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 28 Jan 2010 06:42:31 +0100

> After all, not all recipients share a common native language.

Even worse, users will learn what the button means by the effect (they 
think) they obtain by hitting it, which may vary.

I'd consider bringing up a confirmation dialog when disambiguation is 
needed.

> sender, and not the recipient, etc.

One key point is to establish which complaints require human 
inspection and why. This can be done better deploying collaborative 
interchange with trusted senders.

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 28 Jan 2010 10:46:40 +0000

> flag, for POP you'd have to invent a crock of some sort.

POP isn't really susceptible to simple solutions, as you say, so let's 
focus on IMAP.

There seem to be four options, to me:

(a) define a new flag per message,
(b) define an ANNOTATE annotation per message,
    <http://tools.ietf.org/html/rfc5257#section-3.1>
(c) define an METADATA annotation on a mailbox,
    <http://tools.ietf.org/html/rfc5464>
(d) do something adhoc with mailboxes as is done for "spam" , "sent 
messages", "trash" and the like.

Are there any other possibilities?

(d) is the closest example that we have. It's used by the service provider 
to communication information about spam status to the user. Of course, that 
suggests a fifth option - rewriting the subject header (but I almost wish I 
hadn't thought of that!). I can't think of examples where flags or 
annotations are set IN ORDER to facilitate communication between user and 
provider.

My preferred option would be (b) because (i) it's more flexible than a flag 
(eg, it *could* be used to distinguish between 'block' and 'report' 
requests if both the user and the admin desire) (ii) it preserves the 
information about location of the message, which makes "undo" easier than 
moving the message into a different mailbox, (iii) ANNOTATE has 
experimental RFC status, whereas ANNOTATEMORE is

The drawback of (b) is that it creates a client side user interface 
problem. Presumably the user doesn't want the inbox full of messages that 
have been reported. There needs to be a way for the message to be preserved 
for inspection by the admin, but hidden from (yet findable by) the user.

If defining new annotations, it might be useful to define them for other 
special maiboxes, too.

---

From: John Levine <[email-masked]>
Date: 28 Jan 2010 17:31:12 -0000

>think) they obtain by hitting it, which may vary.

Web mail has had spam buttons for years, and the users seem to have
figured out how to use them.  Can you explain exactly how the issues
with a spam button in a MUA would be different?

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

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 28 Jan 2010 09:41:03 -0800

> with a spam button in a MUA would be different?

The entire thing strikes me as rather elitist: like only Certified Spamologists(tm)
can determine for you what you don't want to receive.

Of course, they completely miss the point: whether something is Objectively spam or
not isn't solving the problem that I as a user have. Spam is just ONE KIND of thing
I don't want to receive. There are many, many other classes and thus far only Baysian
stuff has come close to approximating my actual problem. The Certified Spamologists
just don't get that.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 28 Jan 2010 10:48:24 -0800

> can determine for you what you don't want to receive.
The issue whether a source issued spam or an email someone did not want 
is significantly different.  This is a greater concern for senders, and 
less so for individual recipients.  When this information is used to 
establish spam reputations used for blocking, then not describing 
auto-responses in Chinese as spam would be important.   In general, it 
would be safer to describe email marked by end users clicking "This 
is..." buttons, as only determining the message as unwanted for 
undetermined reasons, where it being spam is one possibility.  As such, 
describing the end-user button and the information obtain as 
identifying  the email as "junk" rather than as "spam" is likely to be 
more accurate from both the sender's and the law's perspective.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Thu, 28 Jan 2010 11:03:29 -0800

On Jan 28, 2010, at 10:48 AM, Douglas Otis wrote:

> The issue whether a source issued spam or an email someone did not want is significantly different.  This is a greater concern for senders, and less so for individual recipients.  When this information is used to establish spam reputations used for blocking, then not describing auto-responses in Chinese as spam would be important.   In general, it would be safer to describe email marked by end users clicking "This is..." buttons, as only determining the message as unwanted for undetermined reasons, where it being spam is one possibility.  As such, describing the end-user button and the information obtain as identifying  the email as "junk" rather than as "spam" is likely to be more accurate from both the sender's and the law's perspective.

Most of the people I see arguing that the "this is spam" button isn't
a good user interface for users to provide their thoughts are spammers
or grey area bulk mailers.

There's a smattering of operationally inexperienced anti-spam nuts,
and dilettantes who have nothing more productive to do than argue about the
wording of AOLs user interface and the colour the AOL bikeshed should be
painted, but it's mostly spammers and dirty bulk mailers.

Most everyone else involved seems reasonably satisfied with it, which
suggests that the overall approach is probably quite effective. Even the
grey area bulk mailers seem fairly happy with the data they get, even while
the guys they hire to push their agendas are arguing about TiS semantics
in public.

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Thu, 28 Jan 2010 11:14:35 -0800

> the guys they hire to push their agendas are arguing about TiS semantics

I'm trying to figure out whether your post is responsive to my point or not.

I can't.

Mike

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 28 Jan 2010 18:13:42 -0500

> I'm trying to figure out whether your post is responsive to my point or not.

I think he was agreeing with you.  I agree with both of you, even if he
wasn't exactly responsive to yours.

Frankly, I think the vast majority of people who thing TiS are bad are
either people who have an incentive to consider them bad, or are largely 
unaware of how they're actually used, or are expecting some sort of 
one-to-one reaction/theoretical purity to every TiS hit.

Score 'em statistically.  Whitelist when they goof.  Humans make 
mistakes.  And sometimes they're right when the filters aren't.  Design 
for it, including methods to intervene when necessary.  No big deal.

Humans evaluate every TiS hit?  That's nuts.  Even in our environment 
(corporate).

It may or may not be a significant part of your filtering arsenal.  With 
us it isn't anymore.  It used to be.  But catches some of the more 
extreme unusual things.

Sure, I have to explain sometimes that TiS'ing three copies of a bot 
spam doesn't necessarily prevent the fourth.  A week ago I had to 
explain why we blocked one of our biggest customers momentarily (looks 
like someone was trying to C&P a bunch of emails into another mailbox, 
and hit the wrong button.  So I selected all the blocked mail and 
forwarded it a few hours later.).  It's no big deal.  Doesn't happen 
often enough to agonize over.  Laugh resignedly.  Make a joke or two. 
Move on.  I've even trained my managers to do it on my behalf.

And occasionally the TiS feedback loop saves your ass.

Our system is set up that it's better to intercept a few good emails, 
than let something nasty thru.  The blocked emails can be forwarded as 
if nothing happened.  The dangerous ones that got thru can't be recalled.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Jan 2010 11:05:41 +0100

>>>>  with a spam button in a MUA would be different?

Because some ISPs' sizes result in vanishing likelihoods that Alice 
and Bob share the same server (see the "ideal" FP example). Nor we can 
expect smaller ISPs to implement FBLs on their own initiative...

> painted, but it's mostly spammers and dirty bulk mailers.

These statements are highly enlightening! They implicitly contain an 
explanation of why we cannot define the term /spam/, and what kind of 
hypocritical equilibrium results from coloring bulk mailers with 
various shades of gray. Since marketers want to send ads and users 
don't want to receive them, MTA operators can pretend there is no 
conflict and provide a direct-to-junk channel. Is everybody happy with 
this [non-]solution?

IMHO it doesn't work very well: First, because ambiguity undermines 
reliability. Second, because users have no direct control.

---

From: Martijn Grooten <[email-masked]>
Date: Fri, 29 Jan 2010 12:37:33 +0000

> for it, including methods to intervene when necessary.  No big deal.

Out of curiosity, have your users been instructed on how to use the TiS buttons (and to use them in the first place, instead of just clicking delete) or do you just trust them to do the right thing (most of the time)? And do you think it would scale to larger, more anonymous organizations such as ISPs?

Unrelated to that, if most MUAs got a TiS-button, wouldn't this allow spammers/botherders to effectively DDOS the systems that process the feedback, thus making them (temporarily) useless? I could see why spammers would see an advantage in doing that.

Martijn.

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

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 29 Jan 2010 12:37:47 +0000

> or grey area bulk mailers.

Maybe the problem is that buttons aren't, in the general case, for applying 
labels. They're for initiating actions (which might include the application 
of a label).

The button should make clear what the action is. Will it stop similar mail 
being delivered to my mailbox? Will it stop similar mail being delivered to 
a colleague? To the rest of the world?

Will it result in a report being sent to the system administrator? To the 
sender? To the sender's boss? To Spamcop? To the police?

Is clicking the button an instruction, a request, or a vote to take any of 
those actions?

Can we use IMAP meta-data to communicate answers to these questions, to the 
user?

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 29 Jan 2010 08:44:51 -0500

> can determine for you what you don't want to receive.

Not quite.  But maybe so.

We don't (at least I sure *hope* we don't) permit users to determine which
packets will/won't be permitted into our networks.  We set those policies
to maximize security, because we recognize that malicious/dubious network
traffic is a threat.  So for example, we might have in place a mechanism
which begins to reject ssh connection attempts after a certain number of
failures.  There is no real difference between that and rejecting SMTP
traffic -- recognizing that spam is *also* a security threat -- other than
the application protocol involved.

Users are not qualified to make decisions about (for example) SSH traffic
management in perimeter firewalls.  Nor are they qualified to make decisions
about about SMTP traffic management in mail servers.  That is why they
are users and not network/server managers.  (They probably get to make
some other decisions that network/server managers don't.  It works both
ways: each according to their expertise and responsibilities.)

This is NOT the same thing as determining for a user (to go back to your
remarks) what "[they] don't want to receive". That's a personal preference
and users are of course free to formulate/express it as they wish.

I don't think this is elitist, I think it's a matter of recognizing that
the spam/not-spam classification process requires expertise *vastly* in
excess of that possessed by almost all users.  This is not their "fault"
per se because it's not a fault: it's simply a lack of area-specific
experience and knowledge.

---Rsk

---

From: Michael Thomas <[email-masked]>
Date: Fri, 29 Jan 2010 09:23:38 -0800

> the application protocol involved.

This is a strawman argument: nobody's saying that users should be the 
sole decider
of network badness. What you said however is that users should have NO 
INVOLVEMENT
in deciding what network things they want/don't want. In this particular 
case, the "don't
want" is the form of a button that users can express their displeasure 
that ultimately
effects some filtering goodness.

> excess of that possessed by almost all users.  
The problem I have here is that your taxonomy has SPAM and HAM branching 
out very
early from the tree of email, where only paelospamologists with the 
proper qualifications
ought to be given any credence as to where they fit in the family tree. 
My position is that
the entire idea of this taxonomy is silly, and the paleospam theory is 
not very helpful in the
larger problem of "filter mail I don't want to see". The theory does 
lead to a full employment
act for the paleospamologist priesthood though. Giving the laity any say 
is a threat, even though
the laity is the only place you can possibly get the raw input for the 
filtering we want rather than
what is given to us on high.

The question should always be: "does user X want this mail?" rather than 
"this mail is spam/ham
in absolute terms". The sooner we get beyond the paleospamogist 
priesthood, the sooner we get
on with the actual job of building products for its users rather than 
the various other vested interests.

Mike

Mike

> This is not their "fault"

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 Jan 2010 10:03:31 -0800

> experience and knowledge.
Well said.  Labeling a feedback button as "this is junk" (TIJ) avoids 
inaccurately describing its identification as absolute indications of 
the purported sender having sent spam.  Often within the feedback, who 
the sender is remains uncertain as well.  Even the Authentication 
Results header fails to capture the important IP address seen at the 
administrative border needed to identify the immediate sending 
administrative entity.

Of course, any email administrator receiving negative feedback 
describing a problem should ascertain its nature, and take corrective 
steps when found abusive.  Unfortunately, even when accurate and 
prioritized information of spamming is provided, administrators instead 
tend to rely upon their own actionable criteria, where even strong 
evidence is often dismissed.  After all, dealing known spam sources 
likely involves customers having 0wned systems or accounts.  Often the 
response is we don't see any problem.

Perhaps when TIJ correlates with actual spam detections, administrators 
might find themselves with fewer excuses.  This issue is growing in 
importance, because bad actors are getting better at compromising 
accounts as well as customer's systems.

-Doug

---

From: Bart Schaefer <[email-masked]>
Date: Fri, 29 Jan 2010 10:08:19 -0800

On Jan 29,  9:23am, Michael Thomas wrote:
}
} The question should always be: "does user X want this mail?" rather
} than "this mail is spam/ham in absolute terms". The sooner we get
} beyond the paleospamogist priesthood, the sooner we get on with the
} actual job of building products for its users rather than the various
} other vested interests.

I think the trouble here is that there are actually two different
problems being conflated.

Mike is focused on the problem of making the users happy, which means
both eliminating content they don't want to be bothered with, and *not*
eliminating content they find desirable.

Rich is focused on the problem of network maintenance and security,
which means eliminating unwanted/malicious traffic as early as possible 
and with minimal disruption to the important/innocuous traffic.

These two foci are in conflict.  For Rich, it's obvious that end users
have limited expertise in distinguishing undesirable traffic; and to
allow the users to express their opinion, he must first allow that
traffic to pass, which is unacceptably dangerous, possibly disruptive,
and violates the "as early as possible" constraint.  Only an absolute
classification helps to solve Rich's problem.

Rich may be overly dismissive of Mike's problem, but to declare concerns
about maintenance and security to be anachronisms not part of the "actual
job" is to repeat the mistakes of the past.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Jan 2010 19:45:29 +0100

> POP isn't really susceptible to simple solutions, as you say, so let's

I really would leave this bit out for the time being. Avoiding to 
upload the message is a minor optimization that can be carried out any 
time. (Compare it with saving sent mail by BCC rather than uploading 
the same message twice.)

IMHO it is more important to focus on _how_ and _where_, the answers 
being, respectively, ARF and abuse@<authserv-id>, where the latter is 
defined in http://tools.ietf.org/html/rfc5451#section-2.3 Note that 
users have to configure their clients specifying which authserv-id 
they trust for each account. This stone can kill both birds.

> Are there any other possibilities?

The IMAP UID is used to refer to a specific message (rfc5092), which 
is what could be used with BURL (rfc4468) to optimize reporting when 
the IMAP server can also be used as an MSA.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 29 Jan 2010 12:37:55 -0800

> classification helps to solve Rich's problem.

no, no, no, you misunderstand me. I'm not saying that prefiltering is 
bad. far from it.
this started out with the claim that end users with their TiS buttons 
are between useless
and dangerous. Users may not get all bad things (duh), but they also 
know a heck of a
lot more about what they don't want than some system-wide classifier 
that is BY DESIGN
allergic to false positives.

And I'll take issue with "only absolute classification helps solve 
Rich's problem." In fact,
users on a day 0 exploit are your only line of defence so you better 
damn well hope that
some percentage of them push the panic button, and you'd be foolish to not
build systems that take those early warnings into account.

The point i'm making is that the user MUST be a part of the larger 
problem of managing
their own firehose. The absolutist "spam/ham"-must-be-part-of-priesthood 
is but one way
to achieve a level of filtering with relatively few false positives, but 
it is not the whole
picture.  The whole picture is "don't show me what I don't want to see".

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 Jan 2010 14:58:19 -0800

On 1/29/10 12:37 PM, Michael Thomas wrote:
> their own firehose. The absolutist 
> "spam/ham"-must-be-part-of-priesthood is but one way
> to achieve a level of filtering with relatively few false positives, 
> but it is not the whole

Mike,

It really depends upon how feedback is applied.  When applied globally 
and not for the individual offering the feedback, then this _will_ cause 
false positive detections.  You are right, this type of information does 
provide early indications that content filtering is failing to detect 
some new spam variant, but then this requires human intervention to repair.

What I don't understand is your desire to muddle with spam definitions 
calling the feedback "This is Spam" and not "This is Junk".  Calling it 
junk accurately describes how it is used, and what it ultimately means.  
You don't need to be part of priesthood to understand what might cause 
false positive blocking of otherwise legitimate messages.

Recently,  our group made this mistake of mis-applying this type of 
feedback, where the confusion appeared due to the sloppy labeling of 
feedback as "spam" when it really meant, "not wanted".  Not wanted is 
usually the output of any content filter as well,  the result of the 
filter's training.

-Doug

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 29 Jan 2010 23:26:23 -0500

> Out of curiosity, have your users been instructed on how to use the TiS buttons (and to use them in the first place, instead of just clicking delete) or do you just trust them to do the right thing…

The "TiS" button is, in effect, an email forward to a specific robot 
process.  Except for Outlook which mangles things up too much, but 
Outlook is unfortunately the corporate standard for most people.  In 
that case, we supply a plugin that knows how to forward full emails 
without mangulation.

We pretty much only mine it for IP addresses.

Instructed our users?  Well, it started out ad-hoc, and it largely still 
is.  There are various employee communications that have gone out over 
the years that tell people to forward spam to it.  Never formally enough 
to remotely be considered "training" Never particularly detailed in 
terms of "don't report grandma", etc. The only "fine tuning" we've ever 
done is "if you're getting very large quantities of the same thing, let 
us know <here> instead", and "if it's spammish behaviour from Nortel 
itself, report <there> instead".

The first of those is the role account, and we'll look into an 
individual users problem to see if we can do something about it.  The 
second hasn't been used in ages.

Oh, and yes, we've told them to discard and ignore blowback unless the 
volume is extreme, and we'll put in a recipient-specific blocking of 
inbound bounces.

But it's still mostly skunk works, and as it wasn't part of the common 
O/S release, it didn't get as widely used as it should have.  We did get 
quite high compliance rates at one point (perhaps nudged the 1 in 10 
spams got reported level), but that's more of a corporate vs. ISP thing.

> Unrelated to that, if most MUAs got a TiS-button, wouldn't this allow spammers/botherders to effectively DDOS the systems that process the feedback, thus making them (temporarily) useless? I could…

Various DOSes are available - eg: flooding and reputation poisoning with 
FPs.  As it exists now, much depends on the per-site implementation 
strategy.  The big guys probably already have it handled, perhaps as a 
native part of their TiS handling, perhaps as active remediation.  We've 
not done much, but it would be really hard to do something that would 
cause me more than a few seconds work to deal with permanently, and all 
damage can be undone.  In terms of outright volume, you're attacking our 
MTAs, and that's fairly hard to break considering the head room we 
operate with.  Full scale whole bot army attack like a Storm Worm 
retaliation?  Well, you have that issue anyway.  And we've already 
demonstrated we can ride out a Storm DDOS without significant impairment.

[If Storm was still around we were all set in terms of approvals nnd 
technology to "get in its face" and do it serious damage.  But Storm 
chickened out ;-)[*]

With a "common" TiS mechanism, of course some time would have to be 
spent on hardening it.

[*] Provoke it to attack us deliberately.  Use the resulting intel to 
<I'm not going to say>.  Storm died instead.

No, of course that wasn't really why it died.  But it makes a good story ;-)

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 29 Jan 2010 23:42:41 -0500

> experience and knowledge.

You seem to be seeing it only as "a single ordinary user making 
site-wide decisions on what to block" versus "totally ignoring what the 
users say" choice.

If that binary choice was the only choice, I'd agree with you.  I have 
enough horror stories of goofs in that regard.  Hell, I have enough 
horror stories when the alleged expert (me) screws up good.

But that is _not_ the choice.  Acting as if it is is at least mistaken. 
  TiS buttons aren't implemented that way.

_Nobody_ is talking about individual ordinary users making site-wide 
decisions of what to block.  That requires very high levels of expertise 
as you say.  But there is absolutely nothing whatsoever wrong with 
taking note of what those individual users are saying, and using it in a 
statistical fashion to guide your filtering.  That is how TiS buttons 
are used in infrastructures large enough to bother with them.  It is, 
after all, how Spamcop was originally implemented, and it's still part 
of their decisioning process albeit less than it used to be.

There are non-user-driven DNSBLs less useful than Spamcop ;-)

If we were to specify/standardize/or even (gasp) implement a common TiS 
strategy/implementation that actually drives filters, the crucial part 
is coming up with a "filter decisioning" strategy that the admins can 
tune, and has reasonable defaults.

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 29 Jan 2010 23:56:40 -0500

> classification helps to solve Rich's problem.

Your description actually means that nothing can be blocked without a 
user first saying it should be blocked.  IOW, the foci you've described 
can't block, ever, because the user hasn't told you yet it's bad, and by 
the act of seeing it, the choice to block or not is moot.

That's obviously silly.

Remember: TiS buttons are intended to catch those things that your 
filters didn't _already_ capture.  They're to refine your filters for 
future repeats of the same thing (however "same" is defined).  _Not_ 
_be_ the filters.

If the filters can tell something is bad, you block it, no matter how 
you've determined it to be bad.  No TiS hits necessary.

TiS is an _adjunct_ to your filtering strategy.  Not the whole thing.

> job" is to repeat the mistakes of the past.

Mike is not dismissing it.  I certainly ain't, because I have to 
maintain and secure the darn thing.  TiS buttons certainly don't 
compromise our maintenance and security.