> On Jun 10, 2016, at 4:10 AM, tobias.herk...@optivo.de wrote: > >> I think it is an insufficient solution that potentially allows a >> security device developer or service to build one click URLs just as >> easily as the ISP could. So it's got two things that I don't like. >> 1- You're requiring the ISP to identify and include a token in the URL >> - I don't think they should have to build something. >> 2- What's being built is just as easily added in by any security >> device who decides they know better than the subscriber and want to >> cause that unsubscribe. >> >> Cheers, >> Al Iverson > > With these arguments you can shoot down everything, SPF, DKIM, DMARC... > I'm not even trying to solve intended malicious behavior because it is > much more complex and I don't want to pick up a fight right now, I'm > simply not in the position to do that. The ORT session requirement or > question never wanted to solve this completely different issue at all.
But when implementing a solution, whatever solution that may be, MUST look at the full issue. This includes looking at interoperation with current protocols and interoperation with current practices. It also includes looking at how the solution could be broken in ways that result in a sub-optimal or harmful result. The current proposal requires multiple parties (ISPs and ESPs using the List-Unsubscribe header) to change what they’re doing now. New proposals that require change are not unheard of, but if people and companies are going to invest resources into changing current behavior there needs to be a very clear benefit. 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. 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. As well, I often use the “list-unsubscribe” header to unsubscribe from certain emails. Why? Because I know that in many / most cases this header is handled by the MTA or the ESP. It is not a “normal” unsubscribe. So if I have had problems with an unsubscribe being respected, I try that. (I’ve also been known to send mail back to the bounce address in truly egregious situations). Having to append a token would break this functionality for me, and people like me, who use the List-Unsubscribe header. Overall, I don’t think the proposal, as written, addresses the underlying issue and introduces a number of opportunities for failure or sub-optimal results. I do believe there needs to be a way to mechanically handle unsubscribes, that can be used by automated systems and individuals. I don’t think the current proposal encompasses that goal. It is fragile and it is complex. What’s more, it silently (to the end user) changes current behavior. This is a recipe for a failed protocol. > Every other solution that came up in this discussion, run down to > possible pathes: > > 1# much more complex idea, that tries to solve a lot more than the > initial question asked for… The initial question was, IMO, overly simplistic. It didn’t encompass the full scope of what was needed. When that happens, creating something that does address the full scope is often a better answer than just looking at the narrow and simplistic case. > 2# leaving the situation like it is right now without changing anything Making a change to s protocol that leaves it more fragile and more complex and more prone to undesired behavior is better than not changing it. I know how frustrating it can be to try and shepherd some of these issues through a group. One of my projects took 4 years and multiple restarts as we figured out we’d missed something in the initial question and had to go back and rescope and reassess. There is a need for automated unsubscribe process. The proposal, as it stands currently, is not a good change. I do not think it will have a good chance of being adopted. It would be easier to get it adopted if the issues brought up here were assessed and addressed. Wearing people down to get them to stop objecting leads to problems in a protocol that become obvious in a few years but no one wants to fix because it was so hard to get a consensus in the first place. Let’s try and get a viable solution done, rather than sticking bubble gum in the hole and hoping no one notices the leaks. 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
