headers
Ian Eiloart | 1 Mar 2010 12:52
Picon
Favicon
Gravatar

Re: Summary of junk button discussion


--On 27 February 2010 14:08:37 +0100 Jose-Marcio Martins da Cruz 
<Jose-Marcio.Martins <at> mines-paristech.fr> wrote:

> Alessandro Vesely wrote:
>> On 27/Feb/10 07:22, Chris Lewis wrote:
>
>>
>>> I'm aiming for a specification that permits a single <user action> to
>>> communicate upstream for _both_ filtering and reporting purposes,
>>> where whether it's used for filtering or reporting or both in any
>>> given instance is up to the site admin and/or end-user.
>>
>> +1, and I would welcome an efficient IMAP implementation in that sense.
>> However, the spec should also allow to just send complaints.
>
> +1. "upstream communication is the idea". It's up to the (email
> address|device|...) to interpret how to interpret it and what to do with.

This is very sensible, but when you say "single <user action>", are you 
voicing support for the notion that only a single bit of data will be 
transmitted? Or will the vocabulary be richer than that? How about an 
extensible vocabulary?

For example, User Agents also have spam filters. It might be useful for 
such a filter to be able to make reports back to the administrator. Also, 
the user or the user's filter might want to say "this is not junk". Thus we 
have at least four messages that we might want to communicate to the admin. 
And, that's before we allow the user to express views on the type of junk 
that's present (boring versus offensive or potentially criminal).
(Continue reading)

Permalink | Reply | 3 comments |
headers
John Levine | 1 Mar 2010 20:25

Re: Summary of junk button discussion

>This is very sensible, but when you say "single <user action>", are you 
>voicing support for the notion that only a single bit of data will be 
>transmitted? Or will the vocabulary be richer than that? How about an 
>extensible vocabulary?

If it sends an ARF report, you can put whatever you want in the ARF,
although I wouldn't want to attempt to standardize a lot of stuff that
nobody uses.  We already made that mistake with ARF, and one of the tasks
of the MARF WG is to strip out the useless crud.

>For example, User Agents also have spam filters. It might be useful for 
>such a filter to be able to make reports back to the administrator. Also, 
>the user or the user's filter might want to say "this is not junk". Thus we 
>have at least four messages that we might want to communicate to the admin. 
>And, that's before we allow the user to express views on the type of junk 
>that's present (boring versus offensive or potentially criminal).

After years of experience with webmail junk buttons, the only messages
they've found useful are "junk" on regular messages and "not junk" on
stuff in the junk folder.  I don't see why MUA users would be any
different.  If you want to encode stuff in the ARF report to say whether
the opinion is from a human or from software, you can, although it is
again not clear how useful that would be.

R's,
John
Permalink | Reply | 2 comments |
headers
Alessandro Vesely | 2 Mar 2010 09:52
Picon
Favicon

Re: Summary of junk button discussion

On 01/Mar/10 20:25, John Levine wrote:
>> This is very sensible, but when you say "single<user action>", are you voicing support for the notion
that only a single bit of data will be transmitted? Or will the vocabulary be richer than that? How about an
extensible vocabulary?
>
> If it sends an ARF report, you can put whatever you want in the ARF, although I wouldn't want to attempt to
standardize a lot of stuff that nobody uses.

But what is the relationship between the report and the button? 
Apparently, "single<user action>" excludes automated reports.

> If you want to encode stuff in the ARF report to say whether the opinion is from a human or from software, you
can, although it is again not clear how useful that would be.

That field may be useful in sorting out a report's consumers in a 
generalized FBL. Some mailbox providers notify via FBL when users hit 
that button, but not when messages are automatically blocked.

Also, humans make errors in a different way than software, hence any 
correction mechanism should be differently tailored.
Permalink | Reply | 0 comments |
headers
Ian Eiloart | 2 Mar 2010 11:49
Picon
Favicon
Gravatar

Re: Summary of junk button discussion


--On 1 March 2010 19:25:08 +0000 John Levine <johnl <at> taugh.com> wrote:

>
> After years of experience with webmail junk buttons, the only messages
> they've found useful are "junk" on regular messages and "not junk" on
> stuff in the junk folder.  I don't see why MUA users would be any
> different.  If you want to encode stuff in the ARF report to say whether
> the opinion is from a human or from software, you can, although it is
> again not clear how useful that would be.

To me, as an administrator, I'd give more weight to a human opinion. In 
part, that's because the human is less likely to actually see a message 
that the client filter had spotted. It's the hard to spot email that I want 
to inspect.

I still want to know why Twitter's experience - which distinguishes between 
"block" and "report" isn't useful in this context. They seem like clear 
distinctions to me, and they're verbs, not adjectives, so they make 
explicit the resultant action. For privacy reasons, I think it's important 
that people are aware that a report is being made.

Now I think of it, "junk" is a verb, too, so its use in a button could 
easily be misinterpreted as equivalent to "trash" - less strong than either 
"block" or "report".

--

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rich Kulawiec | 2 Mar 2010 14:18

Summary/outline of why the junk button idea is pre-failed

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
(Continue reading)

Permalink | Reply | 33 comments |
headers
Daniel Feenberg | 2 Mar 2010 14:40
Favicon

Re: Summary/outline of why the junk button idea is pre-failed


On Tue, 2 Mar 2010, Rich Kulawiec wrote:

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

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

>
> 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
(Continue reading)

Permalink | Reply | 12 comments |
headers
Jose-Marcio Martins da Cruz | 2 Mar 2010 14:52
Picon
Favicon

Re: Summary/outline of why the junk button idea is pre-failed


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:
> 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
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alessandro Vesely | 2 Mar 2010 15:46
Picon
Favicon

Re: Summary/outline of why the junk button idea is pre-failed

On 02/Mar/10 14:40, Daniel Feenberg wrote:
> On Tue, 2 Mar 2010, Rich Kulawiec 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.

>> 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.
>>
>
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rich Kulawiec | 2 Mar 2010 15:55

Re: Summary/outline of why the junk button idea is pre-failed

On Tue, Mar 02, 2010 at 02:52:30PM +0100, Jose-Marcio Martins da Cruz wrote:
> 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.

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alessandro Vesely | 2 Mar 2010 16:44
Picon
Favicon

Re: Summary/outline of why the junk button idea is pre-failed

On 02/Mar/10 15:55, Rich Kulawiec wrote:
> 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*.

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

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

What is the similarity between SAV or similar "callback" mechanisms 
and reporting something as spam?
Permalink | Reply | 0 comments |

Gmane