Re: [Asrg] Adding a spam button to MUAs

[Douglas Otis <[e-mail]>]

On 12/17/09 10:34 AM, Nathaniel Borenstein wrote:
> There's a difference between having an "A or B" bit, and having
> separate "A" and "B" bits that may be muddled.  If you don't know the
> right way to interpret the two bits, then the single bit is
> potentially much less misleading.
>
> But as I said, this is something that could really be resolved by
> empirical study, and I'd prefer not to trust my intuition or anyone
> else's if we can figure out the facts about how people would actually
> use two buttons.  If the error rate is low enough, then two buttons
> will make sense, but I've rarely managed to underestimate the
> competence of the average user.   Two buttons is way more than twice
> as confusing as one, in this case.  -- Nathaniel
>
> On Dec 17, 2009, at 1:25 PM, Seth wrote:
>
>> Nathaniel Borenstein<[e-mail]>  wrote:
>>> On Dec 17, 2009, at 11:27 AM, Ian Eiloart wrote:
>>
>>>> Twitter seems to think that users are smart enough to
>>>> distinguish between "unwanted" and "spam". They give you a
>>>> button for each. It's an important distinction that most people
>>>> can make.
>>>
>>> Twitter isn't always right, and my intuition differs from yours
>>> on this one.  Fortunately it's something that could be resolved
>>> empirically.  I'd like to see such a study, because it wouldn't
>>> take very many users who *can't* properly make that distinction
>>> to render the two-button solution counterproductive.  I'd rather
>>> have one bit of meaningful data than two bits of muddled data.
>>> -- Nathaniel
>>
>> One button is the "OR" of the two buttons, so there's no less
>> information available.  Given enough data, it should be easy to
>> get pretty accurate statistics on how reliable _each_ user is, and
>> the unreliable ones can be mapped into the one-button treatment.

Agreed. After all, can users recognize an auto-response in Chinese, or
know the difference between real or spoofed DSNs?  Of course not.

All that can be determined from user feedback metrics is that 'X' number
of messages from some source were "unwanted".  Filters can be trained at
removing "unwanted" for specific users based upon their feedback,
however this information's usefulness is limited without knowing overall
source volumes, and whether messages might have been either foreign
language auto-responses, or valid DSNs.

Having "unwanted" considered equivalent of "spam-trap" feedback will
create a number of complaints, especially when dealing with a diverse
range of users.  Spam-trap email-addresses do not solicit email and are
good at excluding auto-responses and valid DSN.  This allows spam-trap
feedback be applied over a larger range of users with less regard to
overall source volume.  Unfortunately, since no provider is able to
ensure all customers are not 0wned, even "spam-trap" feedback can
benefit when overall volume is shared.

Our process consolidates metrics for all activity seen from each
specific source and evaluates related metrics in a non-linear fashion.
Offering this information within ARF feedback would not entail a sizable
increase in report size to include a field of "source activity rate" as
a method to share the number of message events (good or bad) seen over
some number of seconds.

Volume metrics added to an ARF report might look something like:

IP-Activity: [source-IP], [#messages], [#seconds];
DKIM-Activity: [d=], [#messages], [#seconds];

Such as
IP-Activity: 192.0.2.128,34566,86400;
DKIM-Activity: example.com,4013,86400;

When metrics are passed through a feedback conduit, each source should
be qualified as representing spam-trap feedback, or user feedback, where
feedback metrics from multiple sources would be consolidated into at
least two separate categories.

-Doug