> On Jun 9, 2016, at 9:11 AM, John Levine <jo...@taugh.com> wrote: > >> It's a public document and I welcome requests with updates... >> https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt > > Hmmn. One the one hand, I'm definitely in favor of making it as easy > as possible for people to make the mail go away. > > On the other hand, this particular proposal is a horrible misuse of > both http GET and of the list-unsubscribe header. The http specs are > quite clear that GET is not supposed to change the state on the web > server. For that you use POST or PUT. It is also a bad idea to try > to redefine the List-Unsubscribe header which has meant the same thing > for 18 years. > > Fortunately, this is not hard to fix. Let's invent a new header, > list-unsubscribe-post, which one can use in conjunction with > list-unsubscribe, e.g. > > List-Unsubcribe: <https://www.spammersr.us/unsub/2908duskejs> > List-Unsubscribe-Post: mailaddr=some...@receipient.de&key=0209023 > > This says to do a POST to the URL in the list-unsubscribe, with the > fields in the list-unsubscribe-post as the data to the POST. MUAs > that don't understand the new field can still do a GET to the URL > which will do whatever it does, probably show you a page with a > confirmation button that does a POST. > > This should be easy to implement, since I've never seen an http > library that could do GET that can't also do POST, and this avoids > both the semantic problem of GET, and the unintended unsubs by > filterware that poke all the URLs just to see what will happen.
+1. (recycling my comments from the last time this was suggested, in a different forum) List-Unsubscribe: is poorly defined (at least for http links) yet widely supported. mailto: links are for non-interactive use, http: links are (almost always) for interactive use. Any attempt to change that risks causing problems with a deployed base - it's not a versioned nor extensible protocol. Extending the behaviour with hidden magic doesn't seem like a clean solution to the problem, even if the magic "shouldn't" cause any problems with existing code[1]. If there is a requirement from MUA developers for an https-based non-interactive unsubscribe - and researching whether that's the case and what their actual requirements are would be the first step - then I'm sure the IETF would be open to a standard to include that metadata in an email, outside the RFC 2369 set of headers. A new RFC, or an extension of RFC 2369 to add a new List-Something header would make the whole idea cleaner and more robust than imposing structure on the existing List-Unsubscribe process, and wouldn't have much significant impact on rollout (as it doesn't change significantly the amount of new code needing to be deployed at both ends of the protocol to support it). That also opens up the option of implementing what MUA developers and list operators can agree on as a useful protocol rather than a single feature wedged into an existing one. As I'm not a list operator or an MUA developer I don't have particular things I'd want there, but I can imagine "send me no more mail like this / remove me from this list", "send me no more mail at all / suppress me from all lists" and maybe even "send me less mail like this"[2] as some possibilities. Cheers, Steve [1] Assuming that ad-hoc clients will strip off URL fragments or that servers will ignore them if they don't is reasonable in a spec sense, but may be optimistic when it comes to deployed code. [2] I like the idea of an MUA with a "meh" button that asks list senders to send less meh mail, or unsubscribe me if they can't manage that. _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
