On Fri, Jun 10, 2016 at 11:23 AM, Laura Atkins <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 :) 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. 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.
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
