> On Jun 10, 2016, at 12:56 PM, Bill Cole > <mailop-20160...@billmail.scconsult.com> wrote: > > On 10 Jun 2016, at 11:23, Laura Atkins wrote: > >> In this case, having read the documents and followed the public discussions, >> there’s no real clear benefit. There is also a lot of expense. So that’s a >> problem. The benefits need to be better articulated by the people who want >> to make the change. > > Yes, indeed: this unicorn's horn is inadequately polished. > > More directly: I don't think any "One Click Unsubscribe" can be a net benefit > for the parties who would need to do the most work to implement and deploy > it. As someone whose job security is improved by the proliferation of arcane > external/interop email failure modes, I'm not saying that out of > self-interest.
The unicorn has already left the barn. Two major webmail providers are using the List-Unsubscribe header to place unsubscribe links in the message display window along with headers like To:, From:, Reply-To: and Date: So the work has already been done to decide that having a header that shows an unsubscribe process is a net benefit. Most ESPs use the List-Unsubscribe header. Two major ISPs take that header and use it to automate unsubscribes mediated by the MUA. Clearly, at least some of the parties involved have decided its a net benefit. But the implementation isn’t standardized and there is some unexpected behavior happening. Thus, coming up with a clearer spec about what is intended is a good idea. But I think the work was inadequately scoped. These issues that we’re discussing here are obvious. Addressing them is vital both to foster interoperability and to drive adoption. >> 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. > > Exactly. If a well-intentioned, prudent, and wise organization implements a > protocol into being an opaque "Just Do What I Want" button in a way that > behaves as the protocol envisions, there will be malicious, reckless, and/or > stupid entities deploying implementations that behave badly and/or facilitate > malicious use within days. That’s what’s currently happening and was the issue this document was supposed to address. The problem is this document inadequately addresses the current issues. Further, it introduces new failure modes creating even more chaos. > The result is that by hiding a complex protocol behind the face of a > "one-click" unsubscribe button, you create a whole new collection of subtle > and obscure ways that various implementations can quietly and rarely operate > incorrectly. Unsubs that should not occur WILL. Unsubs that should occur WILL > NOT. Users will expect their personal and workplace mail systems to give them > identical experiences of the new protocol, which mostly WILL NOT happen. Again, this is already happening. I agree the current proposal will lead to more opportunities for screw up. But not doing anything is a less than adequate resolution. There does need to be clarification on how best to show an unsubscribe through the MUA. The current solution has problems, but consumers like it, so it’s presence is something we need to deal with. I’d just like to see a better solution. 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
