ietf-asrg
[Top] [All Lists]

Re: [Asrg] Adding a spam button to MUAs

2009-12-31 13:28:10
Michael Thomas wrote:
Nathaniel Borenstein wrote:

Absolutely -- the report-spam UI will almost certainly be better if it's integrated with the MUA and agnostic regarding the spam engine receiving the report. The only major open question I'm hearing is how much information that report should contain. Clearly it should be no more than the number of bits that the user himself can be relied on to provide, where our differing opinions might be resolved via user studies.

Different mailbox providers may process reports in widely different ways. While UI's behavior is agnostic, its configuration may refer to specific functionalities that the underlying spam engine may or may not support.

It might also be worth considering offering 1 button to most users, but 2 buttons to users who understand the distinction well enough to change a default in their MUA in order to get 2 buttons instead of 1. I conjecture that the users who would take that action would have a much lower error rate than the average user. In that scenario, most users would send back a single bit "unwanted" message, but sophisticated users could send back two (or even more?) types of "unwanted" message. That might be the cleanest data we could hope to get.

Sophisticated users may choose a mailbox provider according to what functionalities it offers. Conversely, ISPs may offer different functionalities in order to attract different kinds of users. A good MUA should support them all.

I think the problem is that if you open it up to more than one bit, it begs the question of what the actual number of bits such a button is. I'd say that it's probably got a lot of bits -- far more than is likely that any user could be bothered with.

Assuming that the MUA will use ARF, the number of bits that can be stuffed in there is defined by that format and its extensions.

Want/don't want is nice in its simplicity, and I suspect it's about as much as you can expect from users. [...] I think that if we stopped with this absolutist campaign of "spam/ham" (most of us are not on some paladin's quest against the evils of spam, after all) and focused more on the context sensitive job of prioritizing mail, we'd all be a lot better off.

"Ham/spam" is not any better than "wanted/not-wanted", as far as coherence is concerned. "Legitimate/abusive, w.r.t. applicable privacy laws" would perhaps be clearer.

Rather than campaigns, it is a question of functionalities. Servers who support mail priority should be able to use reports for that sake. Ditto for block or unsubscribe. MGRSs might provide for one additional functionality: ban the sender from sending for an amount of time proportional to the number of complaints. I'd consider the latter an exercise of direct judicial process.

_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg