+1. This was what I was thinking when I read it, too. -S
> -----Original Message----- > From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of > John Levine > Sent: Thursday, June 09, 2016 09:11 > To: mailop@mailop.org > Cc: tobias.herk...@optivo.de > Subject: Re: [mailop] "One-Click" List-Unsubscribe URIs > > >It's a public document and I welcome requests with updates... > >https://github.com/Lockhead/oneclick/blob/master/draft-herkul > a-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. > > R's, > John > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
