> On Jun 10, 2016, at 9:07 AM, Vick Khera <vi...@khera.org> wrote: > > > On Fri, Jun 10, 2016 at 11:23 AM, Laura Atkins <la...@wordtothewise.com > <mailto:la...@wordtothewise.com>> wrote: > Also in this case, there is a significant chance that the proposal will > result in sub-optimal or harmful results. It is a fact that there are > appliances and filters out there that follow every link in an email. > Implementing a protocol where a link being followed means a user is > unsubscribed immediately will result in people being unsubscribed. I > understand this proposal makes whatever is automatically clicking the link > append a magic token to the URL, in an effort to stop this. I think that > makes the proposal overly complex and fragile. > > > I kind of like Tobias' proposal (not just because we've thrown back a lot of > beers...) > > The way I interpret it is that naive and current filters will just follow the > URL as-is. The anchor will just be mostly ignored by the landing page, where > you would normally then have to click a "confirm" button on that page. If, > however, your ISP (or mail user agent) detects this magick one-click anchor > and rewrites it for the user to click with the params appended, then it > becomes converted into a one-click unsubscribe by the landing page. The key > is that the automated scanning stuff will (and should) not do any rewriting. > If some filter scanner decides to do the rewrite then all bets are off, and > they should be punched in the face :)
There are a lot of things filtering scanners do that deserve a punch in the face. (Like, for instance, following COI links and then listing the sender on a blacklist when they’re done.) But having the anchor added by the MUA / ISP is fragile. It also means that code needs to be rewritten on both ends - the ESP and the ISP. There are other ways to do this. People here have suggested them. > The beauty of the proposal is that you can with some cooperation of the mail > user agent convert the two-click unsub into a one-click. And the failure of this proposal is that it requires the MUA to change current behavior without a clear benefit to doing so. It also means there can be no partial adoption or roll out. ESPs and ISPs need to coordinate on a flag day for the new changes. All of this makes it a hard sell for a lot of people. > I also am not 100% in agreement that "GET" for HTTP means no altering of > state. I think that's a recent convention coming over from REST based APIs. That’s something for the more technical audience to argue, I’m not the person to do it. But from my reading of the RFCs GET is absolutely the wrong verb to use. laura -- Having an Email Crisis? 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
