ietf-asrg
[Top] [All Lists]

Re: [Asrg] Mailing list signup handshakes

2008-11-30 18:24:58
On Sun, Nov 30, 2008 at 11:40:46AM -0800, Michael Thomas wrote:
I think increased use of RFC 2369 headers and their corresponding
presentation would help; I've also considered the possibility of
making MUAs aware of proper opt-in signups (say, via RFC 2142 -request
addresses, which all all mailing lists should support), as it would leave
open the door for the MUA's to decline to present a "report as spam"
button while viewing any message on that list and instead present a
"request unsubscription" button (using the RFC 2369 headers) instead.
(Why do this in the MUA?  Because it's MUA behavior that needs to
be affected, and it needs to be affected even when the MUA is running
on a system that's not Internet-connected at the moment.)
  

   See, you've already lost me: I and I hope that just about everybody
   else has been conditioned to not trust those "unsubscribe" buttons
   because there's a pretty good chance that something actively evil will
   happen if you click it.

What I'm talking about -- in response to comments about UI improvements --
is an "unsubscribe" button that you only see if your own MUA knows that
you previously subscribed via a proper (COI) process.  I'm not overly
enthused wtih the idea by any means, but if we're going to think about
UI improvements, then *maybe* having the MUA try to keep track of
mailing list subscriptions is one of them.

(I do this is an entirely manual way: every mailing list I'm on gets
a procmail rule, and in that rule I make a note of the data I subscribed.
I also note when I unsubscribe and deactivate the rule.  But this is
clearly not for everyone.)

So I'm not getting why you're saying that a "Unsubscribe" button in the
MUA would be a good choice? It seems like we're likely in agreement, but
I'm confused.

I think we're in agreement -- I'm not sure it's a good thing either, but
I was trying to say that *if* we're going to give users "unsubscribe"
and "report as spam" buttons then maybe there are ways to at least make
them work better.

We're only marginally better than "If you learned to run a mass  spectrometer"
on the spam/phish front. Our automatons need to be *way* smarter, and to
the degree that we blame the user/victim is to the degree that we miss that
point.

Agreed.  I regard it as "our" responsibility to deal with the spam problem,
not end users'.  (And I don't blame them unless they do something that's
actively self-destructive, e.g., following spammer "unsubscribe" links.
I blame us.)

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